octave-maintainers
[Top][All Lists]
Advanced

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

Re: Comparison with NaN


From: Jaroslav Hajek
Subject: Re: Comparison with NaN
Date: Sun, 17 May 2009 21:31:07 +0200

On Sun, May 17, 2009 at 8:59 PM, Michael Goffioul
<address@hidden> wrote:
> On Sun, May 17, 2009 at 6:18 PM, Jaroslav Hajek <address@hidden> wrote:
>>>> In any case, I see no clear way out. We could possibly avoid the
>>>> situation in ov-typeinfo.cc and similar, but I see, for instance no
>>>> way to avoid the references to various array instances from
>>>> Array-tc.cc, even if we change #include oct-obj.h to ov.h (which
>>>> should probably be done).
>>>
>>> For that specific case, changing the include statement is enough.
>>> Then it compiles fine.
>>>
>>
>> How is that possible? Why MSVC does not implicitly instantiate
>> Array<double>, Array<Complex> and other instances referenced from
>> within ov.h?
>> How does the situation differ from the one you previously reported for
>> Array-C.cc referencing dMatrix.h?
>
> 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?

>>> 1) implicit instantiation due to dllexport-ed classes, when Array.cc is
>>> included, and Array<T> cannot be fully instantiated as T does not support
>>> the required operations (typical example, oct-stream.cc and 
>>> Array<octave_value>
>>> instantiation); one solution is to avoid the inclusion of the offending 
>>> header,
>>> when possible
>>
>> What I don't understand is why you don't see the problem in other
>> places. Suppose that in liboctave, Array-C.cc gets compiled first.
>> Array<T> itself references Array<octave_idx_type> (Array<T>::sort,
>> sortrows, find). So why does not MSVC implicitly instantiate
>> Array<octave_idx_type> in Array-C.cc? Or does it? If yes, then why the
>> linker doesn't mind? Does the linker perform some magic? Even if the
>> latter was true, in the recent sources even *compiling* an implicit
>> instance should fail. I just don't understand the difference between
>> this case and referencing Array<double> from Array-C.cc.
>
> The problem was the inclusion of dMatrix.h, forcing the instantiation
> of Array<double> with all members known at that point. This resulted
> in a non-specialized version of sort_isnan being emitted, picked up
> by the linker at link time and exported (instead of the specialized one).
>
> In normal situation, I think you can get various instantations of the same
> template in several object files, and the linker just picks up the first one
> for export.

In the GCC docs, I think this is referred to as "the Borland model",
supported by g++ on ELF systems, but it's mentioned that a future aim
is to create something more smart.

> 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.

Of course, nobody actually tested the possible slowdown, it's just
what I (we) expect.

cheers

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


reply via email to

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