[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