[predef] Status and review results?

older
[chrono/date] Two axes for a date...

Rene Rivera

21 Apr 2013 21 Apr '13

9 p.m.

Just a quick message to mention that I've finished all the review related changes to the Predef library. And done some of the future tasks on the library. In particular the addition of endianness definitions and the moving of MinGW as a platform instead of a compiler (and hence the addition of BOOST_PLAT category of macros. And the one question I have is.. When will the review results of the library be decided on? I ask for two reasons. One, the obvious, is just to know if it's accepted or not. And to know if it's not accepted and hence that I should spend time to recreate a "boost/detail/endian.hpp" header that implements the Predef logic for endian detection. Note the project move to Github earlier this year (in preparation for the Boost git move). You can find the project at < https://github.com/grafikrobot/boost-predef>, and browse the current documentation at http://tinyurl.com/cqqhhev. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Show replies by date

Andrey Semashev

21 Apr 21 Apr

9:22 p.m.

On Sunday 21 April 2013 16:00:49 Rene Rivera wrote:

...

Just a quick message to mention that I've finished all the review related changes to the Predef library. And done some of the future tasks on the library. In particular the addition of endianness definitions and the moving of MinGW as a platform instead of a compiler (and hence the addition of BOOST_PLAT category of macros.

And the one question I have is.. When will the review results of the library be decided on? I ask for two reasons. One, the obvious, is just to know if it's accepted or not. And to know if it's not accepted and hence that I should spend time to recreate a "boost/detail/endian.hpp" header that implements the Predef logic for endian detection.

Note the project move to Github earlier this year (in preparation for the Boost git move). You can find the project at < https://github.com/grafikrobot/boost-predef>, and browse the current documentation at http://tinyurl.com/cqqhhev.

I noticed this in the docs: BOOST_ARCH_X86_64 Intel IA-64 architecture. x86_64 (aka amd64 and Intel64), which is a widespread extension to IA32 (x86), is not the same as IA64, which is implemented in Itanium CPUs. Could you, please, separate these two architectures? Also, FYI there is a new "architecture" x86_32 on Linux, which is not legacy x86 described by your BOOST_ARCH_X86_32 macro. x86_32 is essentially x86_64 with 32 bit pointers and size types. You should probably make this clear in the docs and I'd even rename BOOST_ARCH_X86_32 to BOOST_ARCH_X86_LEGACY or something because of this and introduce BOOST_ARCH_X86_32 with the new meaning. Sorry, I don't have specific macros to detect x86_32 right now but it is supported by gcc.

Lars Viklund

11:45 p.m.

On Mon, Apr 22, 2013 at 01:22:33AM +0400, Andrey Semashev wrote:

...

On Sunday 21 April 2013 16:00:49 Rene Rivera wrote:

...
Just a quick message to mention that I've finished all the review related changes to the Predef library. And done some of the future tasks on the library. In particular the addition of endianness definitions and the moving of MinGW as a platform instead of a compiler (and hence the addition of BOOST_PLAT category of macros.

And the one question I have is.. When will the review results of the library be decided on? I ask for two reasons. One, the obvious, is just to know if it's accepted or not. And to know if it's not accepted and hence that I should spend time to recreate a "boost/detail/endian.hpp" header that implements the Predef logic for endian detection.

Note the project move to Github earlier this year (in preparation for the Boost git move). You can find the project at < https://github.com/grafikrobot/boost-predef>, and browse the current documentation at http://tinyurl.com/cqqhhev.

I noticed this in the docs:

BOOST_ARCH_X86_64 Intel IA-64 architecture.

x86_64 (aka amd64 and Intel64), which is a widespread extension to IA32 (x86), is not the same as IA64, which is implemented in Itanium CPUs. Could you, please, separate these two architectures?

Also, FYI there is a new "architecture" x86_32 on Linux, which is not legacy x86 described by your BOOST_ARCH_X86_32 macro. x86_32 is essentially x86_64 with 32 bit pointers and size types. You should probably make this clear in the docs and I'd even rename BOOST_ARCH_X86_32 to BOOST_ARCH_X86_LEGACY or something because of this and introduce BOOST_ARCH_X86_32 with the new meaning. Sorry, I don't have specific macros to detect x86_32 right now but it is supported by gcc.

I thought that the mongrel ABI was properly called "x32" [1][2][3]. Searching for x86_32 just seems to hit a bunch of confused people actually meaning the regular boring 32-bit x86. While they made an odd naming decision calling it "x32", calling it something else than what it's actually called would be a disservice. [1] http://gcc.gnu.org/ml/gcc/2011-05/msg00246.html [2] https://sites.google.com/site/x32abi/ [3] http://en.wikipedia.org/wiki/X32_ABI [4] http://wiki.debian.org/X32Port -- Lars Viklund | zao@acc.umu.se

Rene Rivera

22 Apr 22 Apr

12:18 a.m.

On Sun, Apr 21, 2013 at 6:45 PM, Lars Viklund wrote:

...

...
On Sunday 21 April 2013 16:00:49 Rene Rivera wrote:

...
Just a quick message to mention that I've finished all the review related changes to the Predef library. And done some of the future tasks on the library. In particular the addition of endianness definitions and the moving of MinGW as a platform instead of a compiler (and hence the addition of BOOST_PLAT category of macros.

And the one question I have is.. When will the review results of the library be decided on? I ask for two reasons. One, the obvious, is just to know if it's accepted or not. And to know if it's not accepted and hence that I should spend time to recreate a "boost/detail/endian.hpp" header that implements the Predef logic for endian detection.

Note the project move to Github earlier this year (in preparation for

On Mon, Apr 22, 2013 at 01:22:33AM +0400, Andrey Semashev wrote: the

...
...
Boost git move). You can find the project at < https://github.com/grafikrobot/boost-predef>, and browse the current documentation at http://tinyurl.com/cqqhhev.

I noticed this in the docs:

BOOST_ARCH_X86_64 Intel IA-64 architecture.

x86_64 (aka amd64 and Intel64), which is a widespread extension to IA32 (x86), is not the same as IA64, which is implemented in Itanium CPUs. Could you, please, separate these two architectures?

