[Predef] Pre-review comments
Misc ==== - This stuff partially exists in Boost.Config. How will this be integrated? - AMD stands for Advanced Micro Devices, not American Micro Devices - The whole set of C and C++ standard libraries doesn't seem to be covered. Are we supposed to infer it from the compiler or operating system? Naming ====== - BOOST_ARCHITECTURE_ is maybe a bit long. Have you considered a shorter name like BOOST_ARCH_ALPHA ? Same comment for BOOST_LANGUAGE_ - BOOST_LANGUAGE_XXX uses a STD prefix for most languages except for Objective-C. How about dropping the STD prefix? Also why not use CXX instead of CPP? - Standard C library is identified by LIBC, but standard C++ library is identified by LIBSTD. I find that confusing, it should be orthogonal. I take it LIBCXX wasn't chosen due to possible confusion with libc++. It's their fault for choosing a ridiculously broad name. glibc is often just called libc as well, yet this is not a problem. - BOOST_CXX_GNUC might be better as BOOST_CXX_GNU or BOOST_CXX_GCC - BOOST_OS_DRAGONFLY_BSD might be better as BOOST_OS_BSD_DRAGONFLY to indicate that "macro refinement" goes left to right. It could be BOOST_OS_BSD_FREEBSD for FreeBSD. Compiler frontend vs backend ============================ The BOOST_CXX_ macros is used to define both frontends (BOOST_CXX_CLANG, BOOST_CXX_EDG) and backends (BOOST_CXX_LLVM) and things that can be both (BOOST_CXX_GNUC) As for BOOST_CXX_CYGWIN, I have no idea what it's doing there. Cygwin should be exclusively in BOOST_OS_CYGWIN. The compiler is a normal GCC. As such it might be hard to tell which set of flags might be defined at the same time. Maybe the solution would be to split the set of frontends and backends, with each value in each set being mutually exclusive. Most compilers do not decouple frontends and backends, so it will end up with a lot of unnecessary duplication though. Non-mutually exclusive macros ============================= Currently, the only macros that are not mutually-exclusive (outside of the CXX macros outlined above, since they cover two different things) are the BOOST_OS_BSD macros along with BOOST_OS_UNIX and BOOST_OS_SVR4. It might be a good idea to expand on that on the architecture side (i.e. any x86, 32 or 64 bit), and the compiler side (GCC-like compilers). There are many variants of ARM as well, and a new 64-bit ARM will be released soon. The design needs to be flexible enough to integrate this. It might be good as well to put a clear distinction between a set of mutually-exclusive macros and more global macros that can cover several configurations. My use-cases ============ Just a few real use cases for which I use custom code in my software today, and that I'd be glad to replace: - Work-around a bug in the GCC frontend - Use a feature present in GCC-like frontends - Work-around a bug in the GCC backend - Define special versions of functions for x86 both 32- and 64-bit - Define special versions of functions for x86-64 only - Use special code for Windows or POSIX operating systems (for that, I currently use BOOST_SYSTEM_WINDOWS_API / BOOST_SYSTEM_POSIX_API)
On 2/19/2012 6:37 AM, Mathias Gaunard wrote:
Misc ====
- This stuff partially exists in Boost.Config. How will this be integrated?
It depends on how backwards compatible we wish to be in Boost Config. As far as I know there aren't that many defs in Config that are also in Predef (and I think are just restricted to the informational defs <http://tinyurl.com/6lnuahh>). If backward compatibility is wanted, the best approach I can think of is to change the Config defs to be based on the Predef macros where possible.
- AMD stands for Advanced Micro Devices, not American Micro Devices
Will fix that obviously.
- The whole set of C and C++ standard libraries doesn't seem to be covered. Are we supposed to infer it from the compiler or operating system?
I will gladly add additional libraries. As I expect this library to expand to the set of libraries, and other aspects, that users make use of.
Naming ======
- BOOST_ARCHITECTURE_ is maybe a bit long. Have you considered a shorter name like BOOST_ARCH_ALPHA ? Same comment for BOOST_LANGUAGE_
I tend to prefer the descriptive names. But, yes, I've tried to think of ways to shorten the macro names. And would certainly put on my todo list to solicit naming ideas if wanted.
- BOOST_LANGUAGE_XXX uses a STD prefix for most languages except for Objective-C. How about dropping the STD prefix?
I tried to only use the STD prefix for aspect that are actually "standard". And as far as I know ObjectiveC is not a standard language. Am I wrong on this? If so, could someone point me to the standard for it?
Also why not use CXX instead of CPP?
I was trying to be more formal for the language. But it seems I should change it to match the compiler prefix definitions for consistency. Note, I don't consider the names of things terribly important.. As I'm not a bike-shed kind of person ;-)
- Standard C library is identified by LIBC, but standard C++ library is identified by LIBSTD. I find that confusing, it should be orthogonal.
One aspect of naming I tried to be somewhat consistent about was to use names close to the "source" macros. This is in the hope that it will be more intuitive/familiar to people's usual platforms. With the idea that it will increase adoption if people can more directly map from what they currently use to a minimally different macro.
I take it LIBCXX wasn't chosen due to possible confusion with libc++. It's their fault for choosing a ridiculously broad name. glibc is often just called libc as well, yet this is not a problem.
- BOOST_CXX_GNUC might be better as BOOST_CXX_GNU or BOOST_CXX_GCC
Probably, but as above, I went with what was closest to the source macro.
- BOOST_OS_DRAGONFLY_BSD might be better as BOOST_OS_BSD_DRAGONFLY to indicate that "macro refinement" goes left to right. It could be BOOST_OS_BSD_FREEBSD for FreeBSD.
I actually went back and forth on that set of names a few times. And eventually decided to use names that where close to what the platforms name themselves. But I certainly would go back again. Especially if there are more examples of the same sub-platform division.
Compiler frontend vs backend ============================
The BOOST_CXX_ macros is used to define both frontends (BOOST_CXX_CLANG, BOOST_CXX_EDG) and backends (BOOST_CXX_LLVM) and things that can be both (BOOST_CXX_GNUC)
As for BOOST_CXX_CYGWIN, I have no idea what it's doing there. Cygwin should be exclusively in BOOST_OS_CYGWIN. The compiler is a normal GCC.
As such it might be hard to tell which set of flags might be defined at the same time.
Maybe the solution would be to split the set of frontends and backends, with each value in each set being mutually exclusive. Most compilers do not decouple frontends and backends, so it will end up with a lot of unnecessary duplication though.
Yes, front/back-end distinctions are hard to deal with. And I wish I had a good idea on this one. Having said that.. I do wish to add such distinctions. But it would be something I would not put a high priority on since it's not a commonplace distinction people have to deal with. But I'll reassess if given more feedback :-)
Non-mutually exclusive macros =============================
Currently, the only macros that are not mutually-exclusive (outside of the CXX macros outlined above, since they cover two different things) are the BOOST_OS_BSD macros along with BOOST_OS_UNIX and BOOST_OS_SVR4.
It might be a good idea to expand on that on the architecture side (i.e. any x86, 32 or 64 bit), and the compiler side (GCC-like compilers). There are many variants of ARM as well, and a new 64-bit ARM will be released soon. The design needs to be flexible enough to integrate this.
You mean having, for example, a GCC def (yes I've subconsciously already changed this from GNUC) and a GCC_LLVM? The latter to denote a GCC parser for the LLVM compiler. If that's what you mean, then yes that is a good idea and would follow the general structure of hierarchically defining the definitions.
It might be good as well to put a clear distinction between a set of mutually-exclusive macros and more global macros that can cover several configurations.
Making the above change, would also involve making it clear in documentation.
My use-cases [...] - Work-around a bug in the GCC backend
Is that with a non-GCC front end?
- Define special versions of functions for x86 both 32- and 64-bit - Define special versions of functions for x86-64 only
I have that same use case. And was partly the impetus for me bringing back this library. I have cross-language binding code, ObjectiveC <==> C++, that needs to make ABI distinctions in these cases.
- Use special code for Windows or POSIX operating systems (for that, I currently use BOOST_SYSTEM_WINDOWS_API / BOOST_SYSTEM_POSIX_API)
I'll need to look those up to see how it detects that distinction. PS. Thanks for the comments. And sorry I didn't reply earlier. But The start of the week is always busy for me. And some unexpected events made the past three days a challenge for my time. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 02/22/2012 07:17 AM, Rene Rivera wrote:
On 2/19/2012 6:37 AM, Mathias Gaunard wrote:
My use-cases [...] - Work-around a bug in the GCC backend
Is that with a non-GCC front end?
The bug in question is in the GCC backend, more precisely in the RTL optimization passes. I don't really care what frontend is used as long as code eventually gets through there. In practice, GCC should be the only compiler to use the GCC backend. I know that there are compilers though, that use the GCC frontend but another backend, such as DragonEgg. LLVM doesn't have this bug so I'd rather not add the workaround when compiling with DragonEgg.
- Define special versions of functions for x86 both 32- and 64-bit - Define special versions of functions for x86-64 only
I have that same use case. And was partly the impetus for me bringing back this library. I have cross-language binding code, ObjectiveC <==> C++, that needs to make ABI distinctions in these cases.
But your library does not provide a single macro to test whether I'm on x86 regardless of word size. I have to do #if defined(BOOST_ARCHITECTURE_X86) || defined(BOOST_ARCHITECTURE_AMD64)
PS. Thanks for the comments. And sorry I didn't reply earlier. But The start of the week is always busy for me. And some unexpected events made the past three days a challenge for my time.
No problem, I was starting to wonder if you'd had seen them though ;)
On 2/22/2012 3:28 AM, Mathias Gaunard wrote:
On 02/22/2012 07:17 AM, Rene Rivera wrote:
On 2/19/2012 6:37 AM, Mathias Gaunard wrote:
My use-cases [...] - Work-around a bug in the GCC backend
Is that with a non-GCC front end?
The bug in question is in the GCC backend, more precisely in the RTL optimization passes. I don't really care what frontend is used as long as code eventually gets through there.
In practice, GCC should be the only compiler to use the GCC backend. I know that there are compilers though, that use the GCC frontend but another backend, such as DragonEgg.
LLVM doesn't have this bug so I'd rather not add the workaround when compiling with DragonEgg.
- Define special versions of functions for x86 both 32- and 64-bit - Define special versions of functions for x86-64 only
I have that same use case. And was partly the impetus for me bringing back this library. I have cross-language binding code, ObjectiveC <==> C++, that needs to make ABI distinctions in these cases.
But your library does not provide a single macro to test whether I'm on x86 regardless of word size.
I have to do #if defined(BOOST_ARCHITECTURE_X86) || defined(BOOST_ARCHITECTURE_AMD64)
Technically none of them are detecting word size. They are detecting the instruction-set, and ABI, for the architecture. Which is the key distinction for my use case. The subject of detecting the word size is mostly orthogonal to this. The key question is whether IA64 and AMD64 should be considered sub-categories of X86? And if so, what would we name the "traditional" non-IA64 or AMD64, other than X86? It's starting to sound to me that people want some "meta-architectures" defined as opposed to, or perhaps in addition to, the specific architectures. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 02/25/2012 11:09 PM, Rene Rivera wrote:
I have to do #if defined(BOOST_ARCHITECTURE_X86) || defined(BOOST_ARCHITECTURE_AMD64)
Technically none of them are detecting word size. They are detecting the instruction-set, and ABI, for the architecture. Which is the key distinction for my use case. The subject of detecting the word size is mostly orthogonal to this.
This has nothing to do with detecting word size. I just want to know that I'm on processor part of the x86 family, because there are big similarities between those processors even if they have a different ABI.
The key question is whether IA64 and AMD64 should be considered sub-categories of X86? And if so, what would we name the "traditional" non-IA64 or AMD64, other than X86?
IA64 has nothing to do with the x86 family. It's Itanium. I still don't understand how people can be confused about this. IA64 (Itanium) is completely unrelated to IA32 (x86) other than the fact that both were created by Intel. On ther other hand, amd64 (also known as x86-64) is based on x86 and simply aimed at moving it to 64-bit and fixing a couple of things. As a result, they're very similar architectures, to the point where making the distinction between the two is often useless. I find it worrying that a library that aims at detecting architectures makes the very basic mistake of confusing the most widely used architecture with an old and defunct one that is entirely unrelated. Plus you were told about this in the other thread already.
It's starting to sound to me that people want some "meta-architectures" defined as opposed to, or perhaps in addition to, the specific architectures.
In addition. This is what I said in my original post, when I said it would be nice to add additional not mutually-exclusive macros to cover families of things, just like you already do for BSD-style operating systems.
On 2/22/2012 3:28 AM, Mathias Gaunard wrote:
On 02/22/2012 07:17 AM, Rene Rivera wrote:
On 2/19/2012 6:37 AM, Mathias Gaunard wrote:
My use-cases [...] - Work-around a bug in the GCC backend
Is that with a non-GCC front end?
The bug in question is in the GCC backend, more precisely in the RTL optimization passes. I don't really care what frontend is used as long as code eventually gets through there.
In practice, GCC should be the only compiler to use the GCC backend. I know that there are compilers though, that use the GCC frontend but another backend, such as DragonEgg.
LLVM doesn't have this bug so I'd rather not add the workaround when compiling with DragonEgg.
I'm not sure if there's much that can be done about detecting the various back-ends vs. front-ends as Predef only deals with reflecting what the compiler is saying about itself. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 02/25/2012 11:15 PM, Rene Rivera wrote:
On 2/22/2012 3:28 AM, Mathias Gaunard wrote:
On 02/22/2012 07:17 AM, Rene Rivera wrote:
On 2/19/2012 6:37 AM, Mathias Gaunard wrote:
My use-cases [...] - Work-around a bug in the GCC backend
Is that with a non-GCC front end?
The bug in question is in the GCC backend, more precisely in the RTL optimization passes. I don't really care what frontend is used as long as code eventually gets through there.
In practice, GCC should be the only compiler to use the GCC backend. I know that there are compilers though, that use the GCC frontend but another backend, such as DragonEgg.
LLVM doesn't have this bug so I'd rather not add the workaround when compiling with DragonEgg.
I'm not sure if there's much that can be done about detecting the various back-ends vs. front-ends as Predef only deals with reflecting what the compiler is saying about itself.
DragonEgg and llvm-gcc define both __GNUC__ and __llvm__. I don't see any problem there with telling that it's a GCC frontend with a LLVM backend.
On 02/26/2012 03:25 PM, Bjorn Reese wrote:
On 2012-02-26 14:59, Mathias Gaunard wrote:
DragonEgg and llvm-gcc define both __GNUC__ and __llvm__. I don't see any problem there with telling that it's a GCC frontend with a LLVM backend.
Clang also defines those two macros even though it is not using GCC as a frontend.
But Clang defines __clang__, which the compilers above do not.
On 2/27/2012 2:55 AM, Mathias Gaunard wrote:
On 02/26/2012 03:25 PM, Bjorn Reese wrote:
On 2012-02-26 14:59, Mathias Gaunard wrote:
DragonEgg and llvm-gcc define both __GNUC__ and __llvm__. I don't see any problem there with telling that it's a GCC frontend with a LLVM backend.
Clang also defines those two macros even though it is not using GCC as a frontend.
But Clang defines __clang__, which the compilers above do not.
In other words.. We need to make a distinction between the *actual* compiler vs. the *compatible/emulated* compiler. There are obviously three options to this: 1. Make the default/base/undecorated definitions reflect the *actual* compiler. And add a set of predefs for the *emulated* compiler. 2. Make two different parallel sets of definitions, one for *actual* and one for *emulated*. 3. Make the default/base/undecorated definitions reflect the *emulated* compiler. And add a set for the *actual* compiler. Technically there isn't much difference between them. It's a question about is there a useful default interpretation of "what compiler you are using". I can think that option 2 is less likely to be useful than 1 and 3, and I would put option 3 slightly higher in preference because of the likelihood that if you are writing based on what features a compiler has, it's the compiler interface/API that you are interested in. And hence making your code more forward portable by using a default that reflects the *emulation*. Making the workarounds use cases the minority. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 02/28/2012 07:06 AM, Rene Rivera wrote:
In other words.. We need to make a distinction between the *actual* compiler vs. the *compatible/emulated* compiler. There are obviously three options to this:
I don't think that's a good idea. Just do #if defined(__clang__) frontend is clang #elif ... .... #elif defined(__GNUC__) frontend is GCC #elif ... ... #endif The whole mechanism to detect what the frontend is should be a chain of if/elif in a single file. I thought this much was a given. This is how Boost.Config and Boost.Detect work.
1. Make the default/base/undecorated definitions reflect the *actual* compiler. And add a set of predefs for the *emulated* compiler.
2. Make two different parallel sets of definitions, one for *actual* and one for *emulated*.
3. Make the default/base/undecorated definitions reflect the *emulated* compiler. And add a set for the *actual* compiler.
This looks like it would be very hard to maintain and hard to ensure that it is correct. It also assumes that all compilers that emulate other compilers do it in an uniform way.
Rene Rivera wrote:
On 2/19/2012 6:37 AM, Mathias Gaunard wrote:
- BOOST_ARCHITECTURE_ is maybe a bit long. Have you considered a shorter name like BOOST_ARCH_ALPHA ? Same comment for BOOST_LANGUAGE_
I tend to prefer the descriptive names. But, yes, I've tried to think of ways to shorten the macro names. And would certainly put on my todo list to solicit naming ideas if wanted.
"ARCH" and "LANG" are common abbreviations, so they wouldn't be bad alternatives. They do, however, deviate from normal Boost practice.
Also why not use CXX instead of CPP?
I was trying to be more formal for the language. But it seems I should change it to match the compiler prefix definitions for consistency.
I think consistency within your library is more important than consistency with the source macros. This makes cross-platform code more readable and consistent.
Note, I don't consider the names of things terribly important.. As I'm not a bike-shed kind of person ;-)
A person can memorize only so much. A good name is easier to recall, so naming is important, even if it can sometimes devolve into seemingly fruitless bickering. (I work hard to express and defend my naming ideas until a decision is made. Once made, I accept the decision.)
- Standard C library is identified by LIBC, but standard C++ library is identified by LIBSTD. I find that confusing, it should be orthogonal.
One aspect of naming I tried to be somewhat consistent about was to use names close to the "source" macros. This is in the hope that it will be more intuitive/familiar to people's usual platforms. With the idea that it will increase adoption if people can more directly map from what they currently use to a minimally different macro.
That's a useful take on naming, but it leads to inconsistent names for the same things with different compilers or libraries. Consistency within your library should be paramount. After all, your goal is that your names become *the* standard for all of Boost and, indirectly, for lots of other code. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (4)
-
Bjorn Reese -
Mathias Gaunard -
Rene Rivera -
Stewart, Robert