octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comparison with NaN


From: Michael Goffioul
Subject: Re: Comparison with NaN
Date: Sun, 17 May 2009 22:25:45 +0100

On Sun, May 17, 2009 at 8:31 PM, Jaroslav Hajek <address@hidden> wrote:
>> In Array-C.cc, the problem was that dMatrix.h defined a dllexport-ed class
>> inheriting from Array<double>, causing forced instantiation. . In 
>> Array-tc.cc,
>> all classes coming from liboctave are dllimport-ed (not dllexport-ed), so no
>> forced instantiation occurs. However, it includes Cell.h (through oct-obj.h),
>> which defines a dllexport-ed Array<octave_value> inherited class; hence
>> forced instantiation of Array<octave_value>.
>>
>
> Oh, now I get it, thanks! So the problem only occurs when referencing
> classes marked OCTAVE_API, right?
> Hmm. Suppose we do the config check for "extern template" ability.
> Would it help to include "extern template Array<double>" declaration
> in dMatrix.h and similar decls in other headers?

It helps in the case 2) reported earlier (for instance it's used in
Array-os.cc).
But it does not help in case 1). You cannot mix "extern template" and dllexport
on the same class.

>> This is usually not a problem as those instantiations are
>> the same (templates are usually entirely in the header and inlined).
>>
>
> I think we talked about that, but the drawback is that such an
> approach puts an unpleasant amount of code to headers, slowing down
> compilation (which is already quite slow). In general, I think that
> it's best if only methods that are supposed to be inlined (at least
> sometimes) have their code directly in header files, similarly to what
> you do if templates aren't involved.
> Further, keeping the implementation separate may avoid some
> unnecessary dependencies of header files.

And I think it's a good thing. MSVC is tricky due to its model of
exporting symbols on top of template instantiation, but up to now
I could find a workaround each time. I'm fine with that.

Michael.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]