Is this really just limited to exception classes? I got the impression from the GCC docs that the issue might extend to:
* Classes with vtables that are used in dynamic_cast's or with typeid. * Classes with static data members.
From my reading of it, the "re-exporting" is limited to exception classes; albeit, the article could be clearer. This is because (again, according to the article) the catch handler looks for the exception class typeinfo in the dso that threw it, and not in the dso that originally defined the exception, hence the need to "re-export" the exception from all dsos that potentially throw it.
With respect to the category of classes that you mention the "re-exporting" issue might extend to, I think the article is just advising to just export these classes, or their static data members in the first place, not "re-export" them from every dso that they appear in.
Hmmm, it's a bit vague in it's wording isn't it?
BUT ...., some simple tests I performed seem to only partially validate my claim (see attached for the tests).
All tests run on: OSX 10.5, gcc version 4.0.1
With respect to the dynamic_cast/typeid category, my tests revealed no need for "re-exporting", even when I compiled with "-O3" flag.
With respect to template classes with static data members, my tests did reveal a need for "re-exporting".
Admittedly, it would be nice if we can get some clarification from the gcc team regarding this.
I still think that re-exporting "just enough and no more" is error prone, and we should just follow the gcc guidelines and re-export everything that's imported - I rather got the impression that gcc will only actually generate re-export data for vtables anyway?
True, it may be error prone. Sorry, I can't seem to find the gcc guideline you're referring to, can you point it out?
The usual http://gcc.gnu.org/wiki/Visibility article, under "Step by Step Guide", they recommend: #define FOX_HELPER_DLL_IMPORT __attribute__ ((visibility("default"))) HTH, John.