Subject: Re: [boost] [config] GCC symbol visibility across shared libraries
From: Beman Dawes (bdawes_at_[hidden])
Date: 2010-05-19 18:03:23
On Wed, May 19, 2010 at 2:16 PM, Jürgen Hunold <juergen.hunold_at_[hidden]> wrote:
>> In addition to that change, I've moved the definitions from win32.hpp
>> into the specific compilers involved. These visibility macros are
>> compiler extensions to C++, and are starting to show up in platforms
>> other than Windows.
> The rationale for the win32.hpp was that _every_ compiler has to support
> ___declspec on this platform.
Every compiler that wants to be compatible with other current Windows
compilers will support ___declspec today, but the introduction of
attribute syntax in C++0x may mean changes in the future. Also, some
past compilers used on Windows didn't support ___declspec, and
Microsoft has changed the spelling of the syntax at least once.
I also have more dislike for having to change the platform headers
when compilers change than the other way around. I don't have any way
to test some of the platform headers easily either.
> I don't know if clang on linux supports __declspec or uses gcc __attribute.
> So I think win32.hpp + platform compiler setup might be the way.
> Or even unix.hpp with __attribute usage for all gcc compatible compilers.
> Else we have a high redundancy defining the same macros in every compilers
I'm still not convinced.
>> I've also edited the docs changes somewhat.
> Thanks, writing docs is a weak point (at least for me ;-))
>> So far, I've only made changes to Boost.System. See the attached.
>> (I've also made a lot of tweaks to Boost.System tests, but those are
>> of limited interest so aren't included in the attached diff.)
> looks good.
>> Unless there are objections, I'll commit these to trunk, and wait
>> until tests have cycled for several days before doing anything with
>> other libraries. We will want to alert developers of other libraries,
>> as some of them will prefer to make their own changes. Others will be
>> happy if someone else makes the changes.
> My only objection is the redundancy introduced by moving the logic out of
> win32.hpp. I don't like lots of identic definitions flying around.
What do others think?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk