On Sun, Jan 18, 2009 at 9:56 PM, Daniel J Sebald <

[hidden email]> wrote:

> I've gotten Mercurial working on my FC3 machine (hoorah!). Python path

> problem...

>

> Compiling the latest source on this older system has uncovered one small

> syntax problem, I believe. Or I have some outdated compiler, std library

> headers, or something.

>

> The issue is the abiguity of '!' operator overloaded in oct-inttypes.h. An

> example string of errors is below. There are only a few spots where these

> errors are occuring. (Note that the errors are happening when building

> liboctave, not the src.) I fixed one instance with a kludge old-style case:

>

>

> diff -Pur octave/liboctave/intNDArray.cc octave-mod/liboctave/intNDArray.cc

> --- octave/liboctave/intNDArray.cc 2009-01-18 13:45:08.000000000 -0600

> +++ octave-mod/liboctave/intNDArray.cc 2009-01-18 13:53:19.000000000 -0600

> @@ -53,7 +53,7 @@

> {

> T val = this->elem (i);

>

> - if (((double)val) != 0.0 && ((double)val) != 1.0)

> + if (val != 0.0 && val != 1.0)

> return true;

> }

>

>

> Things then compiled along until hitting another instance:

>

> oct-inttypes.h: In function `bool operator!=(const double&, const

> octave_int<T>&) [with T = int64_t]':

> mx-s-i64nda.cc:11: instantiated from here

> oct-inttypes.h:1059: error: call of overloaded `mop(const double&, int64_t)'

> is ambiguous

> oct-inttypes.h:193: note: candidates are: static bool

> octave_int_cmp_op::mop(T, double) [with xop = octave_int_cmp_op::ne, T =

> double]

> oct-inttypes.h:198: note: static bool

> octave_int_cmp_op::mop(double, T) [with xop = octave_int_cmp_op::ne, T =

> long long int]

> oct-inttypes.h:211: note: static bool

> octave_int_cmp_op::mop(double, uint64_t) [with xop = octave_int_cmp_op::ne]

> oct-inttypes.h:212: note: static bool

> octave_int_cmp_op::mop(double, int64_t) [with xop = octave_int_cmp_op::ne]

> oct-inttypes.h:213: note: static bool

> octave_int_cmp_op::mop(int64_t, double) [with xop = octave_int_cmp_op::ne]

> oct-inttypes.h:214: note: static bool

> octave_int_cmp_op::mop(uint64_t, double) [with xop = octave_int_cmp_op::ne]

>

> which is much more difficult for me to kludge because it is embedded in some

> definition strings.

>

I guess you have gcc 3 series, right? (Judging by the FC3). The answer

is yes, it is a compiler defect.

The mop overloads inside octave_int_cmp_op are unambiguous and

standard conforming.

For more info, see this previous discussion:

http://www.nabble.com/error-when-compiling-Octave-in-Cygwin-td20966037.html#a20966037and this one on comp.lang.c++:

http://groups.google.com/group/comp.lang.c++/browse_thread/thread/398e6ba0047f902a/c258528a9b0258b9?lnk=gst&q=ambiguous+overloadYour best solution is to upgrade to gcc 4 (and I suggest upgrading the

FC3 anyway). I'm fairly reluctant to alter the conforming code to

please an obsolete compiler due to a particular defect (and so far

nobody even asked for it).

Even if that is an old machine, there should be up-to-dat GNU/Linux

distros fit for it.

But even if you don't want to upgrade the distro, you can build g++ 4

for yourself.

cheers

--

RNDr. Jaroslav Hajek

computing expert

Aeronautical Research and Test Institute (VZLU)

Prague, Czech Republic

url: www.highegg.matfyz.cz