Boost logo

Boost :

Subject: Re: [boost] [preprocessor] Variadics suggestion
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2012-10-08 15:14:40


On Mon, 08 Oct 2012 09:25:18 -0700, Lorenzo Caminiti wrote:

> On Mon, Oct 8, 2012 at 9:00 AM, Paul Mensonides <pmenso57_at_[hidden]>
> wrote:
>> On Sun, 07 Oct 2012 15:49:40 -0400, Edward Diener wrote:
>>
>>>> 2) For a macro library, do we still need to have a BOOST_ prefix or
>>>> could I just keep the CHAOS_PP_ prefix? I cannot use BOOST_PP_
>>>> without bending over backwards to find contrived names for
>>>> everything, and the namespace of brief names beginning with BOOST_ is
>>>> tiny--especially when a library provides hundreds of user-interface
>>>> (i.e. not implementation detail macros).
>>>
>>> BOOST_CHAOS_PP_... seems normal to me.
>>
>> It seems *way* to long to me.
>
> I don't think so, it's not long. However, "chaos" doesn't mean anything
> so I'd prefer a more descriptive name... maybe for pp meta-programming:

"Chaos" does mean something. It was a reference to chaos theory, where
things look random but are ultimately following rules. There are plenty
of other "terms" I used in Chaos that I look at now and think "where on
Earth did that come from?" Regardless, the name must be short. Unlike
normal code, there are no "say it once" scenarios. I.e. there is no

namespace chaos {
    void f(int);
    inline void g() {
        f(123);
    }
}

-or-

using namespace chaos;

Instead, it must be qualified everywhere--even throughout the
implementation--thousands and thousands of times. What if every name
defined by Boost had boost::library:: on it throughout the
implementation? In Chaos, I use CHAOS_PP_ for an interface prefix and
CHAOS_IP_ for implementation macros (where the distinction is sometimes
helpful when debugging). I suppose BOOST_CP_ and BOOST_CI_ aren't too bad
if they aren't taken, though I actually think CHAOS_PP_ is better. The
best name would be BOOST_PP_ but that is, surprisingly, already taken.

There is another issue I have with submitting Chaos to Boost. Boost
currently requires the use of .hpp file suffixes. However, like
Boost.Preprocessor, but unlike all of the rest of Boost, Chaos is a C
library also. The rule should be amended to allow for headers which are
not specifically C++ headers. Chaos uses the generic .h for precisely
this reason. Note that if .hpp is required, I simply will not submit the
library. No hacks--including those introduced to workaround rules which
should not apply.

You have to understand my point of view:

I do not really care whether Chaos becomes part of Boost or not. It is
just that people keep asking me for that. That is fine unless doing so
makes the library inferior according to my subjective or objective
opinion. If I change the prefix, from CHAOS_PP_ to BOOST_CHAOS_ or
similar, I have to make all of the libray source code longer, and all of
my other present and future code which uses it longer--for no benefit to
me. Why would I do that?

I don't really care how many people use the library. Perhaps that's too
strong. I don't mind if lots of people use it, but not if gaining users
requires compromising the purpose of the library.

I also don't require the Boost stamp of approval. I have internal
motivations to do the work that I do. Not that I mind it, but I do not
need the approval of others--otherwise I would never have gotten involved
in extensive preprocessor usage. That's just asking for controversy and
has garnered plenty of it. As Chaos is defined by a no-compromise
approach, it isn't a question of whether Chaos is suitable for Boost.
It's a question of whether Boost is suitable for Chaos. That's not simply
arrogance. It's about the *purpose* of the library.

I gave up on VC++ for lots of reasons including its preprocessor, so I
don't really care whether the library's presence in Boost somehow causes VC
++'s preprocessor to be fixed--which it probably wouldn't anyway. Even if
it was fixed, it likely wouldn't be for the right reasons, and that will
just lead to a similar situations with different issues. If the library
became part of Boost, and MS subsequently fixed their preprocessor, I
still wouldn't touch VC++ with a ten foot pole unless I somehow became
convinced of a radical change in MS's philosophy (unlikely)--which would
require proving it, not just saying it. The language should be
implemented correctly because it is an ISO standard and the future
portability goals that give that weight--not because some popular library
needs it or a large enough portion of the user base wants it. Generally
speaking (not WRT Chaos), I'm willing to work with compilers that are
trying to implement the standard--not just the parts of the standard that
they agree with or want to. If a compiler does not have 100% conformance
(in the limit) as a primary design goal, I'd rather that compiler fail.
In the case of VC++, I no longer want the preprocessor to be fixed.
Instead, I want VC++ to fall into disuse and die however likely or
unlikely that is.

Developing, implementing, and using a standard is about the future of
computing. Look at Boost itself. It is an enormous mess of workarounds.
The barrier to entry is enormously high almost entirely due to an edifice
of compiler-dependent workarounds. With Boost, you don't target C++, you
target the union (not intersection) of MS C++, GCC C++, clang C++, Sun C+
+, and so on. That's okay for something intended to be portable and
practical at a specific point in time, but it stunts innovation even more
than backwards compatibility requirements do. For me, Boost.Preprocessor
is an ugly-but-practical solution that exists at a certain point of time.
It has nowhere to go of technological significance given its requirements.

Not that I'm suggesting this, but what would Boost look like if it was
written to target *C++* in the theoretical case where such compilers
existed? I believe it again would be a platform for innovative (in the
technical C++ sense) which is something I think has been lost to some
degree. At the very least, it would be clean and often elegant code.
When either backward compatibility or compiler compatibility are
fundamental design goals, eventually a library reaches a critical mass,
can no longer innovate, and can barely be maintained. Not that I'm
opposed to the modularization work (though I'd take hg over git any day of
the week), but I'm not convinced that a lack of modularization is what is
causing the majority of the underlying maintenance issues. (Perhaps
modularization is an effective way to shelve those sub-libraries to make
room for those sub-libraries that have not yet reached critical mass.)

WRT Chaos, the library was and is supposed to be a technical exercise used
to explore what a preprocessor metaprogramming library could be in theory
via the creation, development, and usage of advanced technique. As a
preprocessor metaprogramming library, it *happens* to be practical in all
situations where Boost.Preprocessor would be practical and the
preprocessor *happens* to be good enough. Those cases (that I know of)
include gcc, *almost* includes clang, and EDG-based compilers (last time I
checked). I haven't checked any others recently, so there may be more.

So what motivation is there for me to make things more obnoxious to both
implement and use given the fundamental purpose of the library? Chaos
being in Boost gains me nothing which I consider worthwhile. It would
only be altruistic work--which I don't mind, but I will not subvert the
purpose of the library.

Regards,
Paul Mensonides


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk