April 2006 - Boost-users - lists.preview.boost.org

Spirit: Assigning elements of a closure member.
by Mark Williams 06 Apr '06

06 Apr '06

Is there any standard way, in a semantic action, to assign individual elements of a struct that is set as a member of a closure? For example suppose I have:- struct foo { int a, b, c; std::string d; float e; }; And I have this as member1 in my closure, which is then attached to a rule that parses each of those struct member elements seperately, is there then a standard way within the semantic actions in my rule to assign to foo.d, say, without modifying the other values? It seems that my only option is to either write my own functors to set each member seperately, or have the individual elements as seperate members of my closure. I kind of want to do something like this: myrule = int_p[assign_a(myrule.m1.a)] >> int_p[assign_a(myrule.m1.b)]; But myrule.m1 is an actor, not an instance of foo. Is there a way to do this with boost::bind perhaps? I want to use closures since my rules need to be reentrant. Mark

1 1

Assertions doesn't work!
by Kiuhnm 05 Apr '06

05 Apr '06

I'm using MSVC8 (2005) with Boost 1.33.1. The code at the end of this post should cause the compiler to print out something like this (GCC): conversion from 'mpl_::failed ****************(factorial<mpl_::int_<-5> >::FACTORIAL_of_NEGATIVE_NUMBER::****************) (mpl_::int_<-5>)' to non-scalar type 'mpl_::assert<false>' requested. but I obtain something completely different. It seems that the compiler continues to evaluate the factorial (-1, -2, -3, ...) ignoring the assertions. Since the template expansion is quite "complex", the compiler fails and prints out: --- fatal error C1202: recursive type or function dependency context too complex c:\boost\include\boost-1_33_1\boost\mpl\aux_\preprocessed\plain\times.hpp(60) : see reference to class template instantiation 'factorial<N>' being compiled with [ N=boost::mpl::int_<-88> ] --- What's wrong? --- #include <boost/mpl/assert.hpp> #include <boost/mpl/greater_equal.hpp> #include <boost/mpl/equal_to.hpp> #include <boost/mpl/multiplies.hpp> #include <boost/mpl/prior.hpp> #include <boost/static_assert.hpp> namespace mpl = boost::mpl; // specializations are nullary metafunctions that compute n>0 template <int n> struct FACTORIAL_of_NEGATIVE_NUMBER : mpl::greater_equal<mpl::int_<n>, mpl::int_<0> > {}; template <class N> struct factorial : mpl::eval_if< mpl::equal_to<N,mpl::int_<0> > , mpl::int_<1> , mpl::multiplies< N , factorial<typename mpl::prior<N>::type> > > { BOOST_MPL_ASSERT((FACTORIAL_of_NEGATIVE_NUMBER<N::value>)); BOOST_STATIC_ASSERT((0)); // !!! BOOST_MPL_ASSERT_MSG(N::value >= 0, FACTORIAL_of_NEGATIVE_NUMBER, (N)); // !!! }; int main() { int f = factorial< mpl::int_<-5> >::type::value; } --- Thank you, Kiuhnm -- View this message in context: http://www.nabble.com/Assertions-doesn%27t-work%21-t1401263.html#a3770376 Sent from the Boost - Users forum at Nabble.com.

2 1

Re: [Boost-users] Boost-users Digest, Vol 866, Issue 4
by Stephen Gross 05 Apr '06

05 Apr '06

Message: 10 Date: Wed, 5 Apr 2006 10:52:07 -0700 From: "Sohail Somani" <s.somani(a)fincad.com> Subject: Re: [Boost-users] Equation idea (follow-up) To: <boost-users(a)lists.boost.org> Message-ID: <1C1EBEF8DBACDC439D038EA051674EC728BE13(a)xbox.financialcad.com> Content-Type: text/plain; charset="us-ascii" >Because people want to use different types. For example, some systems may support higher precision for long double. I think you have a good point on this one... The trick is to find a way to do it that keeps the client syntax as simple. >I think most boost users are pretty much power-users (for better or worse). Sure, so I guess the question is more like this: If we accept the premise that the intended users of the toolkit aren't power users, then does it make sense for boost to include? I think you have a valid point that maybe it's not appropriate for boost. But at the same time, I figured that since it's built so directly off of boost, it might be helpful. Then again, maybe the best place for the equation toolkit is in a different toolkit bundle...? --Steve

2 1

Re: [Boost-users] equation (really expression) idea (follow-up)
by Stephen Gross 05 Apr '06

05 Apr '06

