SteveKing wrote:
>> * I'd prefer to avoid the "stdcall" stuff and just use C calling
>> conventions every where. it avoids a lot of questions with "should
>> this be declared _NONSTD?"
>
> yes, that would be the _NONSTD macro. But why don't you like the
> "stdcall" approach? Other programming languages could use that better
> 'cause they wouldn't need to convert to the C calling convention
> first before calling functions
> in the dll.
Like he said, if all functions use the default __cdecl convention then there
will never be any confusion about which convention to use, for example, when
writing local callback functions.
Another advantage of sticking with __cdecl is that if you do decide to use
DEF files, then you can eliminate the SVN_DECLARE macros.
I'm not sure about the compatibility with other languages. Delphi and Python
(ctypes module) support both calling conventions. I don't know about visual
basic.
>> * I don't think we want a header named "svn.h"; that feels just a
>> bit too generic for something like this. Also, given that we'd
>> have a full set of macros for each library, the content will get
>> pretty big. I'd suggest putting it into svn_types.h, or create
>> svn__linkage.h or svn__declare.h or something, and include that
>> from each header. (users would never include the header)
>
> I did that like apr did it. They too have one header file called
> apr.h and that's
> included in every other header file. That way users also never need to
> include
> that header. But I'm open about the name. :)
Another place you might consider diverting from apr is in the use of
function call macros. Why not use
SVNAPI svn_error_t *
svn_ra_init_ra_libs (void **ra_baton,
apr_pool_t *pool)
instead of
SVN_DECLARE(svn_error_t *)
svn_ra_init_ra_libs (void **ra_baton,
apr_pool_t *pool)
This is just an aesthetic issue, but it seems ugly to me to use function
call macros in function declarations.
>> All that said, I'd also like to investigate another approach. The
>> DECLARE style macros are necessary to avoid .def files. However,
>> what if we automatically generated .def files from the headers? That
>> is, have the gen-make system create those files for us by analyzing
>> the headers?
>
> That would be very complicated to implement, would take a lot of time
> and always include another step to get to the resulting dll. Sure, the
> community
> would love to have such a tool (search google and you'll find tons of
> other people which need exactly such a tool), but since such a tool
> does not exist yet I don't think we should block the subversion dll
> until there is one. The benefit for clients in handling and size is
> IMHO just too
> big to wait any longer.
You wouldn't need to wait for the tool. Its not any harder to maintain def
files by hand than it is to maintain SVN_DECLARE macros. On the other hand,
it doesn't really make sense to use def files unless you also switch to
__cdecl.
>> It seems that I also recall hearing that ordinals might not be
>> useful any more; that the runtime linkloader might be fast enough
>> with names that the ordinal doesn't buy you much any more.
>
> It depends on what language you use to call the functions. VB (some
> people say that that is _not_ a programming language :) is AFAIK
> slower when calling dll's with ordinals. I don't know about delphi or
> others...
Some other performance-related issues are that using __stdcall instead of
__cdecl will reduce code size, and that adding __declspec(dllimport) can
make calls more efficient. I don't think any of this should really factor
into any decisions though.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 20 23:29:18 2003