On 27 February 2012 10:14, Hite, Christopher wrote: > From: Jonathan Wakely [mailto:jwakely.gcc@xxxxxxxxx] > >> N.B. I was forgetting the has_trivial_xxx traits were renamed/replaced by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html >> but GCC doesn't implement that yet. > Ok, so they're changing the names, but did they change the meaning? Yes. > Do they say wether a compiler's impl of is_trivially* is allowed generate false negatives? It is not allowed. >> I'm not sure, but I think std::is_trivially_default_constructible >> should be true for your optional<std::string> union, because although the default constructor is not trivial (in terms of the core language) it doesn't actually call std::string's constructor or any other non-trivial functions. > I think so to. The frustrating thing is I have to define the ctor/dtor even if they do nothing, but then they appear not to be trivial. > > >> Again, do-nothing and trivial are not the same thing. And a do-nothing constructor for a struct/class (which default-initiailizes bases and >> members) is not the same as a do-nothing constructor for a union (which does not initialize its members.) > I know. Theoertically the compiler could go through all base classes and members. By "do-nothing" constructor I really meant on that generates no code, directly or indirrectly. That's what is_trivially_xxx_constructible should detect. >> > Is there some proof that doing these things are impossible? >> Not that I know of, but I'd be surprised if is_trivially_xxx or the old has_trivial_xxx can be implemented without compiler magic. > Wow, I'm surprised too! Can you send me a link. Anything that detects trivial deconstruction seems like it would need magic. It talks about calling " any operation that is not trivial. " > http://en.cppreference.com/w/cpp/types/is_destructible Huh? A link to what? > What I don't get 100% is: > 1) wasn't this stuff supposed to be finished in the standard? It is finished. > 2) are the is_trvial* different from has_trivial* ? Yes, did you read the link I sent? > 3) does gcc need magic? Will it do the magic any time soon? Yes! They can't be implemented without compiler support. I don't know when that will be available.
