[email protected] wrote:
Hi Alan,
Quoting Alan Conway <[email protected]>:
I'm writing up some principles for future-proofing the C++ API and I
have a
question on declspec use:
The client API uses this idiom:
class Foo {
public:
QPID_CLIENT_EXTERN f();
QPID_CLIENT_EXTERN g();
};
In past projects I've always used this idiom:
class QPID_CLIENT_EXTERN Foo {
pulblic:
f();
g();
};
What's the reason for doing the former rather than the latter? It
seems more
verbose and error prone.
It is more verbose and easier to miss one. However, decorating the class
carries requirements for ancestor classes which can't (easily) be met. I
wrote about it in my blog:
http://stevehuston.wordpress.com/2009/03/12/lessons-learned-converting-apache-qpid-to-build-dlls-on-windows/
OK that makes sense - in particular not having to export private member classes
seems like a worthwhile gain in flexibility.
Gcc also has the notion of exporting symbols but it defaults to
export-everything so often its ignored. Would be interesting to see if turning
on exports would significantly speed up linking. Another day...
Cheers,
Alan.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
