[vtk-developers] Wrappers and signed char

[David Gobbi]

Brad King wrote:

> 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.

Well, there are still three people in the world who can read the VTK 
wrapping code, so there isn't any need to change it quite yet.
The odds of all three of us getting hit by a bus are pretty low.  I 
place a certain nostalgia value on the VTK wrapper generators, they 
remind me of reading Apple II machine code.

>> 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.

It still seems wrong to me, because you're doing the tokenization 
according to semantics instead of according to syntax.

> 2.) This design was faster to implement.

Yeah, but just wait until you find out how much work that "shift by one 
digit" trick takes!

 - DG