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.
Aleksey