On 06/28/2013 10:53 AM, monarch_dodra wrote:
> On Friday, 28 June 2013 at 17:30:58 UTC, Ali Çehreli wrote:
>> 1) C++ does not specify whether the stack gets unwound when the
>> program terminates with an uncaught exception. That's why I caught to
>> ensure that the stack objects would be destroy
On Friday, 28 June 2013 at 17:30:58 UTC, Ali Çehreli wrote:
On 06/28/2013 10:17 AM, Maxim Fomin wrote:
> Are you sure that the code is exact translation of
demonstrated D
> problem?
Sorry. I omitted two points.
> I see difference in argument passing order and your version
> uses try-catch bloc
On Friday, 28 June 2013 at 16:57:29 UTC, monarch_dodra wrote:
On Friday, 28 June 2013 at 16:50:07 UTC, Maxim Fomin wrote:
On Friday, 28 June 2013 at 16:01:05 UTC, monarch_dodra wrote:
I thought that was where you were getting to. Couldn't this
simply be solved by having the *caller*, destroy
On 06/28/2013 10:17 AM, Maxim Fomin wrote:
> Are you sure that the code is exact translation of demonstrated D
> problem?
Sorry. I omitted two points.
> I see difference in argument passing order and your version
> uses try-catch block.
1) C++ does not specify whether the stack gets unwound wh
On 06/28/2013 10:11 AM, Steven Schveighoffer wrote:
> On Fri, 28 Jun 2013 12:44:02 -0400, Ali Çehreli
wrote:
>>
http://www.boost.org/doc/libs/1_53_0/libs/smart_ptr/shared_ptr.htm#BestPractices
>>
>
> Thank you, I didn't know this.
Even though this issue is covered in Herb Sutter's Except
On Friday, 28 June 2013 at 16:44:03 UTC, Ali Çehreli wrote:
Ali
P.S. The C++ program that I have just used for testing:
Are you sure that the code is exact translation of demonstrated D
problem? I see difference in argument passing order and your
version uses try-catch block.
This code
#i
On Fri, 28 Jun 2013 12:44:02 -0400, Ali Çehreli wrote:
I just finished checking. No, C++ does not have this problem. But there
is the following related issue, which every real C++ programmer should
know. ;)
http://www.boost.org/doc/libs/1_53_0/libs/smart_ptr/shared_ptr.htm#BestPractices
On Friday, 28 June 2013 at 16:01:05 UTC, monarch_dodra wrote:
I thought that was where you were getting to. Couldn't this
simply be solved by having the *caller*, destroy the object
that was postblitted into foo? Since foo ends up not being
called (because of the exception), then I see no pro
On Friday, 28 June 2013 at 16:50:07 UTC, Maxim Fomin wrote:
On Friday, 28 June 2013 at 16:01:05 UTC, monarch_dodra wrote:
I thought that was where you were getting to. Couldn't this
simply be solved by having the *caller*, destroy the object
that was postblitted into foo? Since foo ends up no
On 06/28/2013 09:01 AM, monarch_dodra wrote:
> And I'm 99% sure C++ doesn't have this problem...
+1%. :)
I just finished checking. No, C++ does not have this problem. But there
is the following related issue, which every real C++ programmer should
know. ;)
http://www.boost.org/doc/libs/1_5
On Friday, 28 June 2013 at 15:33:40 UTC, Maxim Fomin wrote:
On Friday, 28 June 2013 at 15:17:12 UTC, monarch_dodra wrote:
Should I have expected a different behavior?
import std.stdio;
int callme()
{
throw new Exception("");
}
struct S
{
int i = 0;
this(int i){this.i = i; writeln(
On Friday, 28 June 2013 at 15:17:12 UTC, monarch_dodra wrote:
Should I have expected a different behavior?
import std.stdio;
int callme()
{
throw new Exception("");
}
struct S
{
int i = 0;
this(int i){this.i = i; writeln("constructing: ", i);}
this(this){writeln("postbliting: "
On Friday, 28 June 2013 at 15:12:01 UTC, monarch_dodra wrote:
On Friday, 28 June 2013 at 14:26:04 UTC, Maxim Fomin wrote:
[...]
I don't understand the problem... There *should* be two
destroyers... "main.s" is postblitted into "foo.s", and then
foo destroys "foo.s" at the end of its scope...
On Friday, 28 June 2013 at 14:26:04 UTC, Maxim Fomin wrote:
On Friday, 28 June 2013 at 08:08:17 UTC, monarch_dodra wrote:
Just in case it wasn't clear from the original explanation,
this is a bug, it *should* be perfectly safe to pass as many
temps as you want, and expect the right amount of
On Friday, 28 June 2013 at 08:08:17 UTC, monarch_dodra wrote:
Just in case it wasn't clear from the original explanation,
this is a bug, it *should* be perfectly safe to pass as many
temps as you want, and expect the right amount of destructor
called in case of a throw.
Original explanation
Am Fri, 28 Jun 2013 02:15:19 -0400
schrieb Nick Sabalausky :
> BTW, for anyone else reading, I just searched bugzilla and it looks
> like the relevant issue is #9704.
Reminds me of an issue I reported later:
http://d.puremagic.com/issues/show_bug.cgi?id=10409
--
Marco
On Friday, 28 June 2013 at 06:15:26 UTC, Nick Sabalausky wrote:
On Fri, 28 Jun 2013 07:11:05 +0200
"Maxim Fomin" wrote:
On Friday, 28 June 2013 at 04:54:56 UTC, Nick Sabalausky wrote:
> Probably a silly question, but I wanted to double-check...
>
> If you have this:
>
> struct Foo {...}
>
On Fri, 28 Jun 2013 07:11:05 +0200
"Maxim Fomin" wrote:
> On Friday, 28 June 2013 at 04:54:56 UTC, Nick Sabalausky wrote:
> > Probably a silly question, but I wanted to double-check...
> >
> > If you have this:
> >
> > struct Foo {...}
> > bar(Foo());
> >
> > Then regardless of optimizati
On Friday, 28 June 2013 at 04:54:56 UTC, Nick Sabalausky wrote:
Probably a silly question, but I wanted to double-check...
If you have this:
struct Foo {...}
bar(Foo());
Then regardless of optimizations (aside from any optimizer
bugs, of
course) the Foo temporary can't go out of scope
On Friday, 28 June 2013 at 05:11:11 UTC, Maxim Fomin wrote:
Struct dtor is always called in the end of the caller (bar in
example).
Callee of course.
20 matches
Mail list logo
