Danushka Menikkumbura wrote:
If we go for the latter, then we have to decorate all the base classes.
This has to be done recursively. I started to do the job that way and
later found it really difficult to decorate some of the Qpid classes. If
I remember right there were issues related to some of the Boost base
classes as well.
Now that I understand the issue, I think its better the way it is. In particular
I think it's good to be able to avoid exporting a class just because it's used
as a private member of a public class.
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.
Cheers,
Alan.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
