From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2004-02-19 17:08:47
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;
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
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.
Capturing the argument(s) inside the header file isn't being
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
>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
>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"
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk