Forums: » Register « |  Free Tools |  User CP |  Games |  Calendar |  Members |  FAQs |  Sitemap |  Support |

New Free Tools on Dev Shed!

#1
June 11th, 2003, 10:23 PM
 zenaphex
Registered User

Join Date: Jun 2003
Posts: 17
Time spent in forums: < 1 sec
Reputation 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.

#2
June 12th, 2003, 02:28 AM
 7stud
Contributing User

Join Date: Feb 2001
Posts: 1,365
Time spent in forums: 18 h 20 m 28 sec
Reputation Power: 14
Nope.

#3
June 12th, 2003, 07:25 AM
 Jason Doucette
jasondoucette.com

Join Date: Feb 2003
Posts: 378
Time spent in forums: 7 h 23 m 8 sec
Reputation Power: 11
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
June 12th, 2003, 10:56 AM
 dwise1_aol
Contributing User

Join Date: Jan 2003
Location: USA
Posts: 6,865
Time spent in forums: 3 Months 1 Day 7 h 36 m 3 sec
Reputation Power: 2199
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
June 14th, 2003, 08:25 AM
 grumpy

Join Date: Jun 2003
Posts: 1,044
Time spent in forums: 2 Days 53 m 47 sec
Reputation Power: 13
Quote:
 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
June 14th, 2003, 11:28 AM
 Jason Doucette
jasondoucette.com

Join Date: Feb 2003
Posts: 378
Time spent in forums: 7 h 23 m 8 sec
Reputation Power: 11
Quote:
 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
June 19th, 2003, 11:55 PM
 grumpy

Join Date: Jun 2003
Posts: 1,044
Time spent in forums: 2 Days 53 m 47 sec
Reputation Power: 13
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
June 20th, 2003, 01:06 AM
 TechNoFear
Offensive Member

Join Date: Oct 2002
Location: in the perfect world
Posts: 622
Time spent in forums: 3 Days 18 h 33 m 41 sec
Reputation Power: 27
>>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'.
__________________
The essence of Christianity is told us in the Garden of Eden history. The fruit that was forbidden was on the Tree of Knowledge. The subtext is, All the suffering you have is because you wanted to find out what was going on. You could be in the Garden of Eden if you had just kept your f***ing mouth shut and hadn't asked any questions.

Frank Zappa

#9
June 20th, 2003, 07:32 AM
 Jason Doucette
jasondoucette.com

Join Date: Feb 2003
Posts: 378
Time spent in forums: 7 h 23 m 8 sec
Reputation Power: 11
Quote:
 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
June 21st, 2003, 01:00 AM
 grumpy

Join Date: Jun 2003
Posts: 1,044
Time spent in forums: 2 Days 53 m 47 sec
Reputation Power: 13
Quote:
 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
June 21st, 2003, 05:36 PM
 Jason Doucette
jasondoucette.com

Join Date: Feb 2003
Posts: 378
Time spent in forums: 7 h 23 m 8 sec
Reputation Power: 11
Quote:
 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
August 22nd, 2003, 09:43 AM
 f'lar
ASP.Net MVP

Join Date: Aug 2003
Location: WI
Posts: 4,378
Time spent in forums: 1 Month 2 Weeks 2 Days 11 h 5 m 4 sec
Reputation Power: 1510
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.
__________________
Primary Forum: .Net Development
Holy cow, I'm now an ASP.Net MVP!

[Moving to ASP.Net] | [.Net Dos and Don't for VB6 Programmers]

Last edited by f'lar : August 22nd, 2003 at 09:47 AM.

#13
August 22nd, 2003, 01:15 PM
status unknown

Join Date: Jun 2003
Posts: 262
Time spent in forums: < 1 sec
Reputation Power: 11
Quote:
 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
August 23rd, 2003, 11:58 PM
 grumpy

Join Date: Jun 2003
Posts: 1,044
Time spent in forums: 2 Days 53 m 47 sec
Reputation Power: 13
Quote:
 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.

 Viewing: Dev Shed Forums > Programming Languages > C Programming > Initializing integers