While browsing through somebody's code the other day I came across this C++ class (it's not the full code - just enough for illustration purposes)

Code:
class GLIBMM_API Object : virtual public ObjectBase
{
protected:
  Object(); //For use by C++-only sub-types.
  explicit Object(const Glib::ConstructParams& construct_params);
  explicit Object(GObject* castitem);
  virtual ~Object(); //It should only be deleted by the callback.

public:
  //static RefPtr<Object> create(); //You must re-implement this in each derived class.

  //GObject* gobj_copy(); //Give a ref-ed copy to someone. Use for direct struct access.

  // convenience functions
  //template <class T>
  //void set_data_typed(const Quark& quark, const T& data)
  //  { set_data(quark, new T(data), delete_typed<T>); }

  //template <class T>
  //T& get_data_typed(const QueryQuark& quark)
  //  { return *static_cast<T*>(get_data(quark)); }

private:
  friend class Glib::Object_Class;
  static CppClassType object_class_;

  // noncopyable
  Object(const Object&);
  Object& operator=(const Object&);
};
Notice that it uses GLIBMM_API. When building the library as a DLL, GLIBMM_API is defined as __declspec(dllexport) whereas it gets re-defined to __declspec(dllimport) when building other apps that use the DLL. I assume the intention is that all exportable classes will get derived from class Object.

Whenever I've done something similar in my own code I usually ended up laboriously adding my own WHATEVER_API statements all over the place. It never occurred to me to have a simple base class and then derive all the others from it. I suppose it's a bit lazy but does anyone know if this technique works - i.e. would the derived classes have __declspec(dllexport) correctly defined, so their functions would all be visible (i.e. exported) from the DLL?

I could imagine this being a useful technique for dealing with 3rd party libraries which weren't originally intended to get built as Windows DLLs.