He Zhenxing wrote:
> Hi
>
> Agreed, then what's you opinion on using types such as uint32,
> uchar,my_bool, etc. Should we use these types in plugin.h, or more
> generally, should we use these types in the interfaces, or should we
> just use int, long, char, bool instead.
Personally, I don't see the need for uchar, which just saves typing, nor
for my_bool, since it is just an int. OTOH, types like uint32 et.al.
does server a purpose. If you have a look at stdint.h (a standard
function), there are some inspiration to what should be there (these are
also standard types, so it might be a good idea to actually use those
names for the SDK).
I don't think it is a good idea to use int, long, short, and long long
(with some exceptions), because they have different sizes on different
platforms. Here's a list of what I think we need (what names we use for
the non-fundamental types is not that important):
int8_t
int16_t
int32_t
int64_t
uint8_t
uint16_t
uint32_t
uint64_t
char (to denote a character, not an integer)
unsigned char (to denote a byte)
void*
size_t
int (for error codes and boolean values)
Something like that. The fewer types we use, the better.
/Matz
>
> On 2008-06-09 Mon 09:54 +0200, Sergei Golubchik wrote:
>> Hi!
>>
>> On Jun 09, Mats Kindahl wrote:
>>> He Zhenxing wrote:
>>>> Hi Mats
>>>>
>>>> Did you noticed that I included <my_global.h> in plugin.h?
>>>>
>>>> The functions I added in plugin.h used some typedefs defined in it,
>>>> such as uint32, uchar. I am not quite sure other stuffs defined in
>>>> my_global.h should be exported or not.
>>> No, actually I didn't. I'm reluctant to include my_global.h since it
>>> contain a lot of dependencies on other code in the server... wait...
>>>
>>> ... no, I don't think it is a fundamental problem to include the file.
>>> There are a lot of definitions that are not really needed, but I see
>>> no harm in including it from plugin.h, we just have to make sure that
>>> it is part of the SDK as well.
>> No, please, don't inclue my_global.h in plugin.h, my_global.h is
>> internal, we are changing it freely and want to continue doing that.
>> plugin.h will be VERY soon strictly monitored to make it difficult for
>> anybody to modify it, the less files are public the better.
>> Besides, my_global.h is and always was written as internal - meaning
>> nobody tried to avoid namespace conflicts when it's used with other
>> projects' headers, nobody tried to minimize the dependencies, or
>> definitions/declarations in it, etc. It cannot be made a part of the
>> public API as is.
>>
>> And it'd be best if your plugin would not need it, if at all possible.
>> (for all plugins I've helped to create it's true, they don't need
>> internal headers)
>>
>> Regards / Mit vielen Grüssen,
>> Sergei
>>
>
--
Mats Kindahl
Lead Software Developer
Replication Team
MySQL AB, www.mysql.com
