Comparison with NaN

[Michael Goffioul]

On Thu, May 14, 2009 at 11:58 AM, Jaroslav Hajek <highegg at gmail.com> 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.
What I did is commenting out sections of Array.cc where the
instantiation failed. I did that by surrounding the offending code in
Array.cc with #ifndef NO_TEMPLATE_FIND_SORT and then
added a #define NO_TEMPLATE_FIND_SORT in oct-stream.cc, just
before including Array.cc. That's not elegant, but it works :)

Michael.