[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