Re: URGENT: Please evaluate this easy fix enabling wxgtk2.1 to build!
On 2000-05-28 at 14:00 +0300, Antti-Juhani Kaijanaho wrote:
> On Sat, May 27, 2000 at 07:28:49PM -0400, Mike Bilow wrote:
> > Whether bare 'char' defaults to 'signed char' or to 'unsigned char' is
> > implementation dependent, however.
>
> At least in C, char is neither signed char or unsigned char. It is a
> separate type that behaves either like signed char or like unsigned char.
> I don't know if this difference is important here, but it's there, anyway.
C++ has the notion of a 'trivial conversion,' which is something like a
cast that is guaranteed to succeed. So, while 'char' is a distinct type
which is neither signed nor unsigned in C++ just as it is in C, a trivial
conversion will occur if it is passed as an argument on a function call
and the default happens to match on the platform.
The key difference is that, in C++, if there is a mismatch of argument
type which cannot be patched up with a trivial conversion, then the
function signature will be different, and you are in effect calling an
entirely different function which, if you are lucky, will not exist. In
C, the argument of whatever type is simply put onto the stack and popped
off as raw data, and the only hope of catching this is by enforcing header
discipline through prototypes. However, in C, there is no actual way to
guarantee that the headers are even in agreement, and it can easily happen
-- especially as here when calling a library function -- that the linker
will just silently perform what amounts to a broken cast and introduce a
possibly serious bug.
The reason C++ has the 'trivial cast' is to keep a lot of existing C code
working, since one of the goals was to enforce stricter syntax and catch
many common C errors while forcing as little rewriting of working C code
as was possible. As a result, there are certain relaxations in C++ of
this kind which are compromises of strict type checking in order to
preserve backward compatibility.
In the case of thw wxwin library under discussion, I think the programmers
accomplished exactly their goal in using one of the principal design
objectives of C++, which is to make things break at compile time rather
than at run time. And, as noted, patching it in the way suggested is
probably a bad idea as it could introduce conflicts with the library.
-- Mike
Reply to: