-7
#include <iostream>
#include <string>
using namespace std;


class CExample {
public:
  int a,b,c;
  void setvalue(int n, int m);
  void multiply() { 
  c = a*b;
  cout<< c <<endl;
  };
};

void CExample::setvalue(int n, int m){
  a = n; b = m;
}

int main( )
{

  CExample *d = new CExample[1];
  d[0].setvalue(2,30);
  d[0].multiply();
  d[1].setvalue(2,30);
  d[1].multiply();
  d[2].setvalue(2,30);
  d[2].multiply();
  delete[] d;
  return 0;
}

Since I have only allocate 1 Memory resource for Array d, I ought to encounter error when manipulating d[2]. However, the compiler didn't report error or warning. And the result is correct.

Can someone explain why it works?

Thanks

Yes, it is the magic of undefined behavior. Thanks for all of you.

DreamOn
  • 145
  • 1
  • 2
  • 9
  • 7
    The magic of undefined behavior. – Retired Ninja Jul 03 '14 at 00:12
  • The problem with manipulating memory that isn't yours isn't that it WILL break your program, the problem is no one has any idea what the outcome will be, so it may as well be broken. – Ben Jul 03 '14 at 00:15
  • Perhaps not a dupe, but good reading: http://stackoverflow.com/questions/15646973/how-dangerous-is-it-to-access-an-array-out-of-bounds – Retired Ninja Jul 03 '14 at 00:16
  • Your code has a bug, so of course it won't do what you expect. Fix the bug and the mystery will go away. – David Schwartz Jul 03 '14 at 00:16
  • access to unallocated space (`d[1]` and `d[2]`) is undefined; it could magically not work (think of it getting interrupted between `setvalue()` and `multiply()`). – rslemos Jul 03 '14 at 00:16
  • @user3342797 A comment is just that, a comment. Your code is incorrect and exhibits undefined behavior. It could do anything, including seem to work. – Retired Ninja Jul 03 '14 at 00:17
  • @RetiredNinja Yes, you are right. When I recompile and run it, it has raised the expected error. – DreamOn Jul 03 '14 at 00:26
  • @user3342797 I have flagged your comment on RetiredNinja's comment as not constructive (was deleted quickly apparently). **Never try to push anyone here to get off from your question!** All users have right, and you have currently the most little one here, to demand something from anyone here. **Be humble! Behave!** – πάντα ῥεῖ Jul 03 '14 at 00:28
  • @πάνταῥεῖ Sorry for any misunderstanding raised by me. I firstly didn't understand Retired Ninjia's comment. No offense. – DreamOn Jul 03 '14 at 00:32

3 Answers3

3

The C++ compiler can't and won't catch all the possible way you could write incorrect code.

And while running, a C++ program will usually not throw an error the moment you access memory out of bounds. The language was not designed to protect the programmer from doing bad things.

So when a program does something like this... which is undefined behavior... anything might happen. That "anything" can include appearing to work "correctly". Or weird behavior might appear right away. But either way it's wrong. If it appears to work, that's only by luck.

And in practice it will also likely be corrupting memory somewhere which will lead to other problems eventually. Maybe the problems don't have time to manifest in small example programs. But the larger the program, the more likely some kind of bad symptom will show up.

In the end, C++ puts a significant degree of responsibility on the programmer to write correct code which doesn't do things like going outside of array bounds.

TheUndeadFish
  • 8,058
  • 1
  • 23
  • 17
0

"Can someone explain why it works?" -- You believe the code works.

"I ought to encounter error when manipulating d[2]" -- You believe the code should do something other than what it does.

You are making two conflicting claims. You are saying both that the code works and that it should do something other than what it does. These cannot both be true.

As you know, your code has a bug. So it's not surprising that it doesn't do what you expect.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
  • Thanks for your help. I tried it before asking this question, and it magically work at that time. Then I re-compiled and run it, it encountered the expected error. Sorry for my reckless. – DreamOn Jul 03 '14 at 00:23
0
  1. You operate on a un-alloc memory, it's a undefined behavior.
  2. It's a run-time error, so compiler can't catch it. With valgrind, a memory check tool, you will get "Invalid write" errors.
where23
  • 483
  • 3
  • 9