Subject: Re: [boost] [Predef] Pre-review comments
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2012-02-22 01:17:48
On 2/19/2012 6:37 AM, Mathias Gaunard wrote:
> - 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.
> - 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
> 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
Making the above change, would also involve making it clear in
> 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