Re: Comparison with NaN

[Jaroslav Hajek]

On Thu, May 14, 2009 at 2:46 PM, Michael Goffioul
<address@hidden> wrote:
> On Thu, May 14, 2009 at 11:58 AM, Jaroslav Hajek <address@hidden> wrote:
>>> As a side note, I have a similar effect, though I couldn't find an
>>> easy workaround, with Array<octave_value> instantiation. When
>>> compiling oct-stream.cc, Array.cc gets included. However, Cell.h
>>> also gets included (mainly because of <oct-obj.h>, which is needed
>>> to have octave_value_list defined). Cell.h defines an Array<octave_value>-
>>> inherited class decorated with dllexport, so MSVC instantiates it,
>>> including all known members, that is (for instance) Array::find.
>>> However, Array<octave_value>::find cannot be instantiated, because
>>> for instance of the line 2485:
>>>
>>>    cnt += src[i] != zero;
>>>
>>> where "cnt" is of type "octave_idx_type" and "src[i] != zero" is of
>>> type "octave_value" ("src" is of type "const octave_value*" and
>>> "zero" is of type "const octave_value").
>>>
>>> The only (ugly) worked around I could find is to comment out that
>>> part of Array.cc (all the find and sort related members), as is it not
>>> needed anyway by oct-stream.cc.
>>
>> I think that's the most reasonable solution. I see no reason at all to
>> include it there - Array.cc should be *only* included in those .cc
>> sources instantiating Array for a particular type, and those sources
>> should probably not do anything else beyond the instantiation (and
>> possibly specializing). I'll remove the offending #include.
>
> Don't. It is needed. But the problem is that you only need a part
> of it, while the other part is making template instantiation to fail.

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?

regards

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