lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vadim Zeitlin
Subject: Re: [lmi] "-Wundefined-func-template" warnings from clang
Date: Sun, 10 Jul 2022 13:59:36 +0200

On Sun, 10 Jul 2022 01:36:01 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 7/9/22 16:20, Vadim Zeitlin wrote:
[...]
GC> >  And this might be a good idea for the other reasons, as it seems like
GC> > defining the dtor inline triggers instantiation of this class when just
GC> > including tn_range.hpp, which seems wasteful, as it should be only enough
GC> > to instantiate it once when compiling tn_range_types.cpp.
GC> 
GC> That's an interesting point. To pursue it, I'd want to consider all
GC> similar instances throughout lmi, especially the other "= default"
GC> occurrences in the same file. Maybe we should generally prefer to
GC> write dtors out of line;

 This is recommended for the classes with virtual functions as the compiler
would then (or at least used to, maybe the compiler technology has advanced
since then) generate only a single copy of vtbl in the file defining the
dtor, whereas if the dtor is inline, the compiler needs to generate
multiple copies of the vtbl in all files including the class declaration
(this doesn't result in link errors because all these copies are weak
symbols and so only a single one of them is kept at the link stage).

GC> it becomes difficult to remember which C++ rules of thumb were valid in
GC> which decade.

 It's definitely still better to define the dtors inline for the
non-template value-like classes and not doing it is just an unnecessary
pessimization. But it's true that I hadn't realized that it might be worth
not doing it for the template classes myself (OTOH I still don't know if
it's actually true).

GC> But right now I have only five clang warnings that I haven't decided
GC> whether to disable, and my immediate goal is to investigate all of
GC> them.

 Good luck with this!
VZ

Attachment: pgpkGGiYEk6I5.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]