On Fri, Jul 26, 2013 at 6:18 PM, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> Jeffrey Yasskin <jyasskin_at_[hidden]> writes:
>
> [...]
>
> | (We do need to have the standard endorse using memcpy to set the
> | object representation of a trivially-copyable struct, but I don't hear
> | any disagreement about wanting that. I'll mail Ville about an EWG
> | issue.)
>
> Actually this is on my list of issues I would like to see SG12 discuss,
> and our first recommendation to forward to EWG+CWG at the Chicago meeting.

Oh, ok. I'll leave that to you then. :)

> | > People use the union hack because it is easy to program, given that it is
> | > mainly declarative. Declare a struct that corresponds to the layout of the
> | > data, cast the buffer pointer to the struct pointer, and it usually just
> | > works. If it isn't that easy, people will just keep using the union hack.
> |
> | That's ... not the union hack. The union hack is the thing that gcc
> | (http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-881)
> | and probably C99 endorse where you write one field of a union and read
> | a different field. Simply casting a char[] to a different type is
> | something else, which I hear more objections to simply allowing.
>
> In fact, I would prefer to see standards support -- either in form of
> library functions or in form of some language features or combination --
> for object and value representation as arrays of unsigned char, along
> with your bit_cast. My personal preference would be that over the
> "union hack".

SGTM, although I think the fact that gcc and C99 endorse the union
hack should push us to consider it strongly, in addition to memcpy.
(Your message is slightly ambiguous. Responding to one interpretation,
I'd think it was a shame if we insisted that people use a function
that didn't exist in C++14 in order to set the object representation
in C++17.)

> I am unconvinced we need to embark on a complete overhaul of the basic
> C++'s object model, where the outcome would be that one would talk of an
> object's value before it is ever constructed.

FWIW, there's some precedent for talking about an object's value
before it's constructed: [basic.start.init] says that static objects
are "zero-initialized before before any other initialization takes
place." The same sort of statement might work for discussing the
object representation of an object at the start of its constructor.

However, I think the compiler people who work on optimization will
complain loudly if they have to preserve the contents of the heap when
initializing an object, since it would prevent them from moving the
object to registers. So I'd endorse keeping the current behavior here
(becomes indeterminate), especially since nobody seems to stumble
across it on their own.

Jeffrey