qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: C++ windows declspec question
Date Mon, 30 Mar 2009 21:43:10 GMT
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:dev-subscribe@qpid.apache.org
>>
>>
>>
> 
> 


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message