why use #define?

Why not just put the number itself in?
For example: for some constant called "DECK_SIZE":

1.) You can change it everywhere at once (i.e., what if you want a 20 card deck, or a 54 card w/ 2 jokers?
2.) It makes it easier to see what is going on:
for(unsigned int i = 0; i < DECK_SIZE; ++i) //very obvious
for(unsigned int i = 0; i < 52; ++i) //what is 52? is it special? or is it related to something else?

Although, for stuff like this, you should use const variables IMHO.
I kinda figured the 2nd one but it's never been an issue remembering that kind of stuff. The first one sounds neat though. Thankies :)
Don't get carried away though. If you need a zero, just use a zero.
There are some companies where people have to #define ONE, TWO, THREE, etc. Nonsense. Especially when, at some point, the following happens: #define THREE 4
That may look funny, but it is really cold, hard, cruel truth.
Sometimes #define is a macro, so instead of having to type in a routine, you can just #define it. this can speed up runtime, because define is before runtime and calling routines happens at runtime.

It will be an issue at some point. For small programs, yeah, it's easy to remember. But for large programs (the project I work on is well over a million lines) it is easy to forget. Time also erodes memory.

@Duoas: OMG, did we work for the same company at one time???? We did exactly that. Everything you said. Including the #define THREE 4...

EDIT: That was in a previous job, not the current one...
Last edited on
What is this million+ line project? It sounds interesting; anything with more than 1000 lines of code is interesting; and many things with less...
Sorry, I prefer not to discuss it.

"Interesting" is an ... well, interesting ... way to put it. Projects of that size are so large that no single person can understand how it all works. Programmers at that point become specialists -- they become the sole author and
maintainer of a small subset of the overall project. They know the internal details of how their code works, and
they know the external APIs they use. Because they have the most knowledge, they can "maintain" the code
more easily than anyone else. They fix all the bugs in that piece of code, and they implement all the new
features. And it becomes a positive feedback loop.

It is a problem when they move on to other projects or other jobs because nobody will ever have as thorough,
detailed knowledge and understanding of the software the programmer wrote as the programmer himself/herself,
regardless of how much documentation they write. Even the original author will forget a lot of details if they aren't
dealing with the software routinely. I know. I've written a lot of code in the system that I work on, in many
disparate areas. I jump from area to area, depending upon what new features need to be implemented.

Some of the software I wrote six years ago was so simple at the time. All you had to do was derive
your new class from some base class, and override a few virtual methods. Today, I've forgotten all the
important details of how to do that -- what should function Init() do, when is it called, etc. It was simple
back then, yes, but time erodes even the best of memories. Looking back, yes, I did write copious amounts
of documentation -- design documents, code comments, etc. But still, neither the documentation nor the
comments add up to the knowledge I had when I wrote the software.

And that is why I always harp about maintainability and even why I often post messages like "here's a one-
liner that does the same thing". Less code to maintain, readability equal, is always better. Not only is it
easier to modify later, but it is quicker to understand.

std::sort( people.begin(), people.end(), 
   &boost::lambda::_1->*&Person::age < &boost::lambda::_2->*&Person::age );

IMO is slightly quicker to understand (provided the lambda expressions are readable to you; for anyone
beginning to learn boost::lambda, the above will be unreadable) than looking at an inlined custom
quicksort to do the same thing. Even though many programmers are able to look at the overall structure
of the code and realize it is sorting, there is still some text-scanning involved to figure out the sorting

And IMO the above use of boost::lambda to define the sort criterion is slightly more maintainable than
writing the function object:

struct SortAscendingByAge {
    bool operator()( const Person& p1, const Person& p2 ) const
       { return p1.age < p2.age; }

std::sort( people.begin(), people.end(), SortAscendingByAge() );

because, while both are equally readable to me, the function object is more typing, and if I ever want
to change the sort criterion, I either have to write another function object (more code to maintain) or
change its name in two places -- call site and declaration site.

I have never seen anyone go over 400 lines of code :(
I agree:
It sounds interesting; anything with more than 1000 lines of code is interesting
I have never seen anyone go over 400 lines of code :(
I agree:
It sounds interesting; anything with more than 1000 lines of code is interesting
closed account (S6k9GNh0)
>.> I've gone over 400 lines using Unreal Script. No one even appreciated it accept for my own UT04 server. :/

That and I've gone over 400 lines coding a game I've yet to finish because it looks terrible and I'm not sure if I'm using the most effecient methods....
I know but I haven't seen one my longest is probably the pig latin program ... which no one is commenting on T-T
I know but I haven't seen one my longest is probably the pig latin program

It was a fun idea...

I like the GNU fdisk program so I downloaded the source and I'm trying to figure out how it works. I have everything except actually getting disk information :)

Eventually you won't be able to tell it apart from:
$ sudo fdisk -l /dev/sda

Disk /dev/sda: 640.1 GB, 640135028736 bytes
255 heads, 63 sectors/track, 77825 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xc7285e18

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            1212        1403     1535992    7  HPFS/NTFS
/dev/sda2   *        1403       69332   545643340    7  HPFS/NTFS
/dev/sda3           69333       77825    68220022+   5  Extended
/dev/sda4               1        1211     9727326   82  Linux swap / Solaris
/dev/sda5           69333       77473    65392551   83  Linux
/dev/sda6           77474       77825     2827408+  82  Linux swap / Solaris
Last edited on
I'm on 483 lines already for a school project...admittedly it's spread over 7 files and is really three projects put together, but...
What is it supposed to do?
It's got code for Stacks, Queues, and linked lists...
That reminds me I need to learn sorting alogrithms and linked lists and what not.
Topic archived. No new replies allowed.