1. No Profile Picture
Registered User
Devshed Newbie (0 - 499 posts)

Join Date
Jun 2003
Posts
17
Rep Power
0

#### Initializing integers

I was hoping there would possibly be a way to initialize a bunch of integers to zero on one line without all the '=0's in it. For example, here's the typical setup:

Code:
`int a=0, b=0, c=0, d=0, e=0, f=0, g=0;`
I know this could be done with a simple array setup, but I was just curious if anyone happens to know a simpler way of setting this up so that it doesn't have all the '=0's in it. Something like this, but it doesn't work of course. Just concept.

Code:
`int (a, b, c, d, e, f, g) = 0;`
Sorry for being picky, but it doesn't hurt wanting to explore possiblities. :D
2. No Profile Picture
Contributing User
Devshed Beginner (1000 - 1499 posts)

Join Date
Feb 2001
Posts
1,481
Rep Power
16
Nope.
3. If you separate the declaration and initialization into 2 lines, you can do this:

int a, b, c, d, e, f, g;
a = b = c = d = e = f = g = 0;

If the reason you do not want to have all those 0's is because you wish to later change them all to another constant, the above would be easier. Of course, if you have constants that can change in your program, then you should DEFINE them:

#DEFINE MYNUM 0

Then, you could do this:

int a=MYNUM, b=MYNUM, c=MYNUM, d=MYNUM, e=MYNUM, f=MYNUM, g=MYNUM;

or the method I showed:

int a, b, c, d, e, f, g;
a = b = c = d = e = f = g = MYNUM;

Hope that helps.
4. Explanation:
In an assignment statement, the right side (rvalue) is evaluated first and then assigned to the left side (lvalue). So in the example:
Code:
```lvalue   rvalue
a          b = c = d = e = f = g = 0
b          c = d = e = f = g = 0
c          d = e = f = g = 0
d          e = f = g = 0
e          f = g = 0
f          g = 0
g          0```
The value to which an assignment statement evaluates is its rvalue; thus,
(g = 0) == 0

So zero is assigned to g, then g to f, then f to e, then e to d, then d to c, then c to b, and finally b to a.

Remembering how it works will help you remember how to do it.
5. Originally posted by Jason Doucette
If you separate the declaration and initialization into 2 lines, you can do this:

int a, b, c, d, e, f, g;
a = b = c = d = e = f = g = 0;

If the reason you do not want to have all those 0's is because you wish to later change them all to another constant, the above would be easier. Of course, if you have constants that can change in your program, then you should DEFINE them:

#DEFINE MYNUM 0

Then, you could do this:

int a=MYNUM, b=MYNUM, c=MYNUM, d=MYNUM, e=MYNUM, f=MYNUM, g=MYNUM;

or the method I showed:

int a, b, c, d, e, f, g;
a = b = c = d = e = f = g = MYNUM;

Hope that helps.
It is actually quite poor form to do this in C++ (and I think in standard C, but may be corrected on that). Yes it is allowed, but use of the preprocessor for this sort of thing can actually be a maintenance nightmare.

You will be better off doing

const int MYNUM = 0;

rather than using a macro.
6. Originally posted by grumpy
Yes it is allowed, but use of the preprocessor for this sort of thing can actually be a maintenance nightmare.
Can you elaborate on this? I have never used such code as the above as I cannot see any reason to do so where an array would suffice, but I am curious as to what problems can arise.

This reminds me... I have often attempted to recompile a program to find an error reported that a certain MACRO was already defined - which I know was not defined previously, as it is defined at the start of the only source file. Asking to re-compile everything will makes it solve the problem. It is like it remembers the definition from the last compile every once in a while. I am using MSVC++ 6.0. Has anyone run into this problem?
7. My comment was more concerned with using

#define Value 2

versus

const Value = 2;

than with using arrays. There are a number of reasons that the second form is preferred in C++, including the fact it is typesafe.

As an example of the problems that can be caused, consider the following scenario.

1) The definition of Number is written by programmer 1, in a file called header1.h

2) The following declaration is written by programmer 2, in header2.h.

class Number
{
public:
// various members, constructors, etc

int Value() const { return data_value;};
private:
int data_value;
};

3) Programmer 3 comes along and does something simple like

// more stuff

The result, if header1 uses the macro form, will be compilation errors while parsing header2.h as the line

int Value() const {return data_value;};

will be seen by the compiler as

int 2() const {return data_value;};

This sort of thing is a maintenance nightmare, particularly in large projects developed by teams. In this example, for example, programmer 2 may get a bug report that he can do nothing about.

The reason this can happen with macros is that the preprocessor just does a straight text substitution.
8. No Profile Picture
Offensive Member
Devshed Novice (500 - 999 posts)

Join Date
Oct 2002
Location
in the perfect world
Posts
622
Rep Power
28
>>It is like it remembers the definition from the last compile every once in a while. I am using MSVC++ 6.0. Has anyone run into this problem?<<

Yes. Similar problems.

