Re: Comparison with NaN

[Jaroslav Hajek]

On Sun, May 17, 2009 at 6:30 PM, Michael Goffioul
<address@hidden> wrote:
> On Sun, May 17, 2009 at 4:44 PM, Jaroslav Hajek <address@hidden> wrote:
>> OK, I see.
>> With the recent changes I uploaded, an implicit instantiation of
>> Array<T> in a unit #including Array.cc that does not occur via
>> INSTANTIATE_ARRAY should fail to compile due to
>> Array<T>::instantiation_guard, so you may start seeing a number of
>> errors.
>> I should note that there is no error with gcc; somehow, gcc seems to
>> do precisely what we need, i.e. implicitly instantiates only the
>> interfaces (stuff from Array.h) even when Array.cc is #include, which
>> is nice. I do not, however, understand why it does so, or whether it
>> is required to always do so, which is less nice :(
>
> From my experience, MSVC behaves like GCC regarding template
> instantiation (only instantiates the required parts), except when dllexport
> comes into play. When a class inheriting from some template is
> dllexport-ed, then MSVC instantiates automatically *all* known
> members of the template class, whether they are used or not. This
> "makes sense" in the context of how MSVC exports (or does not
> export) symbols in a DLL. This might not be a problem, but I wonder
> if similar problems pop up when playing with the visibility attribute in
> GCC.
>
>> 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?

>> Hmmm.
>> Maybe MSVC can be somehow forced to follow the GCC strategy? But you
>> would probably know already...
>> Hmmm again...
>> Since MSVC supports the extern template feature, which seems to solve
>> the problem, and which is likely to be eventually supported even by
>> GCC, what about detecting it at config time and possibly try to
>> explicitly prevent the instantiations, as you seem to do?
>>
>> In light of this discussion, I now feel I do not understand well
>> enough how template instantiating works, or should work. I'll try to
>> dig up some more resources.
>
> Just to summarize, let me explain the 2 types of problem I've encountered
> with template instantiation in MSVC (I'm not sure I even fully understand
> them neither...):

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

> 2) implicit instantiation of Array<T> in another library than liboctave, when
> Array.cc is included; then the linker complains about duplicated symbols
> in liboctave and the current compiled code; typical example is Array-os.cc;
> one solution is the use "extern template"
>
> Michael.
>

OK, so now it should fail already in the compiler, because implicit
instantiation. But again, I don't understand why GCC does not have
this problem.


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