Re: [lmi] "-Wundefined-func-template" warnings from clang

[Greg Chicares]

On 7/9/22 16:20, Vadim Zeitlin wrote:
> On Thu, 7 Jul 2022 22:38:48 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> clang-13.0.1-6 gives numerous warnings when this option is enabled.
> GC> Here's one example:
[...snipped...]
> GC> The intention was indeed to instantiate some things explicitly in
> GC> a single translation unit, in the hope of making compilation more
> GC> efficient with 1990's compilers on 1990's hardware.
> GC> 
> GC> Is this an actual problem that calls for action?
> 
>  I don't think there is any actual problem here, if the function were
> really undefined, there would be a linker error. For the same reason, I
> somewhat struggle to find a reason to use this warning in the first place.

Thanks. I've kept the warning disabled, linking to this discussion
as the explanation.

>  However if you'd like to keep it enabled, it seems like it would be simple
> enough to work around this occurrence of it by simply moving the destructor
> definition to the implementation file like this:
[...snip patch...]

That fixes this particular warning, but then other warnings arise
with respect to the same header.

I tried fixing warnings in 'mc_enum_test' piecemeal, but every time
I chopped off one head, at least one more grew in its place. It seemed
unwise to follow that road farther. My impression is that clang, with
this warning enabled, wants declarations of every instantiation in each
file that uses any; but in 'mc_enum_test.cpp' I've already written:

  // Enumerative types 'e_holiday' and 'e_island' are explicitly
  // instantiated in a different translation unit.

which is all I want to say in that file. As you point out, finding
those explicit instantiations elsewhere is the linker's job, and if
they aren't found, the linker will tell us. I don't feel an urge to
write code to help the compiler anticipate whether the linker will
succeed.

>  And this might be a good idea for the other reasons, as it seems like
> defining the dtor inline triggers instantiation of this class when just
> including tn_range.hpp, which seems wasteful, as it should be only enough
> to instantiate it once when compiling tn_range_types.cpp.

That's an interesting point. To pursue it, I'd want to consider all
similar instances throughout lmi, especially the other "= default"
occurrences in the same file. Maybe we should generally prefer to
write dtors out of line; it becomes difficult to remember which
C++ rules of thumb were valid in which decade. But right now I have
only five clang warnings that I haven't decided whether to disable,
and my immediate goal is to investigate all of them.