Girder 3.1 API confusion

[Ron]

I was not aware that bool was 2 bytes, but it seems to work both ways ( as I had some plugins that used bool and _BOOL for a long time already ) but just recompile your plugins to use _BOOL ( BYTE ).

The reason for the change is that the Borland compilers do not have the bool type, so I defined this type to be compatible with both compilers.

<font size=-1>[ This Message was edited by: RonB on 2002-03-20 10:34 ]</font>

[Ron]

Just tested in VC++6.0 and the sizeof function tells me that bool is 1 byte large. So there is no problem.


<font size=-1>[ This Message was edited by: RonB on 2002-03-20 10:36 ]</font>

[Ron]

My god,.. does Windows typef BOOL as an integer,... what a horrible waste, it needs 1 bit they thow out 31 bits.... And people ask why windows uses this much memory.

I'll either make it really explicit that _BOOL is an BYTE, or change over to BYTE...

<font size=-1>[ This Message was edited by: RonB on 2002-03-20 10:58 ]</font>

[Ron]

I must clearly be missing something here. The definition has always been _BOOL, (BYTE) this has not changed now, what is the problem ?

Anyone in favour of moving to an integer as the return type, I really don't mind, but it has never been a problem.

[Ron]

I was not proposing any change to the compiler settings :smile:

note to Ron: Go with Integers next time, no alignment problems on 32 bit machines. Space is not a concern, a byte uses a 32 bits anyway on our lovely IA32 machines. ( pending compiler settings ... )

<font size=-1>[ This Message was edited by: RonB on 2002-03-20 19:25 ]</font>

[Mark F]

Wait a minute. Before you waste more time trying to remove extra bytes, read about your compiler's alignment functions. On VC, see the information on the #pragma PACK and /Zp options.

Bottom line is you cannot change the size of data in a structure by simply changing the data type of the variables. You must tell the compiler that you want to align things on a byte/word/etc. boundary first.

Please remember that by over-riding the default alignment:

You accept the speed penalty that is imposed by Intel processors for non-aligned data. This is the standard speed vs size programming trade-off.
Every plugin developer must change the settings in their compiler to use the new alignment value (if they can). How many times do you want to answer this question, "I'm using compiler YYY, how do I set the alignment to WWW?"


If you are REALLY worried about space usage, don't define the space for the plugins. Instead let the plugin data for commands be more like the payload data for events. IE. completely defined by the plugin. This allows the plugin developer to pack the data into a structure that is exactly the right size. This could also remove the need for the realloc function since the command data interface could be defined such that Girder never gives out a pointer to it's memory space. :smile:

You are breaking compatibility with the current plugins anyway, now seems like an OK time to do this if you want to.

[Mark F]

You are not missing a thing. :smile:

Both of those are valid points which must be considered when defining the interface and any proposed change to the compiler alignment settings.

[simonjo]

Ron,

I'm looking through the new 3.1 API documentation but end up confused.

I saw that the command structure is changed in that you replaced 'bool' with '_BOOL' which comes down to a 'BYTE'.

The same applies to new action support functions (version 5).

This implies a structure shift as 'bool' takes the space of 2 'BYTE's, or am I wrong on this point, or was this not your intention ????


Regards, Jo

[simonjo]

You are right but the problem I see is that in regular win32 programming API's we use 'BOOL' (typedef int BOOL as per windef.h) and not 'bool'.

This makes it even worse as 'int' ends up taking 4 bytes.

In order to avoid any further confusion could you either:

- use the base type, in this case 'BYTE', so it is very clear what allocation is used

- use the 'BOOL' (or even the 'int' base) type as used in win32 API's in future releases.

[simonjo]

I'm not concerned about those few bytes more or less. I do see 2 problems (at least that I encountered):

1) return values from functions that get a wrong typecast, thereby crippling the returned value (i.e. BYTE->int, int->BYTE)

2) if you use a different alignment boundary setting, the physical layout of structures can be different resulting in strange behaviour


Or am I missing out on something???