Also, FYI there is a new "architecture" x86_32 on Linux, which is not legacy x86 described by your BOOST_ARCH_X86_32 macro. x86_32 is essentially x86_64 with 32 bit pointers and size types. You should probably make this clear in the docs and I'd even rename BOOST_ARCH_X86_32 to BOOST_ARCH_X86_LEGACY or something because of this and introduce BOOST_ARCH_X86_32 with the new meaning. Sorry, I don't have specific macros to detect x86_32 right now but it is supported by gcc.

I thought that the mongrel ABI was properly called "x32" [1][2][3]. Searching for x86_32 just seems to hit a bunch of confused people actually meaning the regular boring 32-bit x86.

While they made an odd naming decision calling it "x32", calling it something else than what it's actually called would be a disservice.

Indeed.. I might consider adding an ARCH_X86_X32. Although more appropriate might be ARCH_X86_64_X32. But I'm somewhat reticent to add an ARCH that is just an "emulation" running on X86_64. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Andrey Semashev

3:26 a.m.

On Sunday 21 April 2013 19:18:35 Rene Rivera wrote:

...

On Sun, Apr 21, 2013 at 6:45 PM, Lars Viklund wrote:

...
I thought that the mongrel ABI was properly called "x32" [1][2][3]. Searching for x86_32 just seems to hit a bunch of confused people actually meaning the regular boring 32-bit x86.

While they made an odd naming decision calling it "x32", calling it something else than what it's actually called would be a disservice.

Indeed.. I might consider adding an ARCH_X86_X32. Although more appropriate might be ARCH_X86_64_X32. But I'm somewhat reticent to add an ARCH that is just an "emulation" running on X86_64.

Well, this is a new ABI rather than a new hardware architecture. You could define a new set of macros for detecting ABIs. But it is treated as a distinct architecture in the compiler and OS, so I'm not sure a different set of macros is a good idea. Also I'm not aware of any other precedents. PS: I like ARCH_X86_X32 more.

Bjorn Reese

10:03 a.m.

On 04/22/2013 02:18 AM, Rene Rivera wrote:

...

Indeed.. I might consider adding an ARCH_X86_X32. Although more appropriate might be ARCH_X86_64_X32. But I'm somewhat reticent to add an ARCH that is just an "emulation" running on X86_64.

Or better yet, add macros to detect the data model [1]. For instance, the x32 ABI can be detected as ILP32. This will be a generic solution, not only limited to the oddities of x86. [1] http://sourceforge.net/p/predef/wiki/DataModels/

Rene Rivera

23 Apr 23 Apr

4:05 a.m.

On Mon, Apr 22, 2013 at 5:03 AM, Bjorn Reese wrote:

...

On 04/22/2013 02:18 AM, Rene Rivera wrote:

Indeed.. I might consider adding an ARCH_X86_X32. Although more

...
appropriate might be ARCH_X86_64_X32. But I'm somewhat reticent to add an ARCH that is just an "emulation" running on X86_64.

Or better yet, add macros to detect the data model [1]. For instance, the x32 ABI can be detected as ILP32. This will be a generic solution, not only limited to the oddities of x86.

