Re: [boost] [Predef] Pre-review comments

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:
> 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