[Top][All Lists]

[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: Daniel J Sebald
Subject: Re: Compile error at compiling liboctave/array/Array-b.cc due to "cannot be overloaded octave_int (char c)"
Date: Mon, 22 Jun 2015 11:51:26 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

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
  I'm getting close to getting a Sparc version of Octave running as I
  managed to get ./configure to complete.  Now if I could only get it to


  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
  ./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)))
  { }


reply via email to

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