MSVC only rebuilds the changed files (more to the point, ones MSVC thinks have affected the exe).

Sometimes it requires a 'rebild all' (or 'rebuild solution')

In extreme cases it requires all files in the debug or release folders to be deleted and a full rebuild.

Saving regularly seems to help. Try ALT + F then L to 'save all' then F7 to 'build' or F5 to 'build and run'.
9. Originally posted by grumpy
The reason this can happen with macros is that the preprocessor just does a straight text substitution.
Understood. I guess this is the reason why I, and most other people, define macros in ALL CAPS, and never define variables in all caps, and always define classes starting with a capital C. This should avoid any such problems. However, your point is well taken. The type checking of a real type associated with the value is nice to have.
10. Originally posted by Jason Doucette
Understood. I guess this is the reason why I, and most other people, define macros in ALL CAPS, and never define variables in all caps, and always define classes starting with a capital C. This should avoid any such problems. However, your point is well taken. The type checking of a real type associated with the value is nice to have.
What you say makes sense *if* you can rely on everyone working on your project doing the same thing, *and* there aren't spurious #define's in system header files.

I've encountered system headers that #define macros in various ways, and caused such problems. One that comes to mind is a system header from Microsoft that #define'd a macro called Sleep() [don't recall offhand what arguments it accepted]. That caused all sorts of grief, when it interacted with a class definition that included a Sleep() method.

I've also encountered similar things with C and C++ compilers on Unix boxes, even if the details don't spring to my mind right now.

The reason I prefer not using a macro in this cases is simply to reduce chances of getting error messages that aren't particularly helpful in tracking down the error.
11. Originally posted by grumpy
I've encountered system headers that #define macros in various ways, and caused such problems. One that comes to mind is a system header from Microsoft that #define'd a macro called Sleep() [don't recall offhand what arguments it accepted]. That caused all sorts of grief, when it interacted with a class definition that included a Sleep() method.
Ouch. I can't imagine the problems that could arise. Another thing in favour of declaring variables rather than defines is that in C++ you can now declare a const variable, and use it just as you would a macro (for example, by using its value to declare a specific sized array). So, I guess there is no real reason to use defines for variables anymore...
12. From what I've heard, it's actually a judgement call. #define is faster, because the text is substituted during pre-compile, so when the program is run it's as if there were a literal there, while consts are still variables, and so there are a few extra instructions run to get the value at the address of the const, and the fact that some memory is allocated for the variable in the first place. On the other hand, consts are typesafe, as was mentioned earlier, and they're just *considered* better form.

Hmm, just noticed the old date on this thing. I was bored at work and needed something to keep busy, and didn't check. sorry if this seems like old and buried to some.
Last edited by f'lar; August 22nd, 2003 at 08:47 AM.
13. No Profile Picture
status unknown
Devshed Newbie (0 - 499 posts)

Join Date
Jun 2003
Posts
262
Rep Power
12
Originally posted by f'lar
From what I've heard, it's actually a judgement call. #define is faster, because the text is substituted during pre-compile, so when the program is run it's as if there were a literal there, while consts are still variables, and so there are a few extra instructions run to get the value at the address of the const, and the fact that some memory is allocated for the variable in the first place.
Variable constants. Cripes! Note that in some cases it may be possible for the compiler to get away without allocating space for a constant.
14. Originally posted by f'lar
From what I've heard, it's actually a judgement call. #define is faster, because the text is substituted during pre-compile, so when the program is run it's as if there were a literal there, while consts are still variables, and so there are a few extra instructions run to get the value at the address of the const, and the fact that some memory is allocated for the variable in the first place. On the other hand, consts are typesafe, as was mentioned earlier, and they're just *considered* better form.
You've heard wrong.

When passing arguments by value as a function argument, the compiler is required to make a copy of the value passed and pass the copy to the function. It makes no difference to a compiler whether it does that by copying a literal value or by copying from some defined area of memory.

For example, if we have a macro

#define VALUE 1

and a usage
Function(VALUE);

the preprocessor will translate that into

Function(1);

That value has to be copied into a defined space (eg a data structure or a machine register) before the function is called.

An alternate usage

const int value = 1;

Function(value);

That value also has to be copied into a defined space (eg a data structure or a machine register) before the function is called.

IOW, there is no possible performance gain to using macros in instances where arguments are passed by value.

If the Function takes a reference argument (something possible in C++ but not in C), the situation is a liittle different. In the first case,

Function(1)

must be expanded into something like;

int temp = 1;
Function(temp); //pass by const reference

i.e. the compiler must introduce a temporary variable. In fact, several modern compilers do exactly this, and a smart optimiser is needed to fold multiple uses of a literal into a single (const) variable.

With usage of a const variable, the temporary is not needed as it is already allocated.

The only reason #define is used at all, in C or C++, is that older versions of C did not provide the const keyword, let alone const variables. Hence the only way of achieving the desired effect was to use macros. So, if you're using an antique compiler (pre mid-1980s) you may be stuck with using macros.