[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
Mon Feb 22 19:42:24 CET 2021
Dear Alexey,
On 22.02.21 19:19, Alexey Sheplyakov wrote:
> /me too. In fact I've got a patch which adds an explicit instantiation
> of exprseq::info() and removes dummy_func(). I haven't had a chance to
> test it with msvc yet.
Wouldn't it be just the same as in lst.*? That shouldn't need much
testing unless MSVC suffers borderline personality disorder, IMHO.
In any case, these lines of code can benefit from a good comment! (Case
in point: I was scratching my head way too long over this stuff.)
>> 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?)
>
> I don't quite like this idea. Let's keep the explicit instantiations,
> and suppress clang++ warnings for now.
Oh, I don't care very much about this compiler warning unless there is
something we can improve. (A #pragma isn't an improvement, I'ld say.)
> Making lst::info inline does not sound like a good idea either.
> For one any change in inline function typically requires SONAME
> bump [1], so there should be a pretty good reason to make
> a function/method inline. Usually it's the performance, not
> a (bogus) compiler warning.
Okay.
-richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>
More information about the GiNaC-devel
mailing list