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 20:54:42 GMT
shuston@riverace.com wrote:
> Hi Alan,
> 
> Quoting Alan Conway <aconway@redhat.com>:
>> 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:dev-subscribe@qpid.apache.org


Mime
View raw message