SteveKing wrote:
>> 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?
You do not have to specify __cdecl in the source, it is the default calling
convention used in C and C++ code. The major advantage of this approach is
that you don't need to make *any* changes to the source, all you have to do
is write up a few DEF files and add them to the various projects.
> 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.
I completely agree, and said that DLL performance issues shouldn't matter in
my first post. Greg and Branko both talked about these things, though, and I
wanted to provide some clarification. Basically, my conclusion was that
choice #1 allows for slightly faster loading time, and that choice #2 allows
for faster calls into the DLL.
> 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.
We don't need to wait for a DEF generator. Writing a def file is as easy as
adding macros to the sources. In fact, I volunteer to write the DEF files if
the subversion people decide to go this route. It won't take more than a few
hours of work since they can be based on your patch.
> 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?
Greg wanted to make one DLL for each library instead of one monolithic one
like libapr.dll, Branco said that the macro functions trip up doxygen, and
I've said that macro functions are unneccessary and ugly.
These are the reasons for wanting to take a different approach than APR. I
haven't heard any arguments for the APR approach...
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 21 19:08:18 2003