0

My code is :

#include <iostream>
using namespace std;

int main() {
    // your code goes here

    int* a;

    a = new int[5];
    for(int i = 0; i < 5; i++)
        cin>>a[i];

    for(int i = 0; i < 5; i++)
        cout<<a[i]<<" ";

    delete[] a;
    cout<<"NEW MEM  ";
    a = new int[5];
    for(int i = 0; i < 5; i++)
        cout<<a[i]<<" ";

    return 0;
}

INPUT : 1 2 14 4 5 and OUTPUT : 1 2 14 4 5 NEW MEM 0 0 14 4 5

Please explain why i am not getting OUTPUT : 1 2 14 4 5 NEW MEM 0 0 0 0 0

curiousgeek
  • 903
  • 11
  • 18

2 Answers2

6

Perhaps you were expecting that new int[5] would zero-initialise the new block of memory.

Well, it doesn't! And that's pretty much that. C++ doesn't do things you didn't ask for, because if you didn't want them, that's an unnecessary performance hit.

It looks like your new memory block just so happens to be found at the same place as the last one, and now you're [partially] observing the values left behind from the last one. Technically these values are unspecified, and reading them means your program has undefined behaviour. You have to provide your own fresh values for these new array elements before you can use them for anything truly meaningful.

Or perhaps you were expecting the delete[] to zero-initialise the dying block of memory.

That doesn't happen either. There's really no point in zeroing-out objects just as they are about to wither out of existence. Again, C++ won't waste time on things like this.

You can make the zero-initialisation happen with new int[5]() but I don't see a good reason to do so here.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
  • Why I am getting first two elements as 0 then? – curiousgeek Oct 05 '18 at 10:43
  • 1
    @curiousgeek> why not? You get whatever value is at this memory location. – spectras Oct 05 '18 at 10:43
  • Why do I get all elements as 0 (always) when I just run this code : #include . using namespace std; int main() { int* a = new int[5]; for(int i=0; i < 5; i++) {cout< – curiousgeek Oct 05 '18 at 10:50
  • 1
    @curiousgeek> Same, you get whatever happens to be there. It just so happens that specific example, when run, happens to locate your pointer in an area that has zeroes. – spectras Oct 05 '18 at 11:01
  • But why always, thats why i started thinking that it gets zero intialized automatically. According to you that 0's are garbage – curiousgeek Oct 05 '18 at 11:03
  • @curiousgeek The answer is still "it is **undefined behavior**". Don't do it, don't expect sense in it, and don't rely on it. In _this particular case_ there may be an explanation involving how memory is allocated to your program and compiler optimizations, but if you want to know more about that then you should investigate those topics specifically, not through some procedure that makes literally 0 guarantees on the result. – Max Langhof Oct 05 '18 at 11:15
  • @curiousgeek In theory we could spend a few weeks/months analysing your computer, your program, your compiler, your RAM sticks, and come up with a detailed explanation of why those particular bytes are shown for those particular elements at that particular time (because we live in a physical universe and ultimately there will be a scientific reason) ... but it's so immensely complicated and so immensely _pointless_ that nobody does that. We just observe that the standard says the values are unspecified/meaningless/arbitrary and move on! – Lightness Races in Orbit Oct 05 '18 at 11:21
  • I mean even the "values that happen to be there [at that part of virtual memory]" is not quite right - there's no reason to assume the values you see actually come from memory. They could be "hardcoded" artefacts of program optimisations, or really just about anything at all – Lightness Races in Orbit Oct 05 '18 at 11:22
  • @MaxLanghof Yes, I think your statement that it might be due to some compiler optimaztions is more satisfactory. What I could conclude is that It was not behaviour of cpp and manual initialization is required and there is no such thing like automatic initialization. I actually thought at first that it was due to compiler but I got to see same output even when I tried using diff. compilers and that was the root of all the confusion. – curiousgeek Oct 05 '18 at 11:24
  • @curiousgeek Ah, a good reminder not to assume that consistent behaviour means well-defined behaviour ;) – Lightness Races in Orbit Oct 05 '18 at 11:25
  • @LightnessRacesinOrbit Well said! Thanks for helping :) – curiousgeek Oct 05 '18 at 11:26
2

Because with:

a = new int[5];

You are not (default) initializing your array to zeros nor any other value as pointed out in the comments below. You are only allocating space for five ints on the free-store and printing out the values of an uninitialized array which is undefined behavior.

Initialize your array values to 0:

a = new int[5] {0};

or:

a = new int[5] {};

Or provide values for all the elements:

a = new int[5] { 1, 2, 14, 4, 5 };
Ron
  • 14,674
  • 4
  • 34
  • 47