
On Wed, May 19, 2010 at 2:16 PM, Jürgen Hunold <juergen.hunold@ivembh.de> 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 header.
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? --Beman