I think eventually I will (and I'll add a todo item on that). But given that the information is commonly only going to be indirectly available (i.e. the LP64 etc macros are not defined my most compilers) it's not going to be easy. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Andrey Semashev

22 Apr 22 Apr

3:18 a.m.

On Monday 22 April 2013 01:45:42 Lars Viklund wrote:

...

On Mon, Apr 22, 2013 at 01:22:33AM +0400, Andrey Semashev wrote:

...
Also, FYI there is a new "architecture" x86_32 on Linux, which is not legacy x86 described by your BOOST_ARCH_X86_32 macro. x86_32 is essentially x86_64 with 32 bit pointers and size types. You should probably make this clear in the docs and I'd even rename BOOST_ARCH_X86_32 to BOOST_ARCH_X86_LEGACY or something because of this and introduce BOOST_ARCH_X86_32 with the new meaning. Sorry, I don't have specific macros to detect x86_32 right now but it is supported by gcc.

I thought that the mongrel ABI was properly called "x32" [1][2][3]. Searching for x86_32 just seems to hit a bunch of confused people actually meaning the regular boring 32-bit x86.

While they made an odd naming decision calling it "x32", calling it something else than what it's actually called would be a disservice.

[1] http://gcc.gnu.org/ml/gcc/2011-05/msg00246.html [2] https://sites.google.com/site/x32abi/ [3] http://en.wikipedia.org/wiki/X32_ABI [4] http://wiki.debian.org/X32Port

You're right, I'm not entirely sure where I got the x86_32 naming. Sorry for the confusion. Then there is no need for renaming, and a new macro BOOST_ARCH_X32 or BOOST_ARCH_X86_X32 seems appropriate.

Rene Rivera

12:16 a.m.

On Sun, Apr 21, 2013 at 4:22 PM, Andrey Semashev wrote:

...

On Sunday 21 April 2013 16:00:49 Rene Rivera wrote:

...
Just a quick message to mention that I've finished all the review related changes to the Predef library. And done some of the future tasks on the library. In particular the addition of endianness definitions and the moving of MinGW as a platform instead of a compiler (and hence the addition of BOOST_PLAT category of macros.

And the one question I have is.. When will the review results of the library be decided on? I ask for two reasons. One, the obvious, is just to know if it's accepted or not. And to know if it's not accepted and hence that I should spend time to recreate a "boost/detail/endian.hpp" header that implements the Predef logic for endian detection.

Note the project move to Github earlier this year (in preparation for the Boost git move). You can find the project at < https://github.com/grafikrobot/boost-predef>, and browse the current documentation at http://tinyurl.com/cqqhhev.

I noticed this in the docs:

BOOST_ARCH_X86_64 Intel IA-64 architecture.

x86_64 (aka amd64 and Intel64), which is a widespread extension to IA32 (x86), is not the same as IA64, which is implemented in Itanium CPUs. Could you, please, separate these two architectures?

How weird.. They used to be separate. I must have gotten myself confused in doing the X86_32/64 variants. I'll separate IA64 (as it was before). -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Rene Rivera

23 Apr 23 Apr

3:52 a.m.

On Sun, Apr 21, 2013 at 7:16 PM, Rene Rivera wrote:

...

On Sun, Apr 21, 2013 at 4:22 PM, Andrey Semashev < andrey.semashev@gmail.com> wrote:

...
I noticed this in the docs:

BOOST_ARCH_X86_64 Intel IA-64 architecture.

x86_64 (aka amd64 and Intel64), which is a widespread extension to IA32 (x86), is not the same as IA64, which is implemented in Itanium CPUs. Could you, please, separate these two architectures?

How weird.. They used to be separate. I must have gotten myself confused in doing the X86_32/64 variants. I'll separate IA64 (as it was before).

That change is done. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Andrey Semashev

6:52 a.m.

On Tue, Apr 23, 2013 at 7:52 AM, Rene Rivera wrote:

...

On Sun, Apr 21, 2013 at 7:16 PM, Rene Rivera wrote:

...
On Sun, Apr 21, 2013 at 4:22 PM, Andrey Semashev < andrey.semashev@gmail.com> wrote:

...
I noticed this in the docs:

BOOST_ARCH_X86_64 Intel IA-64 architecture.

x86_64 (aka amd64 and Intel64), which is a widespread extension to IA32 (x86), is not the same as IA64, which is implemented in Itanium CPUs. Could you, please, separate these two architectures?

How weird.. They used to be separate. I must have gotten myself confused in doing the X86_32/64 variants. I'll separate IA64 (as it was before).

That change is done.

Thanks, although BOOST_ARCH_X86_64 description still says "Intel IA-64http://en.wikipedia.org/wiki/Ia64architecture.". It should probably be "Intel64/AMD64 architecture." and link to http://en.wikipedia.org/wiki/Intel64.

Bjorn Reese

22 Apr 22 Apr

10:16 a.m.

On 04/21/2013 11:00 PM, Rene Rivera wrote:

...

Just a quick message to mention that I've finished all the review related changes to the Predef library. And done some of the future tasks on the library. In particular the addition of endianness definitions and the

This is looking very good. I have a minor comment regarding the documentation. In the reference section you list all the pre-defined macros that are used to detect a given Boost.Predef macro. That is not really the kind of information I would expect as a user. Instead I would like to know that I should use BOOST_ARCH_ALPHA to detect the Alpha CPU, and that version number 6.0.0 refers EV6 (aka 21264 [1].) If I want to determine what pre-defined macros are used to create the various Boost.Predef macros, the source is probably a more better place to look. [1] http://en.wikipedia.org/wiki/Alpha_21264

Rene Rivera

23 Apr 23 Apr

3:51 a.m.

On Mon, Apr 22, 2013 at 5:16 AM, Bjorn Reese wrote:

...

On 04/21/2013 11:00 PM, Rene Rivera wrote:

...
Just a quick message to mention that I've finished all the review related changes to the Predef library. And done some of the future tasks on the library. In particular the addition of endianness definitions and the

This is looking very good.

I have a minor comment regarding the documentation. In the reference section you list all the pre-defined macros that are used to detect a given Boost.Predef macro. That is not really the kind of information I would expect as a user. Instead I would like to know that I should use BOOST_ARCH_ALPHA to detect the Alpha CPU, and that version number 6.0.0 refers EV6 (aka 21264 [1].)

I'll add a task to move the documentation towards that as it does seem more informative. But of course is also more work :-)

...

If I want to determine what pre-defined macros are used to create the various Boost.Predef macros, the source is probably a more better place to look.

[1] http://en.wikipedia.org/wiki/**Alpha_21264 http://en.wikipedia.org/wiki/Alpha_21264

______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boosthttp://lists.boost.org/mailman/listinfo.cgi/boost

-- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Petr Machata

22 Apr 22 Apr

3:57 p.m.

Rene Rivera writes:

...

Just a quick message to mention that I've finished all the review related changes to the Predef library. [...] browse the current documentation at http://tinyurl.com/cqqhhev.

I noticed that HP/PA RISC architecture seems to be tied to macro BOOST_ARCH_PARISK. Is that intentional, or a typo? Regarding System/360 and its descendands. A defined __s390x__ actually indicates z/Architecture. If __s390__ is defined, it could be either System/390, or a z/Architecture. FWIW, GCC doesn't seem to define __SYSC_ZARCH__ for z/Architecture machines. I always considered the relation betwenn z/Architecture and s390 to be approximately the same as between i386 and x86_64. Maybe it would make sense to have an overarching is-z-system define, similar to BOOST_ARCH_X86? No idea what to call it though. Also, does it even make sense to add S/370 defines? Can one actually meet such environment in practice? I know that ptrace layer in Linux kernel recently started requiring proper setting of 31bit/24bit backward-compatible flag, so I don't know... maybe there are people actually running 24bit systems. It just somehow seems strange ;) Last, do you envision adding defines for 64-bit PowerPC? I don't know the history here, apparently there's also that RS6000 business that I'm not familiar with at all, but FWIW, __powerpc64__ is the define on Linux. Similarly to above, __powerpc__ would be defined for any PowerPC, 32- or 64-bit one. Oh, and I just realized that there's that 64-bit ARM being cooked. __aarch64__ is the define to check for on Linux. Thanks, PM

Rene Rivera

23 Apr 23 Apr

3:45 a.m.

On Mon, Apr 22, 2013 at 10:57 AM, Petr Machata wrote:

...

Rene Rivera writes:

...
Just a quick message to mention that I've finished all the review related changes to the Predef library. [...] browse the current documentation at http://tinyurl.com/cqqhhev.

I noticed that HP/PA RISC architecture seems to be tied to macro BOOST_ARCH_PARISK. Is that intentional, or a typo?

It's intentional. As, AFAIK, PA-RISC is the common name for that architecture. And also the macros it's based on for the version information are also PA_RISC.

...

Regarding System/360 and its descendands. A defined __s390x__ actually indicates z/Architecture. If __s390__ is defined, it could be either System/390, or a z/Architecture. FWIW, GCC doesn't seem to define __SYSC_ZARCH__ for z/Architecture machines.

