C++ Logo

SG12

Advanced search

Subject: Re: [ub] type punning through congruent base class?
From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 2014-01-16 16:28:39


| -----Original Message-----
| From: ub-bounces_at_[hidden] [mailto:ub-bounces_at_[hidden]] On
| Behalf Of James Dennett
| Sent: Thursday, January 16, 2014 12:06 PM
| To: WG21 UB study group
| Subject: Re: [ub] type punning through congruent base class?
|
| On Thu, Jan 16, 2014 at 12:00 PM, Gabriel Dos Reis <gdr_at_[hidden]>
| wrote:
| >
| >
| > | -----Original Message-----
| > | From: ub-bounces_at_[hidden] [mailto:ub-bounces_at_[hidden]] On
| > | Behalf Of Herb Sutter
| > | Sent: Thursday, January 16, 2014 11:50 AM
| > | To: WG21 UB study group
| > | Subject: Re: [ub] type punning through congruent base class?
| > |
| > | > Well, as far as I understand, trivial constructors might not be called at
| all.
| > |
| > | Maybe "might not be called" is part of the bug then. Isn't the right model
| that
| > | trivial ctors are called, but "might do nothing"?
| >
| > Yes, agreed.
|
| That may be part of a proposed model, but it's not part of the
| existing model, which (for compatibility) is based on C's model, where
| fields of a (necessarily trivially-constructible) struct can be
| written to as soon as suitable memory for that struct is obtained.

There is only one person who knows what he wanted with he original model (see CC:) and I'm not speaking for him, nor am I pretending to.
However, based on extended past discussions on this very subject I suspect that the current wording does not reflect what is supposed to happen - and I suspect, based on this thread, that sentiment is shared by other people as well.

| If C++ weren't based on C, it would likely have a model where you
| could not access an object without an initialization operation to
| create an object from raw memory.

But it is not clear that the fact that it is based on C means the current wording is what want. I don't believe it is what the original author of C++ wanted.

| But C allows use of raw memory as
| objects, and I don't hear anyone suggesting how we can accommodate
| that while avoiding its horrible consequences. We could choose _not_
| to accommodate it (i.e., require the initialization step that creates
| an object from raw memory), but it's a significant change that
| invalidates massive amounts of existing code.

-- Gaby


SG12 list run by herb.sutter at gmail.com