Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c++ > #536

Re: C++11 Rvalue-references

Show all headers | View raw

On Monday, June 25, 2012 2:49:57 AM UTC-4, Dave Harris wrote:
...
>
> As far as I can tell, the main semantic difference is that with your
> proposal, objects are not always destroyed. This seems error prone.
> For example:
>
>    void MyClass::demo( std::temp<Arg> &arg ) {
>        this->p = new int;
>        this->arg = arg;
>    }

I don't see how this issue is any different from an exception being
thrown in a destructor.  You just have to handle it.  Sentries and
catch/rethrow are the methods I'm aware of.

>
> If the new expression throws an exception, should the compiler delete
> the argument or not? At the point of call, the compiler doesn't know
> whether arg is moved before or after the throw.

No it must not, the function must still be equivalent to destruction,
even if an exception occurs.

>
> What about composite objects?
>    this->a = static_cast<std::temp<Arg> &>(other.a);
>    this->b = other.b;
>
> Does other get destructed or not?

I don't directly address this but I think what I wrote clearly implies
it does get destructed.  The compiler would not insert at call to
this->a anyway, so the cast is moot.

>
> The C++11 rule, that objects are always destroyed, actually seems
> simpler to me. It is easier to reason with. It's more obvious what
> will happen in more situations. Your approach was considered but
> abandoned quite early; for example, it is discussed and rejected
> in this 2002 paper by Hinnant, Dimov and Abrahams:
>  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm
>
> Look for "Alternative move designs" and "Destructive move semantics".

Exceptions to rules are bad unless there is good motivation for them.
(If you get too down on exceptions to rules, you'll go back to using C
:) .)  I don't see where the paper mentions anything similar to what I
have proposed.

>
> >From a syntactic point of view, what you suggest seems more verbose.
> I also don't see any benefit from dressing the new rules in old
> clothes.

My approach allows for more optimization.  This is dangerous, like
casting, so it would be consistent to make it verbose like casting.
The use of template-like syntax also follows the casting precedent.

I can't think of a quick example, but I would think that it is a
natural thing to do with templates, to create a "synonym type" for an
existing type to trigger different treatment of objects without
changing the intrinsic behavior of the object.  So the
"pseudo-class-template" seems natural.  A reference allows a pointer
id for an object to be used with the same syntax as the object's name.
 To create a third type of pointer syntax to get different treatment
of objects just seems icky somehow.

...


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Back to comp.std.c++ | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

C++11 Rvalue-references W Karas <wkaras@yahoo.com> - 2012-06-17 18:26 -0700
  Re: C++11 Rvalue-references brangdon@cix.compulink.co.uk (Dave Harris) - 2012-06-24 23:49 -0700
    Re: C++11 Rvalue-references W Karas <wkaras@yahoo.com> - 2012-06-28 13:23 -0700
      Re: C++11 Rvalue-references brangdon@cix.compulink.co.uk (Dave Harris) - 2012-06-29 12:15 -0700
      Re: C++11 Rvalue-references Jason McKesson <jmckesson@gmail.com> - 2012-06-29 12:16 -0700

csiph-web