|
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:1.9.2.24) 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 seemslikeI'm getting close to getting a Sparc version of Octave running as Ifinallymanaged to get ./configure to complete. Now if I could only get it tomake.--------------------------------------------------------- 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 'classoctave_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) [withT = 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
[Prev in Thread] | Current Thread | [Next in Thread] |