1

It baffles me why C++ compilers do not initialise every integer declaration to 0, be it local or global or members? Why do uninitialised sections exists in the memory model?

Lundin
  • 195,001
  • 40
  • 254
  • 396
sandeep bisht
  • 111
  • 12
  • 9
    Because that's how C++ is *specified* to work? – Some programmer dude Mar 27 '14 at 08:59
  • 6
    Because there are costs to doing so and usually the initial value of a variable doesn't need to be zero and setting it to zero and not the value you wanted isn't that much better than it having an undefined value. – jcoder Mar 27 '14 at 09:00
  • 1
    For the same reason static linkage (globals, local statics, etc) *does* initialize with zero-fill; because that is how the language is designed. I could just as easily ask why globals/statics *are* zeroed and not treated like locals. – WhozCraig Mar 27 '14 at 09:01
  • as for your second question: because noone going over the RAM (FREE) memory and setting it to 0s a) it is useless b) it cost memory bandwidth and cpu.and also noone care about uninitialized (junk) memory values , because it is up to you to initialize them in your program as u need it and you don't always need them to be 0 not even in 50% of times in my experience. if you don't initializing them you should expect for undefined behaviour that's how things works in life `c'est la vie`(noone will do hard job for no reason especially when it kills performance - and thats gr8 imo). – Coldsteel48 Mar 27 '14 at 09:07

3 Answers3

17

I know it's a dull answer, but your question begs for it exactly:

Because the C++ standard says so.

Why does it say so? Because C++ is built on a principle:

Don't pay for what you don't use.

Setting memory to a certain value costs CPU time and memory bandwidth. If you want to do it, do it explicitly. A variable declaration should not incur this cost.

rubenvb
  • 74,642
  • 33
  • 187
  • 332
  • 1
    +1, but I think a better phrasing of the principle would be "*Only* pay for what you use," or "Don't pay for what you don't use." – Angew is no longer proud of SO Mar 27 '14 at 09:12
  • There is no rational, consistent plan behind these languages. If C/C++ were actually designed for "pay for what you use", then there would be no zero-out initialization of static storage variables at file scope. There would be no implicit zero-out of items in an array that are not explicitly initialized. There would be no implicit type promotions. And so on. So no, C and C++ were rather built on the principle "Ooh, programming is fun! Let's make a language! Toss some random stuff together and see what we end up with." – Lundin Mar 27 '14 at 09:24
  • @Angew You're right, I couldn't get myself to come up with those two phrases. – rubenvb Mar 27 '14 at 09:28
  • @Lundin Feel free to take up all those points with the people in the [Lounge](http://chat.stackoverflow.com/rooms/10/loungec). Don't tell them I sent you, and don't expect *anything*; or you might be disappointed, offended, or otherwise misled by their collective responses. – rubenvb Mar 27 '14 at 09:29
  • @Lundin I can't agree. Statics are initialised *once,* while function locals would be initialised *each time* the function is executed - *vast* performance difference. Non-initialised array items are only zeroed out if you initialise at least a part of the array - and as array elements are not "complete objects," it makes sense that initialising a part of the array means initialising the whole thing. – Angew is no longer proud of SO Mar 27 '14 at 09:31
  • 1
    It's probable that the cost would be negligible today; the compiler could probably optimize out most, if not all of the unnecessary initializations. It was a performance issue back when the rule was made. As for statics: the initialization is necessary anyway, and done by the OS. (You never receive uninitialized memory from the OS, for security reasons.) – James Kanze Mar 27 '14 at 09:40
  • @Angew Try working with real-time systems. Zero-out crap at the very beginning of your program start up phase, which is often a performance-sensitive part of the program, is often not desired. Particularly, you don't want any damn C++ constructors executing at that point. The only way to dodge it is to set the compiler to create non-conformant start-up code. As for the array initialization, I just wanted to point our how inconsistent the language is. Why does it implicitly zero out array items that I don't plan to use until later? If I just want to use items 1, 2 and 3, why zero 1000 items? – Lundin Mar 27 '14 at 09:42
  • @rubenvb Huh? Why? You can't make any arguments of your own? – Lundin Mar 27 '14 at 09:47
  • 1
    @Lundin I'd say primarily because comments aren't intended for long discussions. – Angew is no longer proud of SO Mar 27 '14 at 09:48
  • @Lundin: I don't live inside the minds of the people who wrote C++. Some in the Lounge kind of do, because their understanding of the language supercedes anything I have seen elsewhere. So yes, I can't make, or rather I won't, make arguments of my own. – rubenvb Mar 27 '14 at 10:03
7

C++ is based on C, and in C a primary design concern was code efficiency. In most cases you want to initialize a new variable to a specific value after declaring it. When the compiler would write 0 to that memory address just to write another value to it shortly afterwards, it would be a waste of a CPU cycle.

Sure, a smart compiler could detect that a variable isn't read before it gets a value assigned and could optimize the initialization to 0 away. But when C was developed, compilers weren't that smart yet.

The C language and its standard library generally follow the principle that it doesn't do stuff automatically when it might be unnecessary to do it under some circumstances.

Philipp
  • 67,764
  • 9
  • 118
  • 153
  • @TonyD Such cases are rare, and involve code complicated enough that the cost of the additional initialization would be negligible. – James Kanze Mar 27 '14 at 09:41
  • "Sure, a smart compiler could detect that a variable isn't read before it gets a value assigned and could optimize the initialization to 0 away." - in many cases that's true, but whether initialisation happens appropriately may depend on runtime variables, and very occasionally static analysis is theoretically possible but prohibitively expensive. Tracking initialisation across functions is pretty tricky too. – Tony Delroy Mar 27 '14 at 09:52
  • (sorry - edited slightly and moved my earlier comment). @JamesKanze that's trivialising the difficulties overly... consider: `int x[10000]; void f(int*); f(x);` - nothing particularly complicated, but relatively expensive to initialise in the caller when perhaps `f()` will do it adequately anyway (or `throw` or something indicating the array shouldn't be used). – Tony Delroy Mar 27 '14 at 09:54
2

It might make life easier for you if it did, but C++ errs on the side of avoiding overheads, e.g. setting values which you might then reset to something else.

doctorlove
  • 18,872
  • 2
  • 46
  • 62