This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] Add __uninitialized_default*; use __is_trivial instead of __is_pod in most places
- From: Paolo Carlini <paolo dot carlini at oracle dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Thu, 17 Jun 2010 16:29:08 +0200
- Subject: Re: [v3] Add __uninitialized_default*; use __is_trivial instead of __is_pod in most places
- References: <4C19DF9E.4040506@oracle.com> <4C1A2DB8.2090702@redhat.com>
On 06/17/2010 04:14 PM, Jason Merrill wrote:
> On 06/17/2010 04:41 AM, Paolo Carlini wrote:
>> Some infrastructure for forthcoming C++0x work + finally got around to
>> use __is_trivial instead of the more restrictive __is_pod in many
>> places. About the latter in particular, I'm also adding in CC Jason -
>> implemented __is_trivial and briefly discussed with him the rather
>> straightforward plan of replacing most dispatches in the library based
>> on POD-ness to trivial-ness.
>
> Note that I've submitted an NB comment on the FCD suggesting that POD
> be changed from "trivial and standard layout" to "trivially copyable
> and standard layout" to make struct A { const int i; }; POD again.
Ok... That issue with POD, good. Thus the idea is resolving it by taking
out from POD-ness the trivial default bit... It seems to me then that,
post that kind of resolution, what we *had* before my patch would be
wrong, because we used to rely on the trivial default constructor. What
we have now, however, seems correct - maybe could be loosened a bit,
we'll see - but it seems correct, because if I understand correctly,
trivial itself is not going to change, thus still includes the trivial
default constructor bit.
Paolo.