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"