[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] non static libs on windows (dll)

From: SteveKing <steveking_at_gmx.ch>
Date: 2003-03-21 10:56:53 CET

> 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.

That would require extra work. And I think that would lead to problems
whenever the DEF file doesn't match the __cdecl in the source. Or can
you guarantee that those are always in sync?

What I don't quite get in this discussion is the part about speed. Todays
computers are fast enough so that no one would ever notice the difference.
There are no functions which are used multiple times, usually a client
only calls one 'command' (like svn_client_update() or others) once and
then the work is done inside the dll which takes the most time. So those
few microseconds for the call itself really doesn't matter.

Also I would really like to have the patch applied so that we get the dll
now. If a def-file generator is planned or even already started then
that could be changed again in the future. I just don't like to wait that
long
until we get the dll - the benefit of a smaller binary is IMHO too big to
wait any longer.

And I also don't understand quite the reason why we not want to do it
the same way as apr does it. Subversion uses apr, apr works well. So
what exactly is wrong with that approach?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 21 10:58:15 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.