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("constructing: ", i);}
>     this(this){writeln("postbliting: ", i);}
>     ~this(){writeln("destroying: ", i);}
> }
>
> void foo(S s, int i)
> {
>    s.i = 2;
> }
>
> void main()
> {
>    S s = S(1);
>    foo(s, callme());
> }
>
> Destructor for copied object is not called because it is placed in foo(). Before calling foo(), dmd makes a copy of main.s, calls postblit, then puts code to invoke callme() and code to invoke foo(). Since callme() throws, foo() is not called and destructor placed in foo() is also not called. A struct copy escapes destructor.
>
> Now, if you try fix this by putting dtor for copy not in foo(), but in main immediately after foo() invocation, you will have a problem because destructor would get S(1) object while it should destroy S(2). Any modification made in foo() is lost. This can be possible fixed by passing copy by reference which would probably create new ABI problems.

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 problem having the caller destroy the "to-be-passed-but-ends-up-not" object?

Basically, it would mean creating a "argument scope" into which each arg is constructed. If something throws, then the "up to now built args" are deconstruted just like with standard scope. If you reach the end of the scope, then call is made, but passing the resposability of destruction to foo.

EG, pseudo code:

memcpy_all_args;
try
{
    foreach arg in args:
        arg.postblit;
        exit(failure) arg.destroy;
}
call_foo;

Isn't that how C++ does it? In terms of passing args by value, I see no difference between CC and postblit... And I'm 99% sure C++ doesn't have this problem...

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_53_0/libs/smart_ptr/shared_ptr.htm#BestPractices

Ali

P.S. The C++ program that I have just used for testing:

#include <iostream>
#include <stdexcept>

using namespace std;

int callme()
{
    throw runtime_error("");
    return 0;
}

struct S
{
    int i_;

    S(int i)
        :
        i_(i)
    {
        cout << "constructing: " << i_ << " at " << this << '\n';
    }

    S(const S & that)
    {
        cout << "copying: " << that.i_ << " to " << this << '\n';
        i_ = that.i_;
    }

    ~S()
    {
        cout << "destroying: " << i_ << " at " << this << '\n';
    }
};

void foo(int i, S s)
{
   s.i_ = 2;
}

int main()
{
    S s = S(1);

    try {
        foo(callme(), s);

    } catch (...) {
        cout << "caught\n";
    }
}

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 problem having the caller destroy the "to-be-passed-but-ends-up-not" object?

In case when there is no exception, struct argument is passed and is modified in callee, destructor in caller would have unchanged version (because structs are passed by value).

> Basically, it would mean creating a "argument scope" into which each arg is constructed. If something throws, then the "up to now built args" are deconstruted just like with standard scope. If you reach the end of the scope, then call is made, but passing the resposability of destruction to foo.

This is another option but suffers from the same problem (in posted examples exception is always thrown, but in reality it need not to).

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 not being called (because of the exception), then I see no problem having the caller destroy the "to-be-passed-but-ends-up-not" object?
>
> In case when there is no exception, struct argument is passed and is modified in callee, destructor in caller would have unchanged version (because structs are passed by value).

I'm saying the "callee" destroys whatever is passed to it, all the time, but that means "callee" needs to actually be called.

If "caller" constructs objects, but then fails to actually call "callee", then caller *has* to be responsible for destroying the objects it has built, but not passed to anyone. But this is only if an exception is thrown:

No exception:
  Caller constructs objects into foo.
  foo is called, foo becomes owner of objects.
  foo finishes.
  foo destroys object.

Exception:
  Caller starts construction.
  Exception is thrown.
  Caller destroys objects as exception is propagating.
  All objects are destroyed, exception goes up.

On Fri, 28 Jun 2013 12:44:02 -0400, Ali Çehreli <acehreli@yahoo.com> 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

Thank you, I didn't know this.  I can consider myself a "real" C++ programmer now :)

-Steve

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

#include <iostream>
#include <stdexcept>

using namespace std;

int callme()
{
    throw runtime_error("");
    return 0;
}

struct S
{
    int i_;

    S(int i)
        :
        i_(i)
    {
        cout << "constructing: " << i_ << " at " << this << '\n';
    }

    S(const S & that)
    {
        cout << "copying: " << that.i_ << " to " << this << '\n';
        i_ = that.i_;
    }

    ~S()
    {
        cout << "destroying: " << i_ << " at " << this << '\n';
    }
};

void foo(S s, int i)
{
   s.i_ = 2;
}

int main()
{
    S s = S(1);
    foo(s, callme());

}

prints for me:

constructing: 1 at 0x7fffb93078d0
terminate called after throwing an instance of 'std::runtime_error'
  what():
Aborted

On 06/28/2013 10:11 AM, Steven Schveighoffer wrote:

> On Fri, 28 Jun 2013 12:44:02 -0400, Ali Çehreli <acehreli@yahoo.com> 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 Exceptional C++ book, which I had read with great interest, I re-learned it last year when a colleague showed that link to me.

I have always considered C++ a language where mere-mortals like myself must read lots and lots of books to advance (or to write any decent code). This thread makes me think that D is following in C++'s steps. I am too normal to figure out these corner cases myself. :-/

Ali

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 when the program terminates with an uncaught exception. That's why I caught to ensure that the stack objects would be destroyed.

2) C++ does not specify in what order function arguments are evaluated. I swapped the parameters because I used gcc under Linux, where the parameters are executed from right-to-left.

Ali

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 block.
>
> 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 destroyed.

Doesn't it? The stack needs to be unwound for the exception to even "escape". It's merely the globals that may not be destroyed. (AFAIK)

> 2) C++ does not specify in what order function arguments are evaluated. I swapped the parameters because I used gcc under Linux, where the parameters are executed from right-to-left.
>
> Ali

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 the object that was postblitted into foo? Since foo ends up not being called (because of the exception), then I see no problem having the caller destroy the "to-be-passed-but-ends-up-not" object?
>>
>> In case when there is no exception, struct argument is passed and is modified in callee, destructor in caller would have unchanged version (because structs are passed by value).
>
> I'm saying the "callee" destroys whatever is passed to it, all the time, but that means "callee" needs to actually be called.
>
> If "caller" constructs objects, but then fails to actually call "callee", then caller *has* to be responsible for destroying the objects it has built, but not passed to anyone. But this is only if an exception is thrown:
>
> No exception:
>   Caller constructs objects into foo.
>   foo is called, foo becomes owner of objects.
>   foo finishes.
>   foo destroys object.
>
> Exception:
>   Caller starts construction.
>   Exception is thrown.
>   Caller destroys objects as exception is propagating.
>   All objects are destroyed, exception goes up.

In this scenario caller should distinguish between two situations: exception was thrown during arguments evaluation or was thrown somewhere in foo, when callee can call destructor for passed argument. Otherwise (for example, using current scope(failure) mechanism to tackle the problem), destructor would be called twice on same struct - first time inside callee as usual, second time - in caller which would think that exception was thrown during argument evaluation. I think some tweak required here, but this sound like a good solution.