C++Talk.NET

glenlow@pixelglow.com · Guest

Hi All

Been following Hinnant, Dimov and Abraham's rvalue reference proposal
with some interest...

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html

Now it looks it will have de facto (if not yet de jure) acceptance into
C++ compilers:

Codewarrior (see comment on C++ library):
http://groups.google.com.au/group/comp.sys.mac.programmer.codewarrior/browse_thread/thread/e154f45f5b225bed/2dceedb61a9961e4#2dceedb61a9961e4

gcc:
http://gcc.gnu.org/ml/gcc/2005-07/msg00658.html (and follow-up).

Qns:

1. Is the N1377, N1690 etc. proposal already accepted for inclusion in
C++0x?

2. Are any of the other compilers accepting it, e.g. Visual C++,
Comeau, ICC?

Cheers,
Glen Low, Pixelglow Software
www.pixelglow.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Howard Hinnant · Guest

In article <1122964657.782608.4270 (AT) z14g2000cwz (DOT) googlegroups.com>,
[email]glenlow (AT) pixelglow (DOT) com[/email] wrote:

Mirek Fidler · Guest

Gabriel Dos Reis · Guest

Howard Hinnant <hinnant (AT) metrowerks (DOT) com> writes:

Joe Gottman · Guest

"Mirek Fidler" <cxl (AT) volny (DOT) cz> wrote

Howard Hinnant · Guest

In article <3laanjF11b3j6U1 (AT) individual (DOT) net>,
Mirek Fidler <cxl (AT) volny (DOT) cz> wrote:

Mirek Fidler · Guest

Howard Hinnant · Guest

In article <zWTHe.83714$3j2.2896451 (AT) twister (DOT) southeast.rr.com>,
"Joe Gottman" <jgottman (AT) carolina (DOT) rr.com> wrote:

Fuz · Guest

I believe there is an advantage in having the automatic generation of
move constructors. Take the following example:

template <typename T>
struct wrapper
{
T t;
};

wrapper<MovableType> will not have move semantics by default, as per
the proposal. This prevents certain optimisation opportunities, so the
author of wrapper<T> might decide to add an explicit move constructor:

template <typename T>
struct wrapper
{
T t;

wrapper(wrapper&& r) : t(r) {}
};

However, the introduction of the constructor prevents wrapper<PODType>
from ever being POD, which prevents (in the eyes of the Standard)
certain other optimisation opportunities, most notably: memcpy-ability
of an array of wrapper<T>.

Unless the explicit default-generation functions go ahead, and their
presence do not affect the PODness of a type, it seems to me that there
is no way of writing wrapper<T> so that it has the same traits as plain
T.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Howard Hinnant · Guest

In article <1123091595.975587.47190 (AT) g43g2000cwa (DOT) googlegroups.com>,
"Fuz" <srobb (AT) reflectionsinteractive (DOT) com> wrote:

Mirek Fidler · Guest

Fuz · Guest

Is it true that types with trivial copy constructors (but otherwise
non-POD) can be memcpy'd? I was always under the impression that only
PODs could be treated as a 'bag of bits' (certainly, that's the message
I've seen given by many experts on this subject). Personally, I think
that 'trivial copy' and 'trivial assign' suggests that's exactly what
can be done... it does exactly what it says on the tin. I can't
remember seeing that specified in the Standard, however.

Also, the addition of a constructor would also require the default
constructor of wrapper<T> to be defined in order to make it
default-constructable. This would prevent any
has_trivial_constructor<T> optimisations. Unless... is an
implementation allowed to 'see through' the definitions of the various
special member functions and give accurate trait information? e.g.:

template <typename T>
struct wrapper
{
test() {}
test(const test& r) : t(r.t) {}
test(test&& r) : t(std::move(r.t)) {}
test& operator=(const test& r) { x = r.t; return *this; }
test& operator=(test&& t) { t = std::move(r.x); return *this; }
~test() {}

T t;
};

// Do these fire?
static_assert(std::has_trivial_constructor<T>::value);
static_assert(std::has_trivial_copy<T>::value);
static_assert(std::has_trivial_move<T>::value);
static_assert(std::has_trivial_assign<T>::value);
static_assert(std::has_trivial_move_assign<T>::value);
static_assert(std::has_trivial_destructor<T>::value);

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Howard Hinnant · Guest

In article <1123178080.023202.320930 (AT) f14g2000cwb (DOT) googlegroups.com>,
"Fuz" <srobb (AT) reflectionsinteractive (DOT) com> wrote:

Fuz · Guest

Thanks, I suspected that was the case. Sad

Would the proposed
extensions to N1717 allow the correct traits to be generated? I would
hope that wrapper<T> could be written as:

template <typename T>
struct wrapper
{
test() { default }
test(const test&) { default }
test(test&&) { default }
test& operator=(const test&) { default }
test& operator=(test&&) { default }
~test() { default }

T t;
};

This would allow T's traits to drop through to wrapper<T> and pass all
the static_asserts mentioned previously.

And what about the memcpy-ing issue? Is has_trivial_copy enough to
ensure that you can create a whole load of new objects using memcpy?
Item 96 of C++ Coding Standards suggests that you need PODness, but you
(and Boost: http://www.boost.org/libs/type_traits#example ) suggest
that only a trivial copy is required, regardless of trivialness of the
other constructors and destructor. And I can't find anything in the
standard which specifies it one way or the other.

I still think this is on-topic, by the way; I don't want the explicit
generation of move constructors to break whether I can memcpy an object
or not. I think Mirek Fidler's suggestion of preventing the automatic
generation of a move constructor if other user-defined constructors
exist is a good idea, and mirrors the behaviour of the automatic
generation of a default constructor. Though (again) the extension of
N1717 to allow an explicit automatically-generated default constructor
which gives an accurate has_trivial_constructor<wrapper result is
still an attractive prospect.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Howard Hinnant · Guest

In article <1123245007.989224.311910 (AT) g43g2000cwa (DOT) googlegroups.com>,
"Fuz" <srobb (AT) reflectionsinteractive (DOT) com> wrote: