seanc@dimensionalrift.com wrote:
> 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.
This is a pretty good point. I'm not sure why anyone would change the
default calling convention, but if they did, they wouldn't be able to use
subversion's header files to call into the dll (At least not with Visual
C++, in Codewarrior you can say:
#pragma calling_convention(__cdecl)
#include "svn_whatever.h"
#pragma calling_convention(reset)
)
> 2) All exported data structures are wrapped with #pragma pack's, for
> the same reason.
This goes beyond "nice and well-behaved," it's downright charitable. The
windows header files don't even appear to do this.
If someone switches to a non default alignment they can be responsible for
writing:
#pragma pack(push, 8)
#include "svn_whatever.h"
#pragma pack(pop, 8)
in their own code.
> 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.
I get the part about using unique names, but don't see any problem with
using unnecessary typedefs or #defines. Both can be used to make code more
readable.
> 4) Exported data structures should never contain an enum type. An
> int or similar type is far superior.
Yes. I don't know whether subversion does this.
> 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.
Subversion does not do this with the dlls it uses, and it would be nice if
it did. This is the reason we have to use different berkeley db binaries for
vc6 and vc7.
> 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.
I don't think the subversion include files pull in any of these things. They
define platform-independent interfaces to the subversion libraries, so they
don't require windows type definitions or C string functions.
Also, I don't buy the whole "people tend to use whats in the address space"
argument. If a programmer writes some code that uses sprintf, and the
compiler gives an error saying sprintf is not defined, is he then going to
realize the error of his ways and rewrite the code? Most likely he'll just
go the top of the file and add #include <stdio.h>.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 23 00:10:05 2003