octave-maintainers
[Top][All Lists]
Advanced

[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



reply via email to

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