From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2003-04-29 05:49:15
Sorry for the late reply.
Paul Mensonides wrote:
> >> 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.
>
> No, but saying that "this feature is unstable on several
> compilers" would. BOOST_PP_REPEAT + BOOST_PP_SEQ_ELEM is an example
> of just how brittle things can be running under VC++. (One way or
> another, that is something that I _can_ make work properly, so I will
> fix that when I can get to it.) The maintenance problems start to
> come up when library primitives are combined on buggy preprocessors.
> The primary problem is _encapsulation_ and avoiding a *combinatorial*
> nightmare when these "next-level" primitives are used by user code.
> It isn't just a question of whether or not feature X with work on
> preprocessor Y, it is a problem with whether feature X will work
> with feature Y on preprocessor Z.
OK, I understand.
> > 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.
>
> It isn't a corner case. The long term final result of the sequence
> mechanism is direct support for variadic sequences, as well as nil
> sequences. This functionality is already available in C99. With
> variadics, it is easy to manipulate arbitrary sized tuples. However,
> that isn't the common case. The common case is something like this:
>
> (a, b)(a, b)(a, b)
>
> I.e. a binary sequence. Variadics sequences support any size with
> only one mechanism. Likewise, I could have designed the sequence
> mechanism to support nil sequences directly, and consequently make
> using sequences more difficult, but I chose not to because that is
> not what it will be eventually. Besides, what you're doing is
> overloading a macro based on the "type" of its operand. This reminds
> me of the conversation we had a while back regarding generic
> algorithms for different pp-data types. The different types are
> syntactically too similar to be differentiated in this way--even with
> variadics. Compiler problems aside, the name BOOST_PP_IS_SEQ implies
> a sort of "type" detection, which I cannot do in general. With the
> IS_UNARY detection process, what your doing is very low-level. It is
> not a high-level facility that would qualify for a name like
> BOOST_PP_IS_SEQ. Which is why I prefer the more low-level name
> BOOST_PP_IS_UNARY. If you *really* think I should, I'll promote those
> detection macros to interface macros, and see how stable I can make
> the COMPARE mechanism, because I respect your opinion. However:
> These facilities are *use-at-your-own-risk*.
I still think that from the user's point of view, the semantics/
limitations of BOOST_PP_IS_SEQ aren't any worse than any other SEQ
primitive, and that users that need this functionality would be happy
to find it under an intuitive name. But I can relate myself to your
position, so not doing it would be fine with me.
Thanks for the discussion,
Aleksey