Proposal: configurable tuple arity limit
I may have posted something to this effect in Apr. 2003 but got no response if I have; just thought I might have better luck the second time as there were no changes to the tuple library since then. Proposal: current boost/tuple library has a hardcoded limit on the tuple arity (10 elements). Some applications may require substantially larger tuples even at a cost of extended compilation time. Using boost/preprocessor library, it is relatively easy to rewrite the tuple code in such a way that arity limit will depend on a single configuration macro without incuring any other changes to the library. No additional cost will be imposed on the users who are satisifed with the current tuple library. I have a working implementation of such configurable tuples that I've been using since Apr. 2003. As I had no need to support C++ compilers that do not implement partial specification, I have only converted boost/tuple/detail/tuple_basic.hpp so far. Arity limit is controlled by the BOOST_TUPLE_MAX_ARITY macro which is defaulted to 10 inside tuple_basic.hpp if it is not defined prior to its inclusion. Since I am not sure what procedure should I follow to submit such a modification to an existing Boost library, I decided just to post the proposal here and provide a link to the modifed file: http://fridge.yymap.com/files/tuple_basic.hpp Regards, ...Max...
tuples even at a cost of extended compilation time. Using boost/preprocessor library, it is relatively easy to rewrite the tuple code in such a way
"Max Motovilov" <max@yymap.com> wrote that
arity limit will depend on a single configuration macro without incuring any other changes to the library. No additional cost will be imposed on the users who are satisifed with the current tuple library.
There may be problems with Boost.Preprocessor: 1. different compiler have different max limits on code outputted from expanded macro. E.g. BCB has quite low limit (somewhere 1-2kB of text). When this limit is reached, BCB starts to behave unpredictably. 2. compilers based on EDG frontend take exponential time to process some Boost.PP statements. This is problem e.g. of Intel C++ compiler. One way to avoid the problems above is to use local or file iteration technique, available in Boost.PP. It would be good to test impact of your change on as many compilers as possible. /Pavel
"Max Motovilov" <max@yymap.com> writes:
I may have posted something to this effect in Apr. 2003 but got no response if I have; just thought I might have better luck the second time as there were no changes to the tuple library since then.
Proposal: current boost/tuple library has a hardcoded limit on the tuple arity (10 elements). Some applications may require substantially larger tuples even at a cost of extended compilation time. Using boost/preprocessor library, it is relatively easy to rewrite the tuple code in such a way that arity limit will depend on a single configuration macro without incuring any other changes to the library. No additional cost will be imposed on the users who are satisifed with the current tuple library.
I have a working implementation of such configurable tuples that I've been using since Apr. 2003. As I had no need to support C++ compilers that do not implement partial specification, I have only converted boost/tuple/detail/tuple_basic.hpp so far. Arity limit is controlled by the BOOST_TUPLE_MAX_ARITY macro which is defaulted to 10 inside tuple_basic.hpp if it is not defined prior to its inclusion. Since I am not sure what procedure should I follow to submit such a modification to an existing Boost library, I decided just to post the proposal here and provide a link to the modifed file: http://fridge.yymap.com/files/tuple_basic.hpp
The existing tuple implementation is scheduled to be replaced in Boost 1.32.0 by Joel de Guzman's "Fusion" library. See http://boost-consulting.com/boost/boost/spirit/fusion/ -- Dave Abrahams Boost Consulting www.boost-consulting.com
1) I like the idea 2) I shouldn't do this (read tech emails when my blood sugar is low... my brain tends to wander and I come up with oddball ideas, to wit:) Your solution to the problem is elegant. I've always enjoyed enhancements that required NO behavior changes on those who didn't want the enhancement. Then my brain went off in "that" direction and I considered the implementation of your solution. I was reminded of back the "good old days"(lol, they weren't all that good) and programming in Basic. In very early Basic one could call subroutines, but there wasn't any argument passing mechanism available so we'd do things like: a3 = 100; a4 = 7; gosub 999; Later, I started working with _real_ languages and discovered the joys of arguments to functions: MYSIN = SIN(X) for those of you who have never had the experience, that was FORTRAN (note the 6 leading spaces in the source. At any rate...then my mind wandered over "this way" and I thought..Hmmmmm #define BOOST_TUPLE_MAX_ARITY 25 #include "boost/tuple_basic.hpp" It brought back all those bad old days (some were rather grim) of writing code when we didn't have an argument passing protocol for functions. It seems that we have exactly the same situation now with respect to header files. OK, there it is. Anyone have any thoughts on "passing arguments to header files"? This, of course, isn't a formal proposal to add any such system, but I'd be interested to hear from others on the topic. BTW, here's a _possible_ syntax to deal with the above. #include "boost/tuple_basic.hpp<25>" Capturing the argument(s) inside the header file isn't being addressed here. ok, the Gatorade got my blood sugar back up... so it's back to work instead of all this daydreaming. At Sunday 2004-02-15 19:43, you wrote:
I may have posted something to this effect in Apr. 2003 but got no response if I have; just thought I might have better luck the second time as there were no changes to the tuple library since then.
Proposal: current boost/tuple library has a hardcoded limit on the tuple arity (10 elements). Some applications may require substantially larger tuples even at a cost of extended compilation time. Using boost/preprocessor library, it is relatively easy to rewrite the tuple code in such a way that arity limit will depend on a single configuration macro without incuring any other changes to the library. No additional cost will be imposed on the users who are satisifed with the current tuple library.
I have a working implementation of such configurable tuples that I've been using since Apr. 2003. As I had no need to support C++ compilers that do not implement partial specification, I have only converted boost/tuple/detail/tuple_basic.hpp so far. Arity limit is controlled by the BOOST_TUPLE_MAX_ARITY macro which is defaulted to 10 inside tuple_basic.hpp if it is not defined prior to its inclusion. Since I am not sure what procedure should I follow to submit such a modification to an existing Boost library, I decided just to post the proposal here and provide a link to the modifed file: http://fridge.yymap.com/files/tuple_basic.hpp
Regards, ....Max...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner, Jr. wrote:
1) I like the idea 2) I shouldn't do this (read tech emails when my blood sugar is low... my brain tends to wander and I come up with oddball ideas, to wit:)
Dunno what illness I suffer from, but what about: // Header "boost/mpl/has_" #ifndef HAS_HPP #define HAS_HPP #include <boost/mpl/aux_/has_xxx.hpp> #endif BOOST_MPL_HAS_XXX_TRAIT_DEF // Use: #include <boost/mpl/has_> ( Test ) // Replaces: #include <boost/mpl/aux_/has_xxx.hpp> BOOST_MPL_HAS_XXX_TRAIT_DEF( Test ) OTOH, some quick test shows that my compiler doesn't like it, as the last line of the include file plus the following line are not recognised as a macro call. Don't know if it's legal to do such stuff... If you'd like to change the language for more convenience, I suggest another syntax: #include <boost/mpl/has_>( Test ) The required change could be quite minimal: #include "bla" or #include <blubb> should accept code (or whatever) after the closing " or > and just replace the part before that with the include file's content. OK, time for a coffee and sorry if this was a stupid idea :) Regards, Daniel -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de
participants (5)
-
Daniel Frey -
David Abrahams -
Max Motovilov -
Pavel Vozenilek -
Victor A. Wagner, Jr.