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,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk