Reinitializing variables & their speed sacrifice

[nbaztec]

No it's not. Ease of maintenance and readability is way, way, way more important than saving two bytes. Variables should be named to give an indication of what they do and how they're used. If somebody that worked for me named variables a, b and c, they'd be rewriting their code or looking for new work. Code has to be easy to understand.

uhh...seems you missed my point there... I also added this:

"Though I personally declare separate variables in my day-to-day projects, which span thousands of lines, just for the sake of better understandability of various variables."

I meant in simple programs like Matrix Calculators, Star/Number Pyramids (From MFC to this, I sometimes lol), etc. etc. why declare another variable.

[Lindley]

I would argue that the ability of a variable to "span thousands of lines" implies that your functions are too long to begin with. Functions should be short, concise bits of functionality which can be tested easily; the shorter the better (within reason).

[nbaztec]

I would argue that the ability of a variable to "span thousands of lines" implies that your functions are too long to begin with. Functions should be short, concise bits of functionality which can be tested easily; the shorter the better.

lol! not "variables" the "code" spans thousands of lines utilizing many custom headers....
Making variables spanning thousands of lines would only be possible if I sleep upon my keyboard with my nose constantly pressing "A" then suddenly I turn and bingo a much coveted ';'

lolz...

EDIT: Perhaps I shud throw in 1 more comma. Fixing Now.

[laserlight]

I would argue that the ability of a variable to "span thousands of lines" implies that your functions are too long to begin with.

I think that "span thousands of lines" applies to the project, not the variable.

[GCDEF]

Agreed it's a Defensive Programming, but so are try, catch, throw. But I know you too might have used various GDI functions for Windows Identifiers, Pids, Process Identifiers....and I many a times got erratic results, just because I didnt ZeroMemory() or NULL them.

try and catch are legitimate error handling mechanisms. If you want to call error handling "defensive programming", I'd agree, but all programs ought to handle errors.

[GCDEF]

uhh...seems you missed my point there... I also added this:

"Though I personally declare separate variables in my day-to-day projects, which span thousands of lines, just for the sake of better understandability of various variables."

I meant in simple programs like Matrix Calculators, Star/Number Pyramids (From MFC to this, I sometimes lol), etc. etc. why declare another variable.

I was taking issue with your blanket statement "But if a problem can be done without the need of additional 2 bytes, its always better."

I would disagree, strongly at that. Who cares about two bytes when memory is measured in gigabytes these days.

[nbaztec]

Who cares about two bytes when memory is measured in gigabytes these days.

Though agree on first statement, but this is rather over-hyped. I once almost gave all of my ram away, just because I wanted to compute upon 999K-digited number(& I mean multiplication), then I realized that if i made that class element of linkd list as short int, much of my memory cud be spared. Though agreed Cheap Memory does have its pros....

[Lindley]

Well, there's a huge difference between saving 2 bytes and saving 2 bytes in a frequently-used object. Saving 2 bytes total is essentially irrelevant. But if you cut down a class size by 2 bytes, and you use 500000 objects of that class, you've just saved yourself a lot more.

So just play it by ear, and save what you can, if you need to. (If you haven't determined you need to reduce your memory usage, don't worry about doing so more than is trivial to do.)

[kempofighter]

I just bought a PC with 6GB of RAM for $409. RAM is cheap. You want to be careful, but if you're reusing variables rather than allocating a few extra ints, you're not programming well.

Default constructors don't initialize memory, and while it won't hurt to do it, there's nothing gained by initializing something to a value that you turn around and overwrite right away. As I said before, it's just a safe habit to develop so that you don't forget to do it when you need to.

I disagree with the statement that there is nothing to gain from the initialization. In the original example scanf was used to write to the variable. Likewise if cin was used it is possible for the extraction to fail leaving the variable initialized to who knows what. std::cin provides failure detection but I am not sure that scanf does. Depending on what your program subsequently does that kind of logic can lead to unexpected behavior. You are right in the third case where the for loop resets the variable to zero unnecessarily. However in that case the programmer could have just left the first part of the for loop empty. To some degree it could be a matter of preference. I like my functions to initialize everything to a known state so that if something fails I don't end up looking at garbage values within the debugger.

I could understand leaving an array uninitialized if you know you are going to completely overwrite it with data anyway provided that it is unlikely that a failure will occur or there is some performance requirement that requires that you don't zero initialize. Again if the write doesn't work I don't want to see an uninitialized buffer full of garbage while debugging. If you are talking about a buffer that was initialized from a binary file or image of some kind it may not be easy to determine if the pattern within memory is good data or bad but if it were zero initialized you can tell that it is still empty very easily. some people don't like to use std::vector for this reason because they don't want zero initialization to occur during construction of the object. If the initialization causes serious performance degradation then I can understand that. However, if it is rather small and doesn't cause me problems I would prefer to zero initialize anyway.

