Why separate variable definition and initialization in C++?

Question

I\'m currently working on some quite old C++ code and often find things like

int i;
i = 42;

or

Object* someObject = NULL;
someO         


        

Answer 1

Why separate variable definition and initialization in C++?

You haven't separated definition and initialization. You have just assigned the variable/object (to some particular) value in your code snippet. So the title is misleading.

Object someObject;
someObject = getTheObject();

is quite different from Object someObject = getTheObject();

someObject = getTheObject(); invokes the assignment operator of Object class whereas in Object someObject = getTheObject(); copy constructor of the class gets invoked. This is also known by the name copy initialization

A good compiler might generate the same code in case of int i; i = 42; and int i =42. There won't be much of an overhead.

BTW I always prefer int i = 42 to int i; i=42 and

Object someObject = getTheObject(); to

Object someObject; someObject = getTheObject();

P.S : int i = 42 defines and initializes i whereas int i; i=42 defines i and then assigns 42 to it.

Answer 2

There is a good technical reason on ROM-based hardware, it is NOT a style issue:

On ROM/EEPROM based embedded systems, this has an effect on where in the binary the value is written. Uninitialized variables are written into .bss, whereas initialized variables are written into .data. Premature initialization will bloat your ROM space, which on older embedded systems can get you into big, big trouble. If you are running on a system with a small ROM, you can run out of memory if you initialize needlessly. Some goofy compilers will even address directly into the ROM, making these values effectively read-only if you are not careful.

e.g. See this GameBoy example for a more thorough explanation: http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_varinit

Answer 3

In C, there is the restriction that you have to define your variables at the top of the code block, even if you only need them somewhere later on in the function. So in the old days of C, people often first defined all their variables and then later though about the values they should have.

Since you say it is quite old C++ code, it might use that same convention as a holdover from C practices.

There is no real reason to do this in C++, though. Better always define your variables where you can initialize them directly.

Answer 4

int i;
i = 42;

That is not separate variable definition and initialization.

That is separate variable declaration and assignment. I don't see any reason for this. If you know the value at the time of declaration of variable, then initialize it right then. So your question doesn't has any rationale explanation.

Of course, if you don't know the value at the time of declaration, then you don't have any choice, you need assignment then.

Answer 5

Consider the following case:

SomeType object;
if( whateverCondition ) {
   object = getObjectOneWay();
} else {
   object = getObjectAnotherWay();
}

this way it's clear that both branches assign the variable and its initial value is irrelevant. It's rarely worth that however.

Answer 6

Object someObject;
someObject = getTheObject();

This uses the assignment operator.

Object someObject = getTheObject();

This uses the copy constructor.

Apart from that, your suggested changes are equivalent, and you should implement them. The copy ctor/assignment operator difference is expected to produce the same result, this is not enforced by the language though.

I see no valid reason to split up declaration and assignment like the original code does - even though for all practical purposes it doesn't introduce overhead (except for the object)