Just a minor interjection: as a user of third party libraries, I expect
the following things to be true of any library, for it to be considered
'nice and well behaved':
1) All exported functions have their calling convention defined in the
prototype. My project settings might not match the setting the library
was built against for this.
2) All exported data structures are wrapped with #pragma pack's, for the
same reason.
3) All exported functions should use plain data types or struct pointers.
If a typedef or #define to wrap the plain types is necessary, it sure
should be clearly unique to the library so there is no chance of a name
collision.
4) Exported data structures should never contain an enum type. An int or
similar type is far superior.
5) Due to the madness of windows memory management in a DLL system, I
should never directly free something the dll allocated or vice versa,
except via calls into the library for this express purpose.
6) Pulling in loads of system headers due to including the library
headers can be annoying, but sometimes unavoidable. A lot of standard
library functions are unsafe (and banned in some shops) and people tend to
use whats in the address space accidentally (sprintf/strcat etc come to
mind). Pulling in windows.h is fat and slow and should be avoided at all
costs.
> [ hey russ! :-) ]
>
> On Fri, Mar 21, 2003 at 03:55:39AM -0500, Russell Yanofsky wrote:
>>...
>> Anyway, on the bigger issue I think the best alternatives are:
>>
>> 1) Use __cdecl and DEF files. The advantages are that it doesn't require
>> any
>> modifications to the source, that it might lead to slightly faster load
>> times if ordinals are specified, and that __cdecl is the default calling
>> convention for C and C++, so programmers wouldn't have to specify it
>> explicity or wonder which convention to use.
>>
>> 2) Use __stdcall and __declspec() . The advantages are that __stdcall
>> function calls are smaller and faster than __cdecl calls, that explicit
>> __declspec(dllimport) declarations allow the compiler to further
>> optimise
>> calls (by eliminating a level of indirection), and that __stdcall is the
>> default calling convention for most languages other than C and C++, so
>> programmers using these languages wouldn't have to specify it explicity
>> or
>> wonder which convention to use.
>>
>> Either one seems reasonable to me...
>
> Since we can automate the first, and it is simplest for the developers,
> and
> the speed cost is negligible... we'll go with option #1.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 22 09:34:10 2003