Something that has always bothered me is why isn't data set to NULL by the compiler, if nothing else was specified? I can't see any reason NOT to, and surely it must be better than the junk that gets referred to otherwise?
Asked
Active
Viewed 175 times
3
Brian Tompsett - 汤莱恩
- 5,753
- 72
- 57
- 129
KaiserJohaan
- 9,028
- 20
- 112
- 199
-
Perhaps to preserve the behavior present in C? C++ is just a superset of C, after all. That's my guess anyways. It's probably also just ever so slightly more efficient at runtime to not initialize anything unless explicitly instructed to do so. – aroth Apr 09 '11 at 11:52
-
[similar post](http://stackoverflow.com/questions/1910832/c-why-arent-pointers-initialized-with-null-by-default) – Prince John Wesley Apr 09 '11 at 11:53
5 Answers
3
The original reason was "for speed" -- the variables were only going to make sense once you assigned something to them, so there was an effort to not make a pointless initialization to 0 that was just going to be overwritten by the programmer in a few milliseconds with the actual data anyway.
While it isn't exactly expensive, compilers probably don't zero out variables today for the same reason: any compiler that does would look slow compared to other compilers on benchmarks.
sarnold
- 102,305
- 22
- 181
- 238
3
The only good reason is that it's not as efficient. C and C++ (unlike higher-level languages) tend not to do anything you didn't ask for. That is how they got the reputation of being extremely fast. Other languages are safer, but slower.
If you wanted to initialise fields to anything other than NULL, it would be a waste of time to first initialise it to NULL and then initialise it to whatever you set it to. So C/C++ assumes you know what you are doing.
mgiuca
- 20,958
- 7
- 54
- 70
0
My guess is because of speed reasons. They would be another CPU call(s) to do it.
KARASZI István
- 30,900
- 8
- 101
- 128
0
If you declare a variable on the heap (not free store, i.e. globally and only globally), this will be initialised to 0.
Data on the stack, however, is not allocated as a way to speed this up. There's no point initialising data to 0 if you're going to overwrite it, which is the assumption made with local (stack) data.
Ben Stott
- 2,218
- 17
- 23
-
Ahhhh that makes sense. However, it does not explain the behaviour of initialised class instances that has data members that if you don't NULL them in the costructor, they refer to junk? – KaiserJohaan Apr 09 '11 at 11:55
-
Are you sure about that? I'm fairly confident that variables declared on the heap are garbage just like everything else. Now obviously "garbage" can mean *anything* including 0. Probably in *most* cases you will find (due to your compiler or your operating system) that they are zeroed out. But I am almost 100% confident that the language does not guarantee this and therefore you had better not assume it. – mgiuca Apr 09 '11 at 11:57
-
1
-
I apologise - this was poorly worded. By heap, I meant globally declared. Note that there's a large distinction between the heap and a globally declared variable, though they're often considered one and the same. In any case, it does explain an intialised class instance (globally). The class itself will be 0, but its members won't be. – Ben Stott Apr 09 '11 at 12:08
-
1Wow, I read the spec, and I stand corrected! In both the C99 and C++ specs, variables with static storage duration are zero-initialised, so you are right. +1 – mgiuca Apr 09 '11 at 12:16
-
I disagree, and http://stackoverflow.com/questions/3553559/how-are-local-and-global-variables-initialized-by-default seems to support my hypothesis. This has quotes from the standard, which I'm not as well-versed in, but this should be adequate for our purposes anyway. – Ben Stott Apr 09 '11 at 12:19
-
Ah, thanks. :) Glad to know that I'm not *always* smoking something strange. :P I haven't read into that too much, but i do believe that also means that heap allocations are initialised with their default constructor, too (of course, POD types have a garbage value as their default, so this won't make a difference in that instance...) – Ben Stott Apr 09 '11 at 12:22
-
Yes, heap allocations are initialised with their default constructor (unless you use `malloc`, but you shouldn't). But the default constructor *is garbage* by default. Only if you program the default constructor to initialise things to NULL will the heap allocation do that initialisation. – mgiuca Apr 09 '11 at 12:38
-
Yeah, as I said - POD values have a garbage value by default, which will rarely be overridden for practical purposes. In any case, only stack (or function-specific) variables are initialised with explicitly garbage data, and this was done with speed in mind. Thanks for keeping me on my toes though! – Ben Stott Apr 09 '11 at 12:41
-
But, Ben: Static varibles are not allocated on the heap. They reside in the BSS (which is not part of the heap). – Johan Kotlinski Apr 10 '11 at 08:00
-
Yeah, that's why I specifically clarified the free store section - most people consider it the heap. However yes, you're correct (I'm assuming by 'static' you're referring to variables that aren't physically defined as 'static', because they weren't what I was initially referring to).... – Ben Stott Apr 10 '11 at 08:05
-
0
Setting the allocated memory to zeroes and marking the structures as 'null' takes time. Your application may have time-critical sections where objects must be instantiated as quickly as possible, after which you initialise them in as minimalist way as possible to make them usable. So the compiler and runtimes do as little work as possible to make the objects, and leave it to you to complete their setup as you see fit.
Some high-level languages do implement further initialisation to 'null', but these are then not always suitable for time-critical applications.
Eight-Bit Guru
- 9,756
- 2
- 48
- 62