I can't claim to know much about those.. But is __SYSC_ZARCH__ enough ro match any z/Architecture regardless of the s390 defines? If you think those detections are bugs.. Could you add a bug in github to that effect? -- Just so that I don't forgot about it ;-)

...

I always considered the relation betwenn z/Architecture and s390 to be approximately the same as between i386 and x86_64. Maybe it would make sense to have an overarching is-z-system define, similar to BOOST_ARCH_X86? No idea what to call it though.

Hm.. Perhaps. Is that a popular understanding of those architectures?

...

Also, does it even make sense to add S/370 defines? Can one actually meet such environment in practice? I know that ptrace layer in Linux kernel recently started requiring proper setting of 31bit/24bit backward-compatible flag, so I don't know... maybe there are people actually running 24bit systems. It just somehow seems strange ;)

Don't know.. Although anything is possible with emulation.

...

Last, do you envision adding defines for 64-bit PowerPC? I don't know the history here, apparently there's also that RS6000 business that I'm not familiar with at all, but FWIW, __powerpc64__ is the define on Linux. Similarly to above, __powerpc__ would be defined for any PowerPC, 32- or 64-bit one.

Yes, if it seems useful to have that distinction. Although as pointed out by others.. At some point separately detecting/defining ABI sizes might be more apt. I'm not out to be dogmatic or pedantic in this library.. Just to provide as much information we can gather from existing definitions. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Bjorn Reese

9:47 a.m.

On 04/23/2013 05:45 AM, Rene Rivera wrote:

...

On Mon, Apr 22, 2013 at 10:57 AM, Petr Machata wrote:

...

It's intentional. As, AFAIK, PA-RISC is the common name for that architecture. And also the macros it's based on for the version information are also PA_RISC.

I think he is refering to the RISK versus RISC spelling.

...

I can't claim to know much about those.. But is __SYSC_ZARCH__ enough ro match any z/Architecture regardless of the s390 defines? If you think those

Not really. __SYSC_ZARCH__ is only defined by the Dignum Systems/C++ compiler.

...

...
I always considered the relation betwenn z/Architecture and s390 to be approximately the same as between i386 and x86_64. Maybe it would make sense to have an overarching is-z-system define, similar to BOOST_ARCH_X86? No idea what to call it though.

Hm.. Perhaps. Is that a popular understanding of those architectures?

z/Architecture is LP64, and is backwards compatible with System/390 which is ILP32 (well almost, as pointers are only 31-bits wide.) See: http://www.redbooks.ibm.com/redpapers/pdfs/redp9110.pdf I suggest "System z" as the common name: http://en.wikipedia.org/wiki/IBM_System_z

...

...
Also, does it even make sense to add S/370 defines? Can one actually

I don't think so. I am not even sure if you can get a C++ compiler for it.

...

...
meet such environment in practice? I know that ptrace layer in Linux kernel recently started requiring proper setting of 31bit/24bit backward-compatible flag, so I don't know... maybe there are people actually running 24bit systems. It just somehow seems strange ;)

24-bits is a System/360 legacy.

Petr Machata

3:08 p.m.

Bjorn Reese writes:

...

On 04/23/2013 05:45 AM, Rene Rivera wrote:

...
On Mon, Apr 22, 2013 at 10:57 AM, Petr Machata wrote:

...
It's intentional. As, AFAIK, PA-RISC is the common name for that architecture. And also the macros it's based on for the version information are also PA_RISC.

I think he is refering to the RISK versus RISC spelling.

Yes, that was my point.

...

...
I can't claim to know much about those.. But is __SYSC_ZARCH__ enough ro match any z/Architecture regardless of the s390 defines? If you think those

Not really. __SYSC_ZARCH__ is only defined by the Dignum Systems/C++ compiler.

Right. What I meant to say was that __SYSC_ZARCH__ is not defined by GCC at all. On GCC, __s390__ is the define for both, and __s390x__ explicitly for the 64-bit one.

...

...
...
I always considered the relation betwenn z/Architecture and s390 to be approximately the same as between i386 and x86_64. Maybe it would make sense to have an overarching is-z-system define, similar to BOOST_ARCH_X86? No idea what to call it though.

Hm.. Perhaps. Is that a popular understanding of those architectures?

z/Architecture is LP64, and is backwards compatible with System/390 which is ILP32 (well almost, as pointers are only 31-bits wide.) See:

Right. To answer the original question, yes, I believe that's a popular understanding. E.g. GCC for s390x can produce s390 binaries when given the -m31 command-line option. strace and ltrace compiled for s390x can "cross-trace" s390 processes. 64-bit s390x Linux kernel supports launching processes in 31-bit execution mode. Etc. Exactly the same as for x86_64/x86 or ppc64/ppc. Thanks, PM

Rene Rivera

26 Apr 26 Apr

2:54 a.m.

On Tue, Apr 23, 2013 at 10:08 AM, Petr Machata wrote:

...

Bjorn Reese writes:

...
On 04/23/2013 05:45 AM, Rene Rivera wrote:

...
On Mon, Apr 22, 2013 at 10:57 AM, Petr Machata wrote:

...
It's intentional. As, AFAIK, PA-RISC is the common name for that architecture. And also the macros it's based on for the version information are also PA_RISC.

I think he is refering to the RISK versus RISC spelling.

Yes, that was my point.

D'oh.. Yes, it's a typo :-\

...

...
...
I can't claim to know much about those.. But is __SYSC_ZARCH__ enough ro match any z/Architecture regardless of the s390 defines? If you think those

Not really. __SYSC_ZARCH__ is only defined by the Dignum Systems/C++ compiler.

Right. What I meant to say was that __SYSC_ZARCH__ is not defined by GCC at all. On GCC, __s390__ is the define for both, and __s390x__ explicitly for the 64-bit one.

...
...
...
I always considered the relation betwenn z/Architecture and s390 to be approximately the same as between i386 and x86_64. Maybe it would make sense to have an overarching is-z-system define, similar to BOOST_ARCH_X86? No idea what to call it though.

Hm.. Perhaps. Is that a popular understanding of those architectures?

z/Architecture is LP64, and is backwards compatible with System/390 which is ILP32 (well almost, as pointers are only 31-bits wide.) See:

