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

[Vadim Zeitlin]

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:
GC> 
GC> In file included from /opt/lmi/src/lmi/custom_io_1.cpp:31:
GC> In file included from /opt/lmi/src/lmi/input.hpp:37:
GC> /opt/lmi/src/lmi/tn_range.hpp:243:5: error: instantiation of function 
'tn_range<int, age_trammel<int>>::read' required here, but no definition is 
available [-Werror,-Wundefined-func-template]
GC>     ~tn_range() override = default;
GC>     ^
GC> /opt/lmi/src/lmi/tn_range.hpp:272:19: note: forward declaration of template 
entity is here
GC>     std::istream& read (std::istream&) override;
GC>                   ^
GC> /opt/lmi/src/lmi/tn_range.hpp:243:5: note: add an explicit instantiation 
declaration to suppress this warning if 'tn_range<int, age_trammel<int>>::read' 
is explicitly instantiated in another translation unit
GC>     ~tn_range() override = default;
GC>     ^
GC> 1 error generated.
GC> 
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.
In principle, it might be useful to receive it earlier, at compilation
stage, with more details, rather than later, at link stage, without them,
but in practice I think link errors due to missing functions are so rare
that it's practically never going to happen -- and if it does, it still
wouldn't be catastrophic at all.

 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:
---------------------------------- >8 --------------------------------------
diff --git a/tn_range.hpp b/tn_range.hpp
index d6cf71807..524cb798d 100644
--- a/tn_range.hpp
+++ b/tn_range.hpp
@@ -240,7 +240,7 @@ class tn_range final
     tn_range();
     explicit tn_range(Number);
     explicit tn_range(std::string const&);
-    ~tn_range() override = default;
+    ~tn_range() override;

     tn_range& operator=(Number);
     tn_range& operator=(std::string const&);
diff --git a/tn_range.tpp b/tn_range.tpp
index 578a7d79c..59482a5f8 100644
--- a/tn_range.tpp
+++ b/tn_range.tpp
@@ -384,6 +384,9 @@ tn_range<Number,Trammel>::tn_range(std::string const& s)
     trammel_.assert_sanity();
 }

+template<typename Number, typename Trammel>
+tn_range<Number,Trammel>::~tn_range() = default;
+
 template<typename Number, typename Trammel>
 tn_range<Number,Trammel>& tn_range<Number,Trammel>::operator=(Number n)
 {
---------------------------------- >8 --------------------------------------

 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.

 But I didn't make any measurements to confirm if it's really worth doing
this or looked at the other instances of this warning occurrence -- please
let me know if you think it would be worth doing either or both.

 Thanks,
VZ

pgpgnPZYRqpyZ.pgp
Description: PGP signature