[GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-708-ga569b474

Richard B. Kreckel kreckel at in.terlu.de
Sun Feb 21 21:12:49 CET 2021


Dear Alexey,

I now tried building with MinGW-w64.

On 08.02.21 11:10, Alexey Sheplyakov wrote:
> There's a mistake in the commit message: the section of the standard
> which describes the explicit template specialization is 14.7.3.
> Everything else looks fine for me.
> 
>> I came across it because clang++ now complains:
>>
>> lst.cpp:41:37: warning: explicit instantiation of 'info' that occurs
>> after an explicit specialization has no effect
>> [-Winstantiation-after-specialization]
> 
> I don't quite understand the warning. What's the point of the explicit
> specialization **after** the thing has been already instantiated (either
> explicitly or implicitly)? And having an explicit specialization *after*
> the method has been implicitly instantiated is an error. I'll re-read
> 14.7 ("Template instantiation
> and specialization") once more, but for now I think clang++ is wrong, and
> we should ignore the warning. I.e. put something like this into lst.cpp:

Okay, it is indeed weird.

CLang++ complains about your explicit instantiation in lst.cpp:
    template bool container<std::list>::info(unsigned) const;
saying that the previous template specialization is in lst.hpp:
    template<> bool lst::info(unsigned inf) const;
which is merely a declaration.

So, CLang++ seems to miss the entire the point of the explicit
instantiation.

> // ignore bogus "explicit instantiation that occurs after an explicit
> specialization" warning
> #if defined(__clang__) &&
> __has_warning("-Winstantiation-after-specialization")
> #pragma clang diagnostic ignored "-Winstantiation-after-specialization"
> #endif
> 
>> Wouldn't it be sufficent to include "lst.h" in "integration_kernel.cpp"?

For the record: #including "lst.h" in "integration_kernel.cpp" as your
patch does is indeed enough for building with MinGW64.

> I think it's implementation defined. The definition of lst::info() is available
> in lst.cpp only, and nothing in that translation unit uses lst::info().
> Therefore the compiler is not obliged to instantiate lst::info() (although it's
> OK to do so). gcc and clang seem to instantiate it, but msvc needs the explicit
> instantiation (or something which triggers the implicit instantiation, like
> `dummy_func` in exprseq.cpp)

I would like to keep the lst.* and exprseq.* similar to make it easier
to read the code. (I had quite a hard time reading it.)

So I consider replacing the explicit instantiation in lst.* with the
dummy_func() trick in exprseq.*, or remove it altogether. (Do recent
versions of MSVC still need it?)

Best wishes,
  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>


More information about the GiNaC-devel mailing list