Right. To answer the original question, yes, I believe that's a popular understanding. E.g. GCC for s390x can produce s390 binaries when given the -m31 command-line option. strace and ltrace compiled for s390x can "cross-trace" s390 processes. 64-bit s390x Linux kernel supports launching processes in 31-bit execution mode. Etc. Exactly the same as for x86_64/x86 or ppc64/ppc.

OK, thanks for the clarifications. I'd say it's then safe to add a category for those. Perhaps ARCH_SYSZ. And the defs could be ARCH_SYSZ_64 and ARCH_SYSZ_S390 (and dropping 370). -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Bjorn Reese

9 May 9 May

10:39 a.m.

On 04/23/2013 05:08 PM, Petr Machata wrote:

...

Right. What I meant to say was that __SYSC_ZARCH__ is not defined by GCC at all. On GCC, __s390__ is the define for both, and __s390x__ explicitly for the 64-bit one.

I just noticed that clang defines __zarch__ in addition to __s390__ and __s390x__.

Ioannis Papadopoulos

27 Apr 27 Apr

6:32 a.m.

On 04/21/2013 04:00 PM, Rene Rivera wrote:

...

Just a quick message to mention that I've finished all the review related changes to the Predef library. And done some of the future tasks on the library. In particular the addition of endianness definitions and the moving of MinGW as a platform instead of a compiler (and hence the addition of BOOST_PLAT category of macros.

And the one question I have is.. When will the review results of the library be decided on? I ask for two reasons. One, the obvious, is just to know if it's accepted or not. And to know if it's not accepted and hence that I should spend time to recreate a "boost/detail/endian.hpp" header that implements the Predef logic for endian detection.

Note the project move to Github earlier this year (in preparation for the Boost git move). You can find the project at < https://github.com/grafikrobot/boost-predef>, and browse the current documentation at http://tinyurl.com/cqqhhev.

Can I suggest some additions? 1) Cray compiler: The cray compiler defines _CRAYC to detect the compiler, _RELEASE for the major release level, _RELEASE_MINOR for the minor release level and _RELEASE_STRING the above as a string. From: http://docs.cray.com/cgi-bin/craydoc.cgi?mode=View;id=S-2179-81;idx=books_se... 2) Cray platforms and IBM Blue Gene: A good set of their macros is here (I have used those with success): https://wiki.alcf.anl.gov/parts/index.php/Preprocessor_Macros I can provide patches in 1-2 weeks if you prefer that.

Michael Marcin

8:03 a.m.

On 4/27/2013 1:32 AM, Ioannis Papadopoulos wrote:

...

On 04/21/2013 04:00 PM, Rene Rivera wrote:

...
Just a quick message to mention that I've finished all the review related changes to the Predef library. And done some of the future tasks on the library. In particular the addition of endianness definitions and the moving of MinGW as a platform instead of a compiler (and hence the addition of BOOST_PLAT category of macros.

And the one question I have is.. When will the review results of the library be decided on? I ask for two reasons. One, the obvious, is just to know if it's accepted or not. And to know if it's not accepted and hence that I should spend time to recreate a "boost/detail/endian.hpp" header that implements the Predef logic for endian detection.

Note the project move to Github earlier this year (in preparation for the Boost git move). You can find the project at < https://github.com/grafikrobot/boost-predef>, and browse the current documentation at http://tinyurl.com/cqqhhev.

Can I suggest some additions?

Also seems to be missing iOS. #include #if TARGET_IPHONE_SIMULATOR #if TARGET_OS_MAC #if TARGET_OS_IPHONE note not #ifdef There is also #include Which has: #if __IPHONE_OS_VERSION_MIN_REQUIRED >= 50000 #if __IPHONE_OS_VERSION_MAX_ALLOWED > __IPHONE_5_1

Bjorn Reese

9:54 a.m.

On 04/27/2013 10:03 AM, Michael Marcin wrote:

...

Also seems to be missing iOS.

#include [...] #include

How do we detect that these headers are available?

Rene Rivera

4:07 p.m.

I have been waiting on adding iOS defs while I figure out the nicest way to do them. But I added an issue for this now. On Sat, Apr 27, 2013 at 4:54 AM, Bjorn Reese wrote:

...

On 04/27/2013 10:03 AM, Michael Marcin wrote:

Also seems to be missing iOS.

...
#include

[...]

...
#include

How do we detect that these headers are available?

______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boosthttp://lists.boost.org/mailman/listinfo.cgi/boost

Michael Marcin

8:07 p.m.

On 4/27/2013 11:07 AM, Rene Rivera wrote:

...

I have been waiting on adding iOS defs while I figure out the nicest way to do them. But I added an issue for this now.

A few more you could possibly add: #if defined(_XBOX) # if defined(_XENON) || (_XBOX_VER == 200) # define BOOST_OS_XBOX360 # else # define BOOST_OS_XBOX # endif #endif #if defined(R5900) # define BOOST_OS_PS2 #endif #if defined(__CELLOS_LV2__) # define BOOST_OS_PS3 #endif #if defined(GEKKO) # define BOOST_OS_GAMECUBE #endif #if defined(RVL) # define BOOST_OS_WII #endif #if defined(__espresso__) # define BOOST_OS_WIIU #endif #if defined(__psp__) # define BOOST_OS_PSP #endif #if defined(__psp2__) # define BOOST_OS_PSVITA #endif #if defined(_arch_dreamcast) # define BOOST_OS_DREAMCAST #endif #if defined(NN_PLATFORM_CTR) # define BOOST_OS_3DS #endif #if defined(SDK_TWL) # define BOOST_OS_DSI #elif defined(SDK_ARM9) // this may pull in too many platforms # define BOOST_OS_NDS #endif

Michael Marcin

8:54 p.m.

On 4/27/2013 3:07 PM, Michael Marcin wrote:

...

On 4/27/2013 11:07 AM, Rene Rivera wrote:

...
I have been waiting on adding iOS defs while I figure out the nicest way to do them. But I added an issue for this now.

A few more you could possibly add:

Also: #if defined(__native_client__) # define BOOST_OS_NATIVECLIENT #endif

Rene Rivera

4:20 p.m.

