Boost page describing interleaved new expressions

Boost page describing interleaved new expressions

Post by Scott Meye » Fri, 25 Mar 2005 08:08:53


Consider this function call:

f(new Widget, new Widget);

Regardless of the prototype for f, this call can lead to resource leaks,
because compilers are allowed to interleave the execution of the two new
expressions. I know that Herb covers this in one of his books, but I'm
pretty sure I first ran into the discussion at a Boost web page. The
problem is, I can't find the page. I'm writing the acks for the third
edition of Effective C++, and I'd really like to track down the Boost page
that discusses this. Can anybody identify it for me?

Thanks,

Scott


[ See http://www.yqcomputer.com/ ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
 
 
 

Boost page describing interleaved new expressions

Post by Peter Dimo » Fri, 25 Mar 2005 20:45:14


http://www.yqcomputer.com/ #BestPractices

is one candidate.



[ See http://www.yqcomputer.com/ ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 
 
 

Boost page describing interleaved new expressions

Post by DavidAFerg » Fri, 25 Mar 2005 20:56:12

> Consider this function call:
leaks,
new
I'm
third
page

The 'Best Practices' paragraph of the shared_ptr docs seems like a good
canidate.

http://www.yqcomputer.com/ #BestPractices

The example given is a little more general, where an arbitray function
g()
(not necessarly another new expression) could throw before the smart
pointer
get ownership.

f(shared_ptr<int>(new int(2)), g());

David A. Ferguson <www.davidaferguson.com>


[ See http://www.yqcomputer.com/ ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
 
 
 

Boost page describing interleaved new expressions

Post by Carl Barro » Fri, 25 Mar 2005 20:57:56

In article < XXXX@XXXXX.COM >, Scott Meyers


is this the page?
http://www.yqcomputer.com/

[ See http://www.yqcomputer.com/ ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
 
 
 

Boost page describing interleaved new expressions

Post by Andrew Koe » Fri, 25 Mar 2005 23:54:33


Why does interleaving have anything to do with it? It seems to me that even
in the absence of interleaving, whenever the new-expression that is executed
second throws an exception, the one that was executed first must leak
memory. Even if f's parameters are smart pointers, I can't think of any
requirement that one argument be bound to its parameter before the other
argument is executed.


[ See http://www.yqcomputer.com/ ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
 
 
 

Boost page describing interleaved new expressions

Post by Hyman Rose » Sat, 26 Mar 2005 09:59:29


That's one reason I frequently maintain that C++ must be changed to fix
order of evaluation. In that happy event, each parameter would be bound
in left-to-right order and the expression would become exception-safe.

[ See http://www.yqcomputer.com/ ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
 
 
 

Boost page describing interleaved new expressions

Post by Ross Smit » Sat, 26 Mar 2005 09:59:51


Doesn't the C++ standard ban interleaving? (1.9 para 8)

--
Ross Smith ........ XXXX@XXXXX.COM ........ Auckland, New Zealand
"Romantics might like to think of themselves as being composed
of stardust. Cynics might prefer to think of themselves as
nuclear waste." -- Simon Singh

[ See http://www.yqcomputer.com/ ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
 
 
 

Boost page describing interleaved new expressions

Post by Scott Meye » Sat, 26 Mar 2005 19:58:25


Yes, that's what I meant, I just worded it poorly.

Thanks to all for the reference to the shared_ptr page. It was sitting
right there in front of me (including the references to Herb's writings,
which I also remembered), I just didn't recognize it.

Scott

[ See http://www.yqcomputer.com/ ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
 
 
 

Boost page describing interleaved new expressions

Post by galathae » Sat, 26 Mar 2005 20:11:55

could this functionality be added to stdmeta::?

to keep the backward compatible behavior, just add a metafunction
calls look like

function(stdmeta::ordered_eval(arg1, ...));

maybe, metacode might be a more natural environment
where the parsing knowledge of the order of parameters can be justified
to live

this could be wrapped in various other syntaxes if brevity is desired

as with any metacode function, ordered_eval would return a translation
time error if the environment being translated to cannot make such
guarantees

does your experience with the parties participating in the
standardisation process indicate that such a proposal would be seen as
a fair compromise to backward compatability?


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

galathaea: prankster, fablist, magician, liar


[ See http://www.yqcomputer.com/ ]
[ comp.lang.c++.moderated. First time posters: Do this! ]