Re: Compile error at compiling liboctave/array/Array-b.cc due to "cannot be overloaded octave_int (char c)"

[Daniel J Sebald]

On 06/22/2015 03:55 AM, Tatsuro MATSUOKA wrote:
> ----- Original Message -----
>
> > From: Daniel J Sebald
> > To: Michele31415
> > Cc: octave-maintainers
> > Date: 2015/6/22, Mon 17:27
> > Subject: Re: Compile error at compiling liboctave/array/Array-b.cc due to "cannot be 
> > overloaded octave_int (char c)"
> >
> > On 06/21/2015 11:59 PM, Michele31415 wrote:
> > >   This question was originally posted under a different title.  It has been
> > >   suggested that I post again under a new title that is (presumably) more
> > >   descriptive.  In any case, I still don't have the solution.  It seems
> > like
> > >   I'm getting close to getting a Sparc version of Octave running as I
> > finally
> > >   managed to get ./configure to complete.  Now if I could only get it to
> > make.
> > >   ---------------------------------------------------------
> > >
> > >   On a Sparc Solaris box building Octave 3.8.2 (update - v. 4.0.0 throws the
> > >   same error), gmake fails with:
> > >
> > >     In file included from array/idx-vector.h:35:0,
> > >                     from array/Array.h:36,
> > >                     from array/Array-b.cc:29:
> > >   ./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) { }
> > >       ^

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