Re: URGENT: Please evaluate this easy fix enabling wxgtk2.1 to build!
No, this is a _feature_ of C++, not a bug. The signature of a function is
defined by its argument types, and C++ regards two functions with the same
name but different signatures as two different functions. In standard C,
you would get the same function, but a silent cast might occur.
Whether bare 'char' defaults to 'signed char' or to 'unsigned char' is
implementation dependent, however. Most likely, if this got through from
upstream, it was because the upstream maintainer's implementation assumed
'signed char' in this case.
Most machines are more efficient when handling unsigned values than signed
values, while a few machines are more efficient when handling signed
values than unsigned values. If the program is limited to being compiled
with gcc anyway, then the behavior of the the compiler can be changed with
the '-fsigned-char' switch. The gcc default is to use whichever mode is
more efficient for the target platform.
-- Mike
On 2000-05-27 at 15:45 -0700, Jim Lynch wrote:
> Especially important questions to ask: Why does wxwin choose to use signed
> char * in method prototypes? It seems the new standard will cough when
> you try to pass a char * through that; I have been told this is standard
> c++ behavior (so it's -not- a compiler bug). I have the new language ref
> and will research this if you want. The wxwin people should probably use
> const char * for incoming C strings. But if they change that, they change
> the API... Which, maybe, they should.
Reply to: