Boost logo

Boost :

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2003-04-15 03:06:13

Paul Mensonides wrote:
> >> It is not an interface macro. You can use it (e.g.
> >> BOOST_PP_IS_UNARY), and it will remain, but I do not want to make
> >> interfaces public that don't work properly on all major vendors.
> >
> > Why? I understand that, as the library author, you would much prefer
> > all the facilities work properly on all the compilers (I, for
> > instance, wish that was true for MPL as well), but _not including_ a
> > generally useful and wanted by real-world users functionality into
> > the library because a couple of vendors have broken compilers is
> > exactly the strategy I wouldn't expect any boost library to take.
> And it is the strategy taken by the pp-lib as well.

I suppose you meant the opposite.

> The sheer amount of hacks contained in the pp-lib to make things work
> on broken preprocessors is evidence of this. It contains nearly four
> separate implementations of the same thing--just for that purpose.

I know, and your willingness to make the library work on these broken
preprocessors is much appreciated.

> However: at a certain point, that level of 'hacking' becomes a
> maintenance nightmare, as does fracturing portability by
> enabling and disabling features on various compilers.

I would say I don't see how saying "this feature doesn't works on such
and such compilers" leads to a maintenance nightmare. It's definitely
less work for the maintainer, isn't it? Say, if portability wasn't
one of the important goals of the MPL, I would _gladly_ give up some
of the workarounds for a simple statement "this doesn't work on broken
compilers such as ...". It would definitely make library's maintenance
way easier.

> Also, in regards to IS_SEQ specifically, the macro is *unsafe*. The
> level of generality that it implies does not exist without variadics
> -- and even then things can be ambiguous. Specifically, in this case,
> it cannot accept arbitrary input:
> BOOST_PP_IS_UNARY( (a, b, c) ) // error

Well, technical feasibility is a different question. What I am opposed
to is rejection of useful and relevant functionality from the library
because of "portability fracturing", especially since IS_SEQ is not the
only primitive that was turned down under that line of reasoning.

As for the above issue, pp-sequences themselves cannot contain that
kind of data, can they? For instance, I am pretty sure this one will
fail as well

    BOOST_PP_SEQ_ELEM(0, (a, b, c)(a))

although, strictly speaking, (a, b, c)(a) _is_ a sequence. Frankly, I
don't think it's an important corner case either. For anyone more or
less familiar with C++ preprocessor it's obvious that the above won't
work, and why.

> This is an important concern in preprocessor metaprogramming because
> it causes tight bindings between various library primitives and
> user-code. Ultimately, IS_UNARY is a low-level detection mechanism
> that is part of a "next-level" preprocessing methodology that is only
> minimally used even in the pp-lib itself and only in *very* controlled
> circumstances. The pp-lib cannot support this "next-level" in any
> general fashion. Even the use of IS_UNARY, et al, is "dicy" on
> Metrowerks and VC++. It will not work in contexts that are not
> strictly controlled, because it directly relies on expansion order
> -- something that is fundamentally flawed on those preprocessors.
> So, in the end, what that means is that it is unsafe to use in
> user-code without the same level of hacks that are used in the pp-lib
> itself. The problems with VC++ and Metrowerks are serious
> encapsulation issues, which is why you're having the REPEAT +
> SEQ_ELEM bug, and if I "publish" macros of this nature, this type of
> problem will occur more and more often.

Hmm, that's kind of news to me. What about the IS_SEQ implementation I
posted? Is it "unstable" as well?

> >> (I assume that you are trying to deal with an "end-of-seq"
> >> indicator.
> >
> > No, I want to distinguish if a parameter passed to a macro is a
> > "plain" data or a sequence of "advanced" arguments.
> Ah, okay. BOOST_PP_IS_UNARY will do it for you, _if_ the input is
> either a unary sequence or operatic.

No, it's either alphabetical date or multi-element sequence.

> Nothing else with work portably. E.g. textual input will fail on
> several compilers.

Mine implementation seems to work fine at least on MSVC and Metrowerks.
We don't care about the rest :).

> Also, before any argument goes into BOOST_PP_IS_UNARY, it must be
> *forced* to expand on VC++ and Metrowerks.
> >> FYI, nil sequences are directly supported in the
> >> "strict" pp-lib if using C99 facilities.)
> >
> > If "strict" PP library makes it in our production environment,
> > it's going to be more or less distant future. The need that
> > generated my request for IS_SEQ is much more real.
> As I said: the facility exists already but has major drawbacks.
> It is not that I'm not trying to be helpful. Rather I think it
> establishes a precendent that I don't want to have to deal with down
> the road.

I can understand the technical reasons for not including the
facilities in the library - if that's where it will end up. I am not
fond of "everything should work on every major compiler" line of
reasoning - especially considering that many users don't care about
some of those "major" vendors.

> The "strict" pp-lib's primary purpose is as a concept library, a
> teaching tool, and an idealistic reference implementation. Whether
> or not people actually use it in a production environment is up to
> them--i.e. if it is worth relying on a secondary build tool.

Well, that's reassuring to hear, because as much as I am excited about
this new work, I would hate to see a drop of support and enhancement
for the "traditional" version of one of the most useful boost libraries
to date.


Boost list run by bdawes at, gregod at, cpdaniel at, john at