Re: Documentation module lib-symbol-visibility

[Дилян Палаузов]

Hello Michael,

there is a point with dllexport/dllimport, however when not building for 
Windows, the argumentation does not apply and the recommendation for use 
LIBFOO_DLL_EXPORTED in the header files is suboptimal in my eyes.

Looking at the documentation of module lib-symbol-visibility, at the 
very end, I might oversee something, but I have the feeling, that when 
./configure determined support for -fvisibility=hidden, and 
BUILDING_LIBFOO, HAVE_VISIBILITY and _MSC_VER are all defined, from

     #if BUILDING_LIBFOO && HAVE_VISIBILITY
     #define LIBFOO_DLL_EXPORTED __attribute__((__visibility__("default")))
     #elif BUILDING_LIBFOO && defined _MSC_VER
     #define LIBFOO_DLL_EXPORTED __declspec(dllexport)
     #elif defined _MSC_VER
     #define LIBFOO_DLL_EXPORTED __declspec(dllimport)
     #else
     #define LIBFOO_DLL_EXPORTED
     #endif

follows, that LIBFOO_DLL_EXPORTED is
   __attribute__((__visibility__("default")))
whereas it shall be
  declspec(dllexport)
as declspec(dllexport) implies visibility(default), and 
visibility(default) does not help to DLL-export the symbols.

Със здраве
  Дилян


On 20.07.2012 14:15, Michael Goffioul wrote:
> On Fri, Jul 20, 2012 at 12:56 PM, Дилян Палаузов
> <address@hidden <mailto:address@hidden>> wrote:
>
>     Defining LIBFOO_DLL_EXPORTED in public header files has no added
>     value from the user's perspective: mentioning a function in the
>     public header files implies, that the function is visible.  As
>     suggested, there is another way to achieve the same result, without
>     touching the header files.
>
>
> One advantage I see for decorating declarations is easier compatibility
> with compilers like MSVC that require exported variables to be decorated
> with dllimport. From a C++ point of view, I'd also find easier to
> decorate the class declaration once, instead of having to decorate all
> members in the source code.
>
> Michael.

dilyan_palauzov.vcf
Description: Vcard