Re: [lmi] libstdc++ in gcc-7.3.0: std::vector<incomplete_type>

[Greg Chicares]

On 2018-04-25 16:36, Vadim Zeitlin wrote:
> On Wed, 25 Apr 2018 00:45:58 +0000 Greg Chicares <address@hidden> wrote:
>
[...moved inlines out of line, and wroite an explicit dtor out of line,
but it still wouldn't compile...]
> 
>  Sorry, there is a third one, too.

I.e., replace implicit copy ctor with an explicit one written out of line.

I went back to the gcc messages I was staring at last night, and the best
interpretation I can come up with [highly edited to reduce size] is:

/c++/bits/stl_vector.h: In instantiation of '<wx_table_generator::column_info>'
/c++/bits/stl_vector.h:   required from
  std::vector<wx_table_generator::column_info>::vector(const std::vector<T>&)

I.e., a std::vector copy ctor couldn't be generated, and from that I am
to reason that the copy ctor of a class that contains such a vector cannot
be generated because it's implicitly declared. That seems like a non-obvious
deduction.

Is there a set of best practices that would have helped here?

In the C++98 era, I strove to implement all of a class's member functions
in the same file--either all inline in the '.hpp' file where they were
declared, or all out of line in a separate '.cpp' file--and especially to
keep all (implicit or explicit) ctors and dtors in one place or the other,
to make sure both were called from the same side of a DLL barrier. That
often meant declaring all special member functions explicitly, and defining
them with "{}" as the function body.

Here, we had to do something very similar. How much of my C++98 defensive
practice is still useful? Should any part of it be omitted, or anything new
be added? The only thing I'm fairly sure of is that "=default;" can now
replace "{}".