Re: Comparison with NaN

[Jaroslav Hajek]

On Fri, May 15, 2009 at 9:43 PM, Michael Goffioul
<address@hidden> wrote:
> On Fri, May 15, 2009 at 12:56 PM, Jaroslav Hajek <address@hidden> wrote:
>> OK, I see the problem. I think this should simply not be done - Array
>> is not supposed to be a helper container, it is really ill-suited for
>> such purposes and I think STL containers fill that role better. Array
>> instances should be explicitly controlled and including Array.cc
>> should be limited to the implementation file (Array-xxx.cc). Btw. yes,
>> I realize it would be nice to document this recommendation :)
>>
>> I wiped out the ArrayN-idx problem you found and avoided the
>> instantiation mess in oct-stream.cc by using a static array instead
>> (which seems also much better suited for the purpose of a static
>> lookup table).
>> I also enhanced the Array interface with a dummy "instantiation_guard"
>> function that will (with probability approaching to 1 :) fail to
>> compile if an Array instance implementation is invoked by means other
>> than INSTANTIATE_ARRAY (which presumably means that the user knows
>> what he is doing).
>>
>> http://hg.savannah.gnu.org/hgweb/octave/rev/4b2147b25e8d
>> http://hg.savannah.gnu.org/hgweb/octave/rev/472f0e22aa60
>> http://hg.savannah.gnu.org/hgweb/octave/rev/72620af9cbaf
>>
>> since gcc seems to use a templating model which may discard implicitly
>> created instances, I wonder whether you now can actually compile
>> Octave with MSVC including these changes. Can you check?
>> Maybe we are still implicitly creating instances somewhere?
>
> I'll check, but oct-stream.cc was not and isolated case. There are
> other similar problems in the following 3 files:
>
> ov-typeinfo.cc: same as oct-stream.cc, #include Array.cc and oct-obj.h
>
> Array-tc.cc: idem, #include Array.cc and oct-obj.h; however in this case
> it is possible to change the #include <oct-obj.h> with #include <ov.h>,
> to avoid instantiation of Array<octave_value>; I'm also not sure MSVC is
> right in this case as there's a NO_INSTANTIATE_ARRAY_SORT(octave_value)
> statement, but it seems the implicit instantation due to #include <oct-obj.h>
> happens first and MSVC "ignores" the explicit instantiation
>
> Array-os.cc: implicit instantiation of Array<bool> and Array<octave_idx_type>
> (== Array<int>); in this case, the problem is a linker error due to multiple
> symbol definitions; the existing "extern template" statements solve the 
> problem.
>
> Michael.
>

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 :(
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).
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.

regards

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