Re: Comparison with NaN

[Michael Goffioul]

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.

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