A neat way of exporting DLL symbols?

I know that in MSVC we can export all symbols from a C++ class by using a suitable export specifier applied to the whole class. Or alternatively we can export certain functions selectively by preceding each declaration individually with __declspec(dllexport). But apparently the gcc processor has a neat little pragma for doing this - e.g.

Code:

---

#define MY_EXPORT_SPECIFIER  __attribute__ ((visibility ("default")))

class MY_EXPORT_SPECIFIER MyClass
{
      // c'tor and d'tor get exported due to MY_EXPORT_SPECIFIER
      MyClass();
      ~MyClass();

private:
      // Private data and functions are not exported
#pragma GCC visibility push(hidden)

      // Declare private data and functions
#pragma pop

public:
      // Publicly declared functions are now exported again
}

---

;

Okay, it might seem a bit lazy but I think that's quite neat - much better than the MSVC way of needing to address each function individually. Or is it? Is there any similar little trick we can do in MSVC?

exporting a single function and exporting a class serve different purposes.

I kinda fail to see why you'd want to export a whole class, but then not export the private/protected parts thereof, that seems like a bad idea on so many levels.
It means you can't extend the class properly through inheritance since part of the interface is inaccessible.
and it means that some of the inline's may not even work.
It probably gives you the false impression "it's a good idea", but if you only wanted the member functions... Then why did you export the whole class and give an apparent indication you want the class to be exptendable outside the dll.

"being lazy" is a bad excuse for not doing something properly.

Very good points but my question was more to find out if there's a way to "group" functions to be exported without either (a) exporting them all individually, or (b) exporting the entire class.

For example... in a C++ DLL it's possible to remove name decoration from a bunch of 'C' functions like this:-

Code:

---

extern "C" {
      // A list of functions
}

---

so wouldn't it be useful to be able to do this:-

Code:

---

__declspec(dllexport) {
      // A list of functions
}

---

The GCC approach is slightly convoluted but in effect, that's what it achieves.

__declspec is part of the ansi c++ spec (the keyword is, the implementation isn't) so the way to use it has been very carefully chosen.

I'm not sure a syntax like you propose would be syntactically viable or if it would cause issues/sideeffects in the parser/compiler.

GCC added a keyword of their own. That's their choice, but it isn't part of the standard.

Personally I don't really see much problem with it. it's not like adding a declspec is particularly hard, and you probably want to add a calling specification anyway (if at function level), so you end up macroing it anyway. exporting entire classes is non portable to another compiler anyway.

also... note that there was a reason to support the extern "C" {} syntax. namely to support including C headers and libraries from C++ without touching the header

Code:

---

extern "C" {
#include "some_c_header.h"
}

---

whereas such a need never existed for __declspec.