kenneth wrote:
On Oct 5, 10:41 pm, Hyman Rosen <hyro...@mail.com> wrote:
How about that in the following code
#include <memory>
typedef std::auto_ptr<int> api;
void f(api, api) { }
int main() { f(api(new int(1)), api(new int(2))); }
it is not guaranteed that all successfully allocated memory
is freed when one of the allocations throws an exception?
Yes, it is. At least it should be, despite some buggy implementations.
What the standard says is that, given the code above, you cannot
assert which comes before which, new int(1) or new int(2). But note
that these are two completely independent operations, and as such we
give the compiler (actually the compiler implementer) complete freedom
to choose any order it finds suitable. If I were to use the allocated
values before a sequence point (cutting the shit, I mean the
semicolon; or something like that), then that value would be "undefined".
It might be the secret of life (I've heard it is 42), or just plain
garbage.
I don't mean to rag on you particularly, but thank you for
illustrating my point that people don't understand order of
evaluation issues, and that they should be removed from the
language.
Here's what you missed. According to the standard, one
permissible order of evaluation for the expression is
call ::operator new int (resulting in p2)
initialize *p2 with 2
call ::operator new int (resulting in p1)
initialize *p1 with 1
create an auto_ptr argument a1 to f initialized with p1
create an auto_ptr argument a2 to f initialized with p2
call f
destruct a2
destruct a1
If the second call to ::operator new throws an exception,
pointer p1 will never be deallocated in this scenario because
the auto_ptr which was supposed to do that hasn't yet been
created. Yes, this is a standard-conforming possibility. Hard
to believe, isn't it?
true issue. <g>. The problem isn't order of evaluation; it's sequence
points. Yes, forcing order of evaluation would eliminate the problem,
but there are less drastic language-level solutions, as well.
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
[ comp.lang.c++.moderated. First time posters: Do this! ]