I understand that some might disagree but I was just offering my point of view.

[ninja9578]

1) Technically speaking... int main(argc, argv**) on Windows, another void * on linux and another int on top of that for Mac. :P

2) You're not using it, don't initialize it. It's good practice for debugging, but not release. Most debuggers will null initialize things to BAADF00D or DEADBEEF anyway.

3) Don't even declare the variable outside of the loop, you can declare it in the loop with C++. Not in C granted, but with C++ it's better because the optimizer can do more with it.

ZeroMemory is not C++, it's Windows API. You should only do that if you want the majority of the structure to be zero. You're right about the effects being minimal, but remember that a lot of us go through millions of recursive functions, and work in data sets in the gigabytes, in those cases it starts to matter.

[Lindley]

std::cin provides failure detection but I am not sure that scanf does.

The scanf() family of functions returns the number of format specifiers corresponding to successful conversions. So it does provide failure detection so long as you include at least one format specifier (other than %n) in the string.

[kempofighter]

2) You're not using it, don't initialize it. It's good practice for debugging, but not release. Most debuggers will null initialize things to BAADF00D or DEADBEEF anyway.

Most? Not sure about that. very few that I have used will do that. I remember that visual studio did that for me back when I used it. Sometimes profilers will do that in order to help detect potential problems. I'd rather not rely on the compiler to do that. The compiler does it to help you find situations where you forgot to do it and then you go fix it. Also if you aren't using it don't even create it in the first place.

ZeroMemory is not C++, it's Windows API. You should only do that if you want the majority of the structure to be zero. You're right about the effects being minimal, but remember that a lot of us go through millions of recursive functions, and work in data sets in the gigabytes, in those cases it starts to matter.

I know that the windows API has some kind of a zeroMem function but I never suggested that anyone use it since it isn't portable. I was suggesting that initial values be suplied to the constructors or that the constructor default initializes all values. I don't even write windows programs so the thought of the zeromem function never even entered my mind.

A lot of who go through millions of recursive functions? I never have. I did specifically state that there are cases like that where you don't want to zero initialize a giant array of data. For buffers that are overwritten multiple times I don't suggest zero initializing multiple times but I still think that if it doesn't degrade performance that it is good to allow zero initialization upon creation.

Anyway, do it however you want in your own program. Opinions will always vary on the subject.

[andersod2]

Someone may have already stated this, but there is an important difference between initialized & uninitialized data in that uninitialized data ends up in the .bss segment (assuming it's supported on the particular platform), and thus does not add to the executable size (since it will not be stored in the executable). Initialized data will go into the .data segment along with it's initial value, and thus becomes part of the exe. I believe the exception to this is static data which I *think* is always initialized in the .data segment.

In the OP's given example this may not matter, but large programs can be drastically affected in code size depending on whether the data is initialized or not. Try using large int arrays in the given example with and without initialization (and with/without static) and the difference in exe size should be apparent.

[nbaztec]

2) You're not using it, don't initialize it. It's good practice for debugging, but not release. Most debuggers will null initialize things to BAADF00D or DEADBEEF anyway.

Agreed on debugging aspect, as we're the only one's operating. But once RTM, nobody knows how the code will behave on diff PCs( a la run-time errors), owing to a Corrupted RAM, 99% CPU usage, Virus, etc. The user may even be an Average Joe, and wouldn't be as accustomed as we to our own developed app. So IMO it's always gud to initialize.

3) Don't even declare the variable outside of the loop, you can declare it in the loop with C++. Not in C granted, but with C++ it's better because the optimizer can do more with it.

Ya, I dont. But C doesn't permit this. C++ does n I'm more than familiar with this.

ZeroMemory is not C++, it's Windows API. You should only do that if you want the majority of the structure to be zero. You're right about the effects being minimal, but remember that a lot of us go through millions of recursive functions, and work in data sets in the gigabytes, in those cases it starts to matter.

Well as for ZeroMem() I mostly develop Windows Apps, so I apologize for not stating otherwise.

The better compilers, assign 0 to ints 0.0 to floats and NULL for chars automatically. So if we take it for granted that every compiler will be like this, the code has a slight chance to show abnormal behavior on diff compilers.

And since the question has been popped up of recursive functions, personally I hate them, unless they are the CALLBACK functions utilizing Windows Procedures. But in normal C/C++, which is better in terms of Performance:
a) A Loop
b) A Recursive Function

I guess so: A loop, as a function is called again and again (and sometimes....again) thus affecting speed greatly.

[Lindley]

Trivial recursion should certainly be replaced with a loop. But in divide-and-conquer algorithms where a function contains two or more recursive calls, converting to a loop is usually more trouble than it's worth; you quickly reach the point where you're obfuscating what the function actually does for the sake for a few milliseconds, which of course is bad form.

As always, the rule is: Keep the code obvious until you've profiled and determined that it needs to be faster, and where.