On Sat, Apr 27, 2013 at 1:32 AM, Ioannis Papadopoulos

...

wrote:

...

On 04/21/2013 04:00 PM, Rene Rivera wrote:

...
Just a quick message to mention that I've finished all the review related changes to the Predef library. And done some of the future tasks on the library. In particular the addition of endianness definitions and the moving of MinGW as a platform instead of a compiler (and hence the addition of BOOST_PLAT category of macros.

And the one question I have is.. When will the review results of the library be decided on? I ask for two reasons. One, the obvious, is just to know if it's accepted or not. And to know if it's not accepted and hence that I should spend time to recreate a "boost/detail/endian.hpp" header that implements the Predef logic for endian detection.

Note the project move to Github earlier this year (in preparation for the Boost git move). You can find the project at < https://github.com/**grafikrobot/boost-predef https://github.com/grafikrobot/boost-predef>, and browse the current documentation at http://tinyurl.com/cqqhhev.

Can I suggest some additions?

1) Cray compiler:

The cray compiler defines _CRAYC to detect the compiler, _RELEASE for the major release level, _RELEASE_MINOR for the minor release level and _RELEASE_STRING the above as a string.

From: http://docs.cray.com/cgi-bin/**craydoc.cgi?mode=View;id=S-** 2179-81;idx=books_search;this_**sort=title;q=;type=books;** title=Cray%20C%20and%20C%2b%**2b%20Reference%20Manualhttp://docs.cray.com/cgi-bin/craydoc.cgi?mode=View;id=S-2179-81;idx=books_se...

OK.. Added an issues https://github.com/grafikrobot/boost-predef/issues/8. 2) Cray platforms and IBM Blue Gene:

...

A good set of their macros is here (I have used those with success): https://wiki.alcf.anl.gov/**parts/index.php/Preprocessor_**Macros https://wiki.alcf.anl.gov/parts/index.php/Preprocessor_Macros

I can provide patches in 1-2 weeks if you prefer that.

Patches are certainly welcome.. Especially since that way the code will be tested ahead of time. I'll work on formalizing the PLAT defs < https://github.com/grafikrobot/boost-predef/issues/5> to make it easier for those patches though. I added issues for those platforms also < https://github.com/grafikrobot/boost-predef/issues/7>, < https://github.com/grafikrobot/boost-predef/issues/6>. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Ioannis Papadopoulos

2 May 2 May

6:37 p.m.

On 04/27/2013 11:20 AM, Rene Rivera wrote:

...

On Sat, Apr 27, 2013 at 1:32 AM, Ioannis Papadopoulos
...
wrote:

...
On 04/21/2013 04:00 PM, Rene Rivera wrote:

...
Just a quick message to mention that I've finished all the review related changes to the Predef library. And done some of the future tasks on the library. In particular the addition of endianness definitions and the moving of MinGW as a platform instead of a compiler (and hence the addition of BOOST_PLAT category of macros.

And the one question I have is.. When will the review results of the library be decided on? I ask for two reasons. One, the obvious, is just to know if it's accepted or not. And to know if it's not accepted and hence that I should spend time to recreate a "boost/detail/endian.hpp" header that implements the Predef logic for endian detection.

Note the project move to Github earlier this year (in preparation for the Boost git move). You can find the project at < https://github.com/**grafikrobot/boost-predef https://github.com/grafikrobot/boost-predef>, and browse the current documentation at http://tinyurl.com/cqqhhev.

Can I suggest some additions?

1) Cray compiler:

The cray compiler defines _CRAYC to detect the compiler, _RELEASE for the major release level, _RELEASE_MINOR for the minor release level and _RELEASE_STRING the above as a string.

From: http://docs.cray.com/cgi-bin/**craydoc.cgi?mode=View;id=S-** 2179-81;idx=books_search;this_**sort=title;q=;type=books;** title=Cray%20C%20and%20C%2b%**2b%20Reference%20Manualhttp://docs.cray.com/cgi-bin/craydoc.cgi?mode=View;id=S-2179-81;idx=books_se...

OK.. Added an issues https://github.com/grafikrobot/boost-predef/issues/8.

2) Cray platforms and IBM Blue Gene:

...
A good set of their macros is here (I have used those with success): https://wiki.alcf.anl.gov/**parts/index.php/Preprocessor_**Macros https://wiki.alcf.anl.gov/parts/index.php/Preprocessor_Macros

I can provide patches in 1-2 weeks if you prefer that.

Patches are certainly welcome.. Especially since that way the code will be tested ahead of time. I'll work on formalizing the PLAT defs < https://github.com/grafikrobot/boost-predef/issues/5> to make it easier for those patches though. I added issues for those platforms also < https://github.com/grafikrobot/boost-predef/issues/7>, < https://github.com/grafikrobot/boost-predef/issues/6>.

While making the patches for I noticed the following (using test/info_as_cpp.cpp) : For Intel 13: ** Detected ** BOOST_ARCH_X86 = 1 (0,0,1) | Intel x86 BOOST_ARCH_X86_32 = 60000000 (6,0,0) | Intel x86-32 BOOST_ARCH_X86_64 = 1 (0,0,1) | Intel x86-64 BOOST_COMP_EDG = 40400000 (4,4,0) | EDG C++ Frontend BOOST_COMP_GNUC = 40700000 (4,7,0) | Gnu GCC C/C++ BOOST_COMP_INTEL = 30100000 (3,1,0) | Intel C/C++ BOOST_ENDIAN_LITTLE_BYTE = 1 (0,0,1) | Byte-Swapped Little-Endian BOOST_LANG_STDC = 1 (0,0,1) | Standard C BOOST_LANG_STDCPP = 271100001 (27,11,1) | Standard C++ BOOST_LIB_C_GNU = 21500000 (2,15,0) | GNU BOOST_LIB_STD_GNU = 420900021 (42,9,21) | GNU BOOST_OS_LINUX = 1 (0,0,1) | Linux BOOST_OS_UNIX = 1 (0,0,1) | Unix Environment It detects three different architectures (but it does not say which one I am using). It also incorrectly says that it is GCC compiler. This is because Intel likes to do that for compatibility with GCC (I believe clang also defines __GNUC_). This leads to the question that if another macro is required that says that the compiler may identify itself as a GCC (or whatever else).

