Ivan Zhakov wrote:
> On 12/6/05, Branko Čibej <email@example.com> wrote:
>> Ivan Zhakov wrote:
>>> On 12/6/05, Branko Čibej <firstname.lastname@example.org> wrote:
>>>> svn_ctype_table DATA
>>>> No source-level decoration is necessary.
>>> Yes, but in this case *some* test fails! I can't figure why. But if
>>> declare svn_ctype_table with __declspec(dllexport) everything works
>> Now, that _is_ funny. I wonder what's going on...
> I have discovered problems:
> In a few words: On Windows exporting variable means exporting
> *pointer* to this variable and importing must dereference it.
> __declspec(dllexport)/__declspec(dllimport) makes this automatically.
> So I see several ways:
> 1. Use __declspec(dllimport) for variables only. Causes special define
> for *each* dll to separate dll building dll from importing.
> 2. Use __declspec(dllimport) everywhere on windows -- anyway causes
> usage special define per library and change signature of all API.
Not really... only when you link with a DLL, and since we don't provide
DLLs yet, it's not actually a signature change. :)
> 3. Never export/import data between libraries. I don't sure that this
> can be done.
I'd go with 3. Sure it can be done; in the few cases where we do have
public data items, we can deprecate those and create accessor functions
instead. It'll slow down a fiew things (notably the svn_ctype macros),
but I don't think the difference will be significant.
I really hate the idea of per-library decorations because that would a)
complicate the build (we'd have to emit a different define when building
each library), b) it would reduce the readability of the public headers,
and c) it would mean that each library has to be built twice -- once as
a static lib, and once as a DLL -- instead of building just the static
lib, then simply relinking it as a DLL.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Dec 8 11:32:20 2005