Re: Comparison with NaN

[Michael Goffioul]

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

>> 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. This is usually not a problem as those instantiations are
the same (templates are usually entirely in the header and inlined).

Michael.