RE: Passing functors into query

That's very nice, I really like it.  I've been running my version of
this for some time and it's extremely useful.  I had been planning to
offer up a patch of some kind but not got round to it, you know how it
is :)

I use for_each most often when I need to calculate an aggregate but
still need the individual records, for example, displaying a list of
items in stock with their value and quantity available, and then a total
value and number of units.  It really makes code much clearer and
encourages better separation of responsibilities i.e. you're not
calculating stuff during display code.

I notice there's no for_each method which takes just the functor.  Have
I missed something?  Anyway, we use this method all over our projects so
I've amended it to match the better style (!) and attached a doxygenated
version for your consideration.  While I was at it I created an
equivalent for store_if and that's in the patch too.

Thanks,

Joel

-----Original Message-----
From: Warren Young [mailto:mysqlpp@xxxxxxxxxxx] 
Sent: 19 June 2007 05:44
To: MySQL++ Mailing List
Cc: Joel Fielder
Subject: Re: Passing functors into query


Joel Fielder wrote:
> 
> I thought it would be cool to be able to do this instead:
> 
> query << "select whatever";
> query.for_each(DoSomething());

I've added this, though I all but rewrote it for style reasons.  (Yes, 
I'm aware that you copied the style from Query::storein_sequence(), but 
I didn't write that. :) )

> This functionality could be added to the library (without breaking
> ABI???) by adding the following into Query (plus appropriate versions 
> mirroring the storein functions):

I also added Query::store_if(), plus an example program to demonstrate
it.

The example collects rows from the sample table with prime values in the

"num" column.  I'm open to ideas for a better example than primality 
testing.  What I'm really after here is something as simple as possible,

so as not to clutter the example, yet not so simple that you could write

it as a WHERE clause, thus defeating the purpose.

One could argue that there should be two versions of store_if(), one for

sequences and one for set type containers, but I can't really see the 
need.  It won't take a very strong example to get me to change my mind, 
though, since it'd be a function naming problem down the road if we do 
need a version for associative containers.

I also wonder if we need support for template queries?


-- 
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:    
http://lists.mysql.com/plusplus?unsub=gcdmc-plusplus@xxxxxxxxxxx