[vtk-developers] Wrappers and signed char

[Brad King]

David Gobbi wrote:
> I saw that you added "signed char" support to the wrappers.  Adding new 
> types to the wrappers is good, but if you're not careful, you'll run out 
> of available types pretty fast!  You're already up to 0xD, so only 0xE 
> and 0xF remain.

When we run out of types we can just shift everything over one digit and 
then we'll have 256 types.  Alternatively someone could implement a real 
type system that is actually readable and avoids duplicating the 
enumerations in Tcl/Java/Python/ClientServer/etc wrapper generators.

> You added a new token for "signed char".
> 
> You should have added a token for "signed" so that "signed" and "char" 
> in combination would make a "signed char".
> 
> This is actually pretty easy to do, because "unsigned" is already in 
> there, you just have to duplicate the "unsigned" code in vtkParse.y and 
> have "signed" evaluate to "0x20".
> 
> Then, the wrappers will see the basic type as "char", and can check to 
> see if it is preceeded by "signed" in exactly the same way that they 
> check for "unsigned".
> 
> A side benefit of this is that the wrappers will no longer choke on 
> "signed int" or "signed short" etc., instead they will properly 
> interpret these as being the same as "int" and "short".

I considered this design but rejected it for a couple reasons:

1.) The difference between "unsigned" and "signed" is that "signed char" 
is a distinct type from "char" while "signed short" is the same type as 
"short".  The "unsigned" qualifier always has meaning while the "signed" 
qualifier does not: the types "short", "int", and "long" are always 
signed.  We could simply update the parser to translate "signed int" as 
"int".  The type "char" is a distinct type and may have either 
signedness, so "signed char" is effectively its own type and should be 
treated as such by the wrappers.

2.) This design was faster to implement.

-Brad