[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compile error at compiling liboctave/array/Array-b.cc due to "cannot
From: |
Tatsuro MATSUOKA |
Subject: |
Re: Compile error at compiling liboctave/array/Array-b.cc due to "cannot be overloaded octave_int (char c)" |
Date: |
Wed, 24 Jun 2015 13:51:17 +0900 (JST) |
^
> Picking just the first example, I'm not completely sure what the issue is,
> but it has something to do with casting from one type to the same type
> perhaps?
> Maybe octave_int<char>::octave_int(char) doesn't make sense to the
> compiler. Line 1041 is
>
> template <>
> inline std::ostream&
> operator << (std::ostream& os, const octave_int<int8_t>&
> ival)
> {
> os << static_cast<int> (ival.value ()); [THIS LINE IS 1041]
> return os;
> }
>
> int8_t I would guess is char type. That is cast to an int. Could int also
> be a
> char on SPARC? Doesn't seem right, but I'm just trying to conjure up a
> line of thought that might go somewhere.
>
> The comment associated with code hunk above might be a clue:
>
> // We need to specialise for char and unsigned char because
> // std::operator<< and std::operator>> are overloaded to input and
> // output the ASCII character values instead of a representation of
> // their numerical value (e.g. os << char(10) outputs a space instead
> // of outputting the characters '1' and '0')
>
> To me, that sounds like attempting to convert 8-bit integer behavior to
> 16-bit
> integer so that the << operators output numbers. Somehow this sort of
> trick (for lack of word) isn't compiling correctly on SPARC.
>
> Here's line 834:
>
> // Always treat characters as unsigned.
> octave_int (char c) [THIS LINE IS 834]
> : ival (octave_int_base<T>::truncate_int (static_cast<unsigned
> char> (c)))
> { }
>
> Dan
The environments etcs.
Sparc Solaris , gcc-4.9.2
Octave 3.8.2 (4.0.0 may give the same error)
Compiling source file: liboctave/array/Array-b.cc
Place error occurred: liboctave/util/oct-inttypes.h
Error message:
./util/oct-inttypes.h: In instantiation of 'class octave_int<char>':
./util/oct-inttypes.h:1041:31: required from here
./util/oct-inttypes.h:834:3: error: 'octave_int<T>::octave_int(char) [with T =
char]' cannot be overloaded
octave_int (char c)
^
./util/oct-inttypes.h:831:3: error: with 'octave_int<T>::octave_int(T) [with T
= char]'
octave_int (T i) : ival (i) { }
^
Dan's assumption is shown the above.
From Dan's observation, this error is specific to SPARC Solaris.
> To me, that sounds like attempting to convert 8-bit integer behavior to
> 16-bit
> integer so that the << operators output numbers. Somehow this sort of
> trick (for lack of word) isn't compiling correctly on SPARC.
The octave codes are preferably independent of kind of platforms or
architectures.
Is the phenomenon deserve to file as a bug?
Tatsuro