Rene Rivera

3 May 3 May

4:40 a.m.

On Thu, May 2, 2013 at 1:37 PM, Ioannis Papadopoulos wrote:

...

While making the patches for I noticed the following (using test/info_as_cpp.cpp) :

For Intel 13:

** Detected ** BOOST_ARCH_X86 = 1 (0,0,1) | Intel x86 BOOST_ARCH_X86_32 = 60000000 (6,0,0) | Intel x86-32 BOOST_ARCH_X86_64 = 1 (0,0,1) | Intel x86-64 BOOST_COMP_EDG = 40400000 (4,4,0) | EDG C++ Frontend BOOST_COMP_GNUC = 40700000 (4,7,0) | Gnu GCC C/C++ BOOST_COMP_INTEL = 30100000 (3,1,0) | Intel C/C++ BOOST_ENDIAN_LITTLE_BYTE = 1 (0,0,1) | Byte-Swapped Little-Endian BOOST_LANG_STDC = 1 (0,0,1) | Standard C BOOST_LANG_STDCPP = 271100001 (27,11,1) | Standard C++ BOOST_LIB_C_GNU = 21500000 (2,15,0) | GNU BOOST_LIB_STD_GNU = 420900021 (42,9,21) | GNU BOOST_OS_LINUX = 1 (0,0,1) | Linux BOOST_OS_UNIX = 1 (0,0,1) | Unix Environment

It detects three different architectures (but it does not say which one I am using).

Interesting.. On my x86 Mac with Xcode/GCC/LLVM it only detects x86_64.. === ** Detected ** BOOST_ARCH_X86 = 1 (0,0,1) | Intel x86 BOOST_ARCH_X86_64 = 1 (0,0,1) | Intel x86-64 BOOST_COMP_GNUC = 40200001 (4,2,1) | Gnu GCC C/C++ BOOST_COMP_LLVM = 1 (0,0,1) | LLVM BOOST_ENDIAN_LITTLE_BYTE = 1 (0,0,1) | Byte-Swapped Little-Endian BOOST_LANG_OBJC = 1 (0,0,1) | Objective-C BOOST_LANG_STDC = 1 (0,0,1) | Standard C BOOST_OS_MACOS = 100000000 (10,0,0) | Mac OS ** Not Detected ** === And given the version number it detects for you on x86_32 of 6.0.0 it means that the Intel compiler is, I would guess, trying to say that it's targeting both at the same time? It would be nice decipher why it's doing that. Could you send me the default preprocessor macros it defines for you?

...

It also incorrectly says that it is GCC compiler. This is because Intel likes to do that for compatibility with GCC (I believe clang also defines __GNUC_).

This is actually intentional, even if a bit confusing. If a compiler decides that it wants to emulate another compiler it's OK for me to detect both compilers at once. It's then up to users to decide if the compiler does actually emulate the compiler correctly. Basically I err on the side of more information.

...

This leads to the question that if another macro is required that says that the compiler may identify itself as a GCC (or whatever else).

A user would need to decide if they care about a compiler claiming emulation of another compiler. For example by testing for the Intel compiler first. I'll make a note to document this rational in the documentation though :-) -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Bjorn Reese

11:10 a.m.

On 05/03/2013 06:40 AM, Rene Rivera wrote:

...

...
It also incorrectly says that it is GCC compiler. This is because Intel likes to do that for compatibility with GCC (I believe clang also defines __GNUC_).

This is actually intentional, even if a bit confusing. If a compiler decides that it wants to emulate another compiler it's OK for me to detect both compilers at once. It's then up to users to decide if the compiler does actually emulate the compiler correctly. Basically I err on the side of more information.

The following is a quote from the predef.sourceforge.net pages: "Notice that the meaning of the __GNUC__ macro has changed subtly over the years, from identifying the GNU C/C++ compiler to identifying any compiler that implements the GNU compiler extensions (see the "Feature request - a macro defined for GCC" [1] discussion for further information). For example, the Intel C++ on Linux also defines these macros from version 8.1 (see the "Intel C++ Compiler 8.1 for Linux Release Notes" [2] and "Intel Compilers for Linux: Compatibility with GNU Compilers" [3].)" [1] http://gcc.gnu.org/ml/gcc/2008-07/threads.html#00025 [2] ftp://download.intel.com/support/performancetools/c/linux/sb/clin81_relnotes.pdf) [3] http://software.intel.com/en-us/articles/intel-compilers-for-linux-compatibi... The way to avoid false positives, is to know which other compilers define the GCC macros, and test for these first. For instance: #if defined(__INTEL_COMPILER) // Do Intel stuff #else # if defined(__GNUC__) // Do GCC stuff # endif #endif

Ioannis Papadopoulos

7:02 p.m.

On 05/02/2013 11:40 PM, Rene Rivera wrote:

...

On Thu, May 2, 2013 at 1:37 PM, Ioannis Papadopoulos wrote:

...
While making the patches for I noticed the following (using test/info_as_cpp.cpp) :

For Intel 13:

** Detected ** BOOST_ARCH_X86 = 1 (0,0,1) | Intel x86 BOOST_ARCH_X86_32 = 60000000 (6,0,0) | Intel x86-32 BOOST_ARCH_X86_64 = 1 (0,0,1) | Intel x86-64 BOOST_COMP_EDG = 40400000 (4,4,0) | EDG C++ Frontend BOOST_COMP_GNUC = 40700000 (4,7,0) | Gnu GCC C/C++ BOOST_COMP_INTEL = 30100000 (3,1,0) | Intel C/C++ BOOST_ENDIAN_LITTLE_BYTE = 1 (0,0,1) | Byte-Swapped Little-Endian BOOST_LANG_STDC = 1 (0,0,1) | Standard C BOOST_LANG_STDCPP = 271100001 (27,11,1) | Standard C++ BOOST_LIB_C_GNU = 21500000 (2,15,0) | GNU BOOST_LIB_STD_GNU = 420900021 (42,9,21) | GNU BOOST_OS_LINUX = 1 (0,0,1) | Linux BOOST_OS_UNIX = 1 (0,0,1) | Unix Environment

