on Fri Oct 05 2012, Paul Mensonides <pmenso57-AT-comcast.net> wrote:
On Thu, 04 Oct 2012 21:31:48 -0400, Dave Abrahams wrote:
on Wed Sep 26 2012, Paul Mensonides <pmenso57-AT-comcast.net> wrote:
Right, and what will change that sad fact? Attempting to workaround forever isn't working. Similarly, is the whole world supposed to not use variadic templates because VC++ doesn't implement them? At least that's likely to change, but a line needs to be drawn. It is one thing for a workaround to be an implementation detail. It is another when it affects the interface. In the latter case, IMO, the best thing to do is provide the interface that *should* exist and either not support the compilers that don't work or provide some clunkier interface for those compilers. Doing else cripples technological advancement.
I'll mention again that I think we should accept some libraries that won't work on broken compilers (like Chaos). "Boost works on this compiler" is an important selling point.
1) How is the modularization/git transition going?
I think https://groups.google.com/forum/?fromgroups=#!topic/ryppl-dev/12z1ahWsNtk contains the best answers to that question so far. Short answer: quite well; we just need to keep moving it forward.
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).
I don't have a strong position on this one, but will point out that there are other options such as BOOST_CHAOS_ or BOOST_CPP_
A quick example:
#include <chaos/preprocessor/arithmetic/dec.h> #include <chaos/preprocessor/control/if.h> #include <chaos/preprocessor/facilities/empty.h> #include <chaos/preprocessor/punctuation/comma.h> #include <chaos/preprocessor/recursion/basic.h> #include <chaos/preprocessor/recursion/expr.h> #include <chaos/preprocessor/tuple/eat.h>
// interface:
#define DELINEATE(c, sep, m, ...) \ DELINEATE_S(CHAOS_PP_STATE(), c, sep, m, __VA_ARGS__) \ /**/ #define DELINEATE_S(s, c, sep, m, ...) \ DELINEATE_I(s, c, CHAOS_PP_EMPTY, sep, m, __VA_ARGS__) \ /**/
// implementation:
#define DELINEATE_I(s, c, s1, s2, m, ...) \ CHAOS_PP_IF(c)( \ DELINEATE_II, CHAOS_PP_EAT \ )(CHAOS_PP_OBSTRUCT(), CHAOS_PP_NEXT(s), \ CHAOS_PP_DEC(c), s1, s2, m, __VA_ARGS__) \ /**/ #define DELINEATE_INDIRECT() DELINEATE_I #define DELINEATE_II(_, s, c, s1, s2, m, ...) \ CHAOS_PP_EXPR_S _(s)(DELINEATE_INDIRECT _()( \ s, c, s2, s2, m, __VA_ARGS__ \ )) \ m _(s, c, __VA_ARGS__) s1() \ /**/
// reusable:
#define REPEAT(c, m, ...) DELINEATE(c, CHAOS_PP_EMPTY, m, __VA_ARGS__) #define REPEAT_S(s, c, m, ...) \ DELINEATE_S(s, c, CHAOS_PP_EMPTY, m, __VA_ARGS__) \ /**/
What's the point of showing REPEAT here? It doesn't seem to be used below. Are you just illustrating that you can build REPEAT and ENUM using the same foundation?
#define ENUM(c, m, ...) DELINEATE(c, CHAOS_PP_COMMA, m, __VA_ARGS__) #define ENUM_S(s, c, m, ...) \ DELINEATE_S(s, c, CHAOS_PP_COMMA, m, __VA_ARGS__) \ /**/
// recursive:
#define TTP(s, n, id) \ template<CHAOS_PP_EXPR(ENUM( \ CHAOS_PP_INC(n), class CHAOS_PP_EAT, ~ \
Did CHAOS_PP_INC come in with CHAOS_PP_DEC? I don't see an #include for it.
))> class id ## n \ /**/
CHAOS_PP_EXPR(ENUM(3, TTP, T))
-> template<class> class T0 , template<class, class> class T1 , template<class, class, class> class T2
Complicated?...yes. But compare that to the implementation of BOOST_PP_REPEAT. Unlike BOOST_PP_REPEAT, however, this macro can be recursively reentered about 500 times. The actual implementations of these in Chaos is far fancier.
I went to look at the code and found the mercurial repo doesn't appear to contain most of chaos, which was a little confusing. Just thought it would be worth telling people to look at the CVS. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost