octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comparison with NaN


From: Michael Goffioul
Subject: Re: Comparison with NaN
Date: Fri, 15 May 2009 20:43:11 +0100

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]