Thread: auto_ptr array

Let us know if you have found definite result from standard whether the code in post #11 is exception safe or not? To my point of view, I think it should be safe.

He did ("Yeah, no such thing there.") and I agree with him. The code is not guaranteed to be exception safe.

Originally Posted by George2

For code in post #11, we think it is implementation defined whether or not it is exception safe?

And that, by definition, makes it unsafe. If it's not guaranteed to be safe, then it's not safe.

--
Mats

Originally Posted by George2

For code in post #8, we are definitely sure it is not exception safe?

I believe the verdict was "won't compile".

For code in post #11, we think it is implementation defined whether or not it is exception safe?

No, the implementation is under no obligation to define anything here. It's unspecified, and may change from one compilation to the other, based on some totally unrelated changes that change the way the optimizer reasons about the code.

Originally Posted by George2

Thanks CornedBee,

Interested. In my normal senses, the code in post #11 should not leak. If you know any compiler which will leak memory in code sample in post #11, please let me know. :-)


regards,
George

Well, it won't leak unless you are low on memory, but there's (according to the previous discussion) no guarantee that the compile produces the actual auto_ptr immediately as it's allocating the memory for it, so you may end up with a dangling pointer if you have an exception during the initialization of the array. And as Cornedbee says: It may change at a whim of the compiler, e.g. you change the options, the code generator thinks the function is "too complex", so it uses a different set of rules for the "too complex" function compared to a simple function [because you added an extra if-statement at the end of the code, for example].

--
Mats

Originally Posted by George2

Memory leak has nothing to do with whether memory is low or not?

Of course it does. Say you manage to allocate 5 of the object, then new fails because there's not enough memory, the rest of the pointers will leak unless assigned to the auto_ptr, which it is not guaranteed to do.

3. I do not understand your "if-statement" sample, can you show the code?

Mats was making a general statement. Meaning that the behavior could be different just because you added or removed a line of code.

Originally Posted by George2

Thanks Mats,


Three more comments,

1.



Memory leak has nothing to do with whether memory is low or not?

Well, not technically, but the only reason it would leak is if your function exits before the auto_ptr's constructor has been called - and this will only happen if new throws, which normally only happens if you're running out of memory (or something has gone wrong with the heap).

2.



"Dangling pointer" means, if compiler decides to allocate memory before constructing auto_ptr, and exception in the middle before constructing auto_ptr, no pointer pointed to the allocated memory, so this is what you mean "Dangling pointer"?

Yes.

3.



I do not understand your "if-statement" sample, can you show the code?


regards,
George

Well, the example I was making is if the compiler counts the number of basic-blocks (e.g. if/else branches etc) and then decides which of several code-generation functions to use. So adding an extra if-statement for example, will perhaps push it into "code-generation function 2" instead of "code-generation function 1".

--
Mats

Originally Posted by George2

In my senses, I think when we say exception safety, it means code should not leak memory in any situation based on ensurance of defined behavior of underlying SDK, e.g. we assume delete never throws. It has nothing to do with environment.

I think that sums it up. Exception safety should mean that under no ciruimstance should memory leak or a class be left in a zombie state. Which means avoiding all undefined behaviors,

2. Any comments to my item 2 in post #23?

Mats already told you.

Originally Posted by George2

You mean compiler has some different internal functions, which for examples handles if-block and non-if block separately?

Maybe. How a compiler works is a mystery to most programmers. You don't know what it does. It's a black box. You put in source on one end and get out object code on the other. Much can happen in-between.