Re: [lmi] default-member-initializers vs. is_trivial

[Vadim Zeitlin]

On Sun, 18 Apr 2021 22:50:29 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> Vadim--Do you happen to know why default member initializers
GC> prevent a default ctor from being trivial?

 Sorry if I'm missing something here, but for me "trivial" informally means
"doing nothing" and, I believe, this is exactly what the C++ Standard says in
a more formal way. I.e. a class with a trivial default ctor is like a POD C
struct -- its ctor just does nothing at all.

 And, clearly, if the ctor initializes its members -- as it has to do, if
they do have initializers -- it must do something, and so can't be trivial.

 This reads very tautologically, but isn't it the point? I.e. it's not
trivial because it can't do nothing while doing something.

GC> but I'd like to understand the purpose of that particular requirement.
GC> If the reason is that a default member initializer might throw, then
GC> a constexpr value could surely be allowed. For example, given
GC>   struct foo{int i {1};};
GC> shouldn't a compiler be able to default-construct a 'foo' quite easily?

 It probably can, but "easily" is not the same as "trivially".


GC> Anyway, commit 10299f32061c6 attempts to show why I agonized over this.
GC> Is it capricious for me to ignore is_trivially_default_constructible-ness
GC> and forge blithely ahead, figuring that the compiler can optimize this
GC> parameter-object well enough already? I'm tending to think that providing
GC> default member initializers is a best practice, but I don't see why I
GC> should care about trivial-constructibility of this object when it's
GC> already trivially copyable and moveable.

 I don't see neither. IMO this commit is perfectly fine and I don't think
we need to worry about any performance implications here unless profiling
results (unexpectedly) show that there are any.

 To get an idea of the upper bound of the possible pessimization due to
this change, I'd compare the time needed to resize() a vector of
gpt_scalar_parms before and after this change. However if the size of such
vector is still limited to O(100) elements, as you've mentioned before, I'm
quite sure there is not going to be any noticeable effect anyhow (with a
million elements there might be though).

GC> I found this article interesting:
GC>   https://foonathan.net/2021/03/trivially-copyable/
GC> but all I've been able to conclude from it so far is that "triviality"
GC> is deeper than I had imagined, and that I don't really understand it.
GC> Am I missing something important?

 My personal feeling is that tests such as is_trivially_xxx() are only
useful when writing low-level classes working with raw memory, e.g. when
implementing std::vector. Using them is complicated and error-prone and
another recent blog post shows that even standard library (libc++ in this
case, but I'm sure it's not limited to them only) writers make mistakes
when doing it:

https://quuxplusone.github.io/blog/2021/04/17/pathological-string-appends/

So my first advice would be to not use them in our own code at all because
we probably don't need them anyhow. And you probably won't need my second
advice due to the first one...

 Sorry if all this is not very helpful, but it just seems to me that there
is nothing to worry about here. But, again, please let me know if you think
I'm missing something -- finding new reasons to worry is always exciting.

 Thanks,
VZ

pgpdPyWpc9v73.pgp
Description: PGP signature