It detects three different architectures (but it does not say which one I am using).

Interesting.. On my x86 Mac with Xcode/GCC/LLVM it only detects x86_64..

=== ** Detected ** BOOST_ARCH_X86 = 1 (0,0,1) | Intel x86 BOOST_ARCH_X86_64 = 1 (0,0,1) | Intel x86-64 BOOST_COMP_GNUC = 40200001 (4,2,1) | Gnu GCC C/C++ BOOST_COMP_LLVM = 1 (0,0,1) | LLVM BOOST_ENDIAN_LITTLE_BYTE = 1 (0,0,1) | Byte-Swapped Little-Endian BOOST_LANG_OBJC = 1 (0,0,1) | Objective-C BOOST_LANG_STDC = 1 (0,0,1) | Standard C BOOST_OS_MACOS = 100000000 (10,0,0) | Mac OS ** Not Detected ** ===

And given the version number it detects for you on x86_32 of 6.0.0 it means that the Intel compiler is, I would guess, trying to say that it's targeting both at the same time? It would be nice decipher why it's doing that. Could you send me the default preprocessor macros it defines for you?

I'm attaching both for intel 12.1 and intel 13 (they're similar).

...

...
It also incorrectly says that it is GCC compiler. This is because Intel likes to do that for compatibility with GCC (I believe clang also defines __GNUC_).

This is actually intentional, even if a bit confusing. If a compiler decides that it wants to emulate another compiler it's OK for me to detect both compilers at once. It's then up to users to decide if the compiler does actually emulate the compiler correctly. Basically I err on the side of more information.

That's fine, but then BOOST_COMP_GNUC then is not just "GNU C/C++ compiler", but rather "GNU C/C++ and all the ones that emulated it". I think that defeats the purpose of detecting the compiler.

...

...
This leads to the question that if another macro is required that says that the compiler may identify itself as a GCC (or whatever else).

A user would need to decide if they care about a compiler claiming emulation of another compiler. For example by testing for the Intel compiler first.

However, isn't that boilerplate code for the user that could be handled in Boost.Predef? I believe that it would be more useful to get which compiler I'm using AND a macro that says that it offers GNU compatibility for example (I am not aware of another compiler that other compilers try to impersonate).

...

I'll make a note to document this rational in the documentation though :-)

Jason Roehm

8:04 p.m.

On 05/03/2013 03:02 PM, Ioannis Papadopoulos wrote:

...

...
This is actually intentional, even if a bit confusing. If a compiler decides that it wants to emulate another compiler it's OK for me to detect both compilers at once. It's then up to users to decide if the compiler does actually emulate the compiler correctly. Basically I err on the side of more information.

That's fine, but then BOOST_COMP_GNUC then is not just "GNU C/C++ compiler", but rather "GNU C/C++ and all the ones that emulated it".

I think that defeats the purpose of detecting the compiler.

...
...
This leads to the question that if another macro is required that says that the compiler may identify itself as a GCC (or whatever else).

A user would need to decide if they care about a compiler claiming emulation of another compiler. For example by testing for the Intel compiler first.

However, isn't that boilerplate code for the user that could be handled in Boost.Predef? I believe that it would be more useful to get which compiler I'm using AND a macro that says that it offers GNU compatibility for example (I am not aware of another compiler that other compilers try to impersonate).

I'll throw in my small voice to agree with Ioannis. While the Intel compiler does emulate a lot of GNU extensions, most of the time, if I'm trying to detect the compiler that is being used, I'm very much concerned with the distinction between gcc and icc. Specifically, if you're trying to write conditional statements to work around a compiler bug, then it would be nice if Boost.Predef could be used to easily get an unambiguous answer about which compiler is actually in use. Maybe it would make sense to have two parallel interfaces: one that treats Intel/GNU as equivalent and another more pedantic one that does not. Jason

Andrey Semashev

8:17 p.m.

On Friday 03 May 2013 16:04:39 Jason Roehm wrote:

...

On 05/03/2013 03:02 PM, Ioannis Papadopoulos wrote:

...
...
This is actually intentional, even if a bit confusing. If a compiler decides that it wants to emulate another compiler it's OK for me to detect both compilers at once. It's then up to users to decide if the compiler does actually emulate the compiler correctly. Basically I err on the side of more information.

That's fine, but then BOOST_COMP_GNUC then is not just "GNU C/C++ compiler", but rather "GNU C/C++ and all the ones that emulated it".

I think that defeats the purpose of detecting the compiler.

...
...
This leads to the question that if another macro is required that says that the compiler may identify itself as a GCC (or whatever else).

A user would need to decide if they care about a compiler claiming emulation of another compiler. For example by testing for the Intel compiler first.

However, isn't that boilerplate code for the user that could be handled in Boost.Predef? I believe that it would be more useful to get which compiler I'm using AND a macro that says that it offers GNU compatibility for example (I am not aware of another compiler that other compilers try to impersonate).

I'll throw in my small voice to agree with Ioannis. While the Intel compiler does emulate a lot of GNU extensions, most of the time, if I'm trying to detect the compiler that is being used, I'm very much concerned with the distinction between gcc and icc. Specifically, if you're trying to write conditional statements to work around a compiler bug, then it would be nice if Boost.Predef could be used to easily get an unambiguous answer about which compiler is actually in use. Maybe it would make sense to have two parallel interfaces: one that treats Intel/GNU as equivalent and another more pedantic one that does not.

+1 May I add that Boost.Config defines BOOST_GCC and BOOST_MSVC only for genuine GCC and MSVC and not for their pretenders. You would typically use these macros when you work around specific compiler bugs and __GNUC__ and _MSC_VER when you target code for GNU or Microsoft extensions. I think Boost.Predef should follow this practice, and its BOOST_COMP_* macros should unambiguously identify the compiler. Another set of macros can be made available to detect GNU or MS C++ dialect.

4203

Age (days ago)

4221

Last active (days ago)

List overview

Download

31 comments

8 participants

participants (8)

Andrey Semashev
Bjorn Reese
Ioannis Papadopoulos
Jason Roehm
Lars Viklund
Michael Marcin
Petr Machata
Rene Rivera