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, Дилян Палаузов <dilyan.palau...@aegee.org <mailto:dilyan.palau...@aegee.org>> 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.
<<attachment: dilyan_palauzov.vcf>>