>1. Types are not template-ized. I don't want everything to be a double. This is an interesting point. My goal so far has been to prioritize simplicity above all. The purpose of the toolkit is for letting people write arithmetic equations easily. In light of that, I think sticking with doubles makes sense. 2. Perhaps variables should be first-class objects, not just placeholders in BLL. Maybe... The whole idea, though, is basically to macro-ify some boost::lambda::bind operations so that you let lambda do the heavy lifting of actually combining all the functors together. 3. (Style not substance) Many of the type and function names aren't very clear. Examples: go() and MapType; Sure; style can always be worked on. Right now, it's not very well-documented anyway so some of the implementation may not be intuitive. >I'm thinking the client syntax should be something more like this: expression expr; variable<double> x; variable<int> y; expr = x + y; double v = expr; // would throw because x and y are unassigned x = 10; y = 20; v = expr; // assigns 30 to v Well, this is an interesting idea but it runs contrary to the metaphor I want. In the above example, the variables 'x' and 'y' work as global variables. I want the user to have to pass x and y directly to the equation. There's another reason for this: If one equation uses another equation, you have to make sure the equations use the right variables. Consider this: Equation f1 = x + y Equation f2 = z + f1(x -> z, y -> z) print f2(9) If you had global-level variables, then it would be difficult to make the above example work properly (passing z on as x and y when f2 invokes f1).. --Steve

2 1

Re: [Boost-users] I NEED HEMP PLEASEeeeeeeeeeeeeee
by Sohail Somani 05 Apr '06

05 Apr '06

I don't think this is the right list to discuss these things. (Sorry, I had to)

1 0

Re: [Boost-users] Boost-users Digest, Vol 866, Issue 4
by Sohail Somani 05 Apr '06

05 Apr '06

> >I think most boost users are pretty much power-users (for better or > worse). > > Sure, so I guess the question is more like this: If we accept > the premise > that the intended users of the toolkit aren't power users, > then does it make > sense for boost to include? I think you have a valid point > that maybe it's > not appropriate for boost. But at the same time, I figured > that since it's > built so directly off of boost, it might be helpful. Then > again, maybe the > best place for the equation toolkit is in a different toolkit > bundle...? Im sure you'd get a really great response on a numerical analysis type forum (I think there is a newsgroup sci.math.num-analysis or something) Sohail

1 0

Re: [Boost-users] Equation idea (follow-up)
by Sohail Somani 05 Apr '06

05 Apr '06

> >> class Equation > >Should be templated > > Why? Because people want to use different types. For example, some systems may support higher precision for long double. > The idea is that the target users for this toolkit aren't > power-users. Quite > the contrary: I work with a lot of scientists, and they have > rudimentary > C/C++ skills. This system would let them write equations > without having to > learn template syntax or, for that matter, much about > function declarations. I think most boost users are pretty much power-users (for better or worse). If your stuff is compatible with boost/tr1 function (and it seems that it is, just might be missing some tyepdefs), then that's a step in the right direction. Sohail

1 0

Re: [Boost-users] Equation idea (follow-up)
by Stephen Gross 05 Apr '06

05 Apr '06

>> std::cout << a(_y is 5, _z is 10) << std::endl; >I do think the idea of assigning inputs at the call site is important which is what you've done. It would be nice to use the named parameter library here if possible to get rid of the leading underscores. I've played around a little with the parameter library, but it requires you to pre-register variable names (I think???). With this system, you can either use the underscore-letter name, or just wrap the name in the VAR() macro (eg: Equation e = VAR(foo) + VAR(bar); cout << e(VAR(foo) is 9, VAR(bar) is 10). ) >> class Equation >Should be templated Why? >I don't know what this offers over boost bind and function. I use these to do a lot of this type of stuff. As long as the number of parameters are low, its easy to understand and you get some currying for free. The idea is that the target users for this toolkit aren't power-users. Quite the contrary: I work with a lot of scientists, and they have rudimentary C/C++ skills. This system would let them write equations without having to learn template syntax or, for that matter, much about function declarations. >// I'd really like to do >double v = f(x=x,y=y); I think the system I've proposed will do what you're asking: Equation f = _x + _y; double v = f(_x is 5, _y is 8) --Steve

1 0

Re: [Boost-users] Equation idea (follow-up)
by Sohail Somani 05 Apr '06

05 Apr '06

Comments below > std::cout << a(_y is 5, _z is 10) << std::endl; I do think the idea of assigning inputs at the call site is important which is what you've done. It would be nice to use the named parameter library here if possible to get rid of the leading underscores. > class ArgTable I think this is not needed if you can use the named parameter library. > class Equation Should be templated I don't know what this offers over boost bind and function. I use these to do a lot of this type of stuff. As long as the number of parameters are low, its easy to understand and you get some currying for free. SomeFn f = bind(my_fn(),_1,_2); // its not too difficult to understand this as x,y // I'd really like to do double v = f(x=x,y=y); Sohail

1 0

Re: [Boost-users] Equation idea (follow-up)
by Stephen Gross 05 Apr '06

05 Apr '06

>Why don't just use Blitz++ for various expressions/equations? ;) I didn't know about blitz++, but I've just now taken a quick look at it. It appears designed for performance above all, which is not the idea behind my equation toolkit. The equation toolkit is designed to let you *easily* write straight-forward equations, combine them, and re-assign them as you want. For instance: ================= Equation e = x + y print e(x -> 1, y -> 2) e = y print e(y -> 9) e = z + 2 * y / a + b print e(a -> 2, b -> 5, y -> 100, z -> 50) ================= The advantage is that you can easily change an equation so you don't actually have to write functions for each equation. If you have a situation where you need to dynamically change around equations a lot during runtime, this system should (ideally) be useful. --Steve

1 0