- Boost - lists.boost.org

RE: [boost] Re: First lambda
by Powell, Gary 04 Mar '04

04 Mar '04

>> // PROPOSED CHANGE IN SOME FUTURE PAPER >> >> unsigned long n = std::accumulate( >> xs.begin(), xs.end(), 0UL, >> long (long lhs, X const &rhs) // inline fn with no name. >> { >> return lhs + rhs.count; >> } >> ); >Yeah, but do you propose to make local names visible inside the anonymous >function, or not? If you do, you open a big can of worms for implementations >(recursive nested functions, need I say more?), if you don't, BLL can still >do things that anonymous functions can not. Anonymous functors could help >some, but their syntax won't be quite as compact as your example above. >...Max... In my plan, variables would have same scope in a function as they do now. i.e. variables local to std::accumulate are not visible in the anonymous fn. And yes its not a panacea. For instance, what about static variables in an anonymous function. Do they have the lifetime of the program, or does the anonymous function have a "lifetime" of the calling function? e.g. unsigned long foo (vector<X> const &xs) unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, unsigned long (unsigned long lhs, X const &rhs) // inline fn with no name. { static unsigned long y = 0; return ++y * (lhs + rhs.count); } ); return n; } int main() { vector<X> xs; // ... initialize xs unsigned long a = foo(xs); unsigned long b = foo(xs); a == b; // depends on the lifetime of foo::anonymous::y return 0; } In this case perhaps a functor created with a mix of BLL and an anonymous functions would be clear. Yours, -Gary-

4 3

RE: [boost] Re: [named_params] timing trivia and some comments
by Hurd, Matthew 04 Mar '04

04 Mar '04

> On Behalf Of David Abrahams > Subject: [boost] Re: [named_params] timing trivia and some comments > > > "Matthew Hurd" <matt(a)finray.net> writes: > > > Been looking at the very cute named_params in the sandbox. Getting > > around to trying to do some stuff with it. <snip> > > I'm deeply impressed. Well done Dave and Daniel. > > You can thank the good people at Microsoft for that. I don't think > we put any special attention on avoiding abstraction penalty other > than doing the obvious things (e.g. pass classes by reference). Design helps and the magic of C++ optimisation ;-) > > It would be nice if the macro could some how encapsulate the keyword > > definition so this might be eliminated. > > struct base_t; > > struct exponent_t; > > > > namespace > > { > > boost::keyword<base_t> base; > > boost::keyword<exponent_t> exponent; > > } > > > > struct power_keywords : boost::keywords< base_t, exponent_t> {}; > > Good point... but we anticipate the keywords for a given library will > probably be re-used in several function interfaces, so we can't > rightly do it all with a single macro invocation -- you might need to > write several lines like the last one, for different functions. We > can do something like: > > BOOST_NAMED_PARAMS_KEYWORD_DECL((base)(exponent)) > > to generate the keyword declarations and then something like: > > BOOST_NAMED_PARAMS_KEYWORD_SET(power, (base)(exponent)) > > for each line like the last one. That would work nicely. Though there might be some benefit in not reusing the keywords and putting them into a namespace with the function and I think ADL might help with the keyword name resolution. Hmm, or does it. I'll try it. > > The pre-processor trickery to do this is beyond me I'm afraid. > > It's not hard, if you're willing to spend the time poring through the > PP lib docs. I just worry a little about ending up with a library > interface that hides everything behind macros. I'll give it a crack. Though I too am concerned about ending up with a macro mess and little C++. Would be much nicer if there was a generative C++ approach that was suitable. > > I am interested in being able to iterate over the parameters extracting > > keyword_types, argument types and argument values. > > Since the parameters can have heterogeneous types, there's no way to > iterate over them. It would, however, be possible to "recurse" over > the items with something that looks like: > > for_each(params, some_templated_function_object) > > > Convenient string names would be good too but I can always uses > > typeid on the keyword_types. > > > > Why would I want to do this? I would like to use this approach as a way > for > > inserting an intermediary function. Specifically, I would like to call > > f<direct>(x,y) and have the direct representation called or f<marshal, > > destination>(x,y) and have an intermediary serialize the params into a > block > > and send it off on a transport where a representation along the lines of > > f<marshal, source>(x,y) would accept the block in some infrastructure > > somewhere else. f<queue_for_processing_in_a_thread_pool>(x,y) fits this > > model too. > > > > Any thoughts? > > I guess my first thought is: "Whaa??? What does any of the above have > to do with a named parameters library?" Pretty much nothing. I just like the named_params style of interface and wanted to adopt the approach. I want to build a mechanism where it is easy to build an interface to a function / functor than can have a policy that allows it to be a normal function or something else such as a function in worker pool or a remote function. My desire is to make it easy to represent a function and keep this orthogonal to whether it remote, pooled or local via a policy. For some of the mechanisms I actually would like names for the parameters to help fulfil a protocol requirement, thus the desire for introspection on the names and a look into your neat library. > And then I think: "OK, he wants something that mates the serialization > library from Robert Ramey with the new tuples (fusion) from Joel de > Guzman". This was my original thought. To use tuples and Robert's serialization. I haven't looked at the new tuples in fusion. Will do so. The get<0>(mr_tuple) approach is not as nice and it doesn't have a unique name for the param. I'll have a think about this. Which ever approach Robert's serialization will be a key plank. > I can begin to vaguely see a reason to slap a named parameters > interface on top of the whole thing, but it seems like you could do > that as an afterthought. Am I missing something? I must be. One extra note for you. There was a couple of typos in the doc. From memory, the order of the arity and the keywords in the macro are transposed in the documentation. Also the docs still refer to params[name | default] rather than p[name|default]. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

3 2

RE: [boost] Re: [named_params] timing trivia and some comments
by Hurd, Matthew 04 Mar '04

04 Mar '04

> On Behalf Of David Abrahams > Subject: [boost] Re: [named_params] timing trivia and some comments > > >"Hurd, Matthew" <hurdm(a)sig.com> writes: > > >> I guess my first thought is: "Whaa??? What does any of the above have > >> to do with a named parameters library?" > > > > Pretty much nothing. I just like the named_params style of interface > > and wanted to adopt the approach. > > > > I want to build a mechanism where it is easy to build an interface to a > > function / functor than can have a policy that allows it to be a normal > > function or something else such as a function in worker pool or a remote > > function. > > > > My desire is to make it easy to represent a function and keep this > > orthogonal to whether it remote, pooled or local via a policy. > > You're describing boost::function<...> now. Nearly, yep. I just want the cool named and default parameters with support for iteration / recursion over the parameters with a bit of introspection. > > For some of the mechanisms I actually would like names for the > > parameters to help fulfil a protocol requirement, thus the desire for > > introspection on the names and a look into your neat library. > > So put a named-param front end on a boost::function (?) OK, I'll take your advice and have a look at doing this. I'll also have a think about if I can find a way to generate the alternative functions using a class generation approach instead of macros later too. Thanks Dave, Regards, Matt Hurd IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

RE: [boost] Re: GUI library - another one
by Hurd, Matthew 04 Mar '04

04 Mar '04

> On Behalf Of Jesse Booher > Sent: Thursday, 4 March 2004 8:05 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: GUI library - another one > > It is never a bad thing when someone is interested in donating their time > to develop software to share with the world, and if there is a community > of developers here with the time and motivation to develop a full featured > GUI library that rises to the high standards of Boost that would be a > wonderful thing. That said a GUI library is a *HUGE* undertaking and > other cross platform libraries like wxWidgets have a big head start. Not > that this is a race or anything but when it comes to GUI libraries, > features nearly always trump form. After all an awkward interface is a > developer annoyance, whereas a missing feature can be a show stopper. > > There is a certain allure to clean slate designs and there may very well > be no existing open source user interface projects that you would consider > worthy of your time, but I wondered if you have considered any slightly > less ambitious alternatives such as creating a framework employing > components from an existing open source project? It seems to me that the > promise of open source development is not served when wheels (or widgets) > need to be reinvented over and over again. I'd agree with this sentiment. The world is littered with limited cross platform gui libraries. I'd take a decent free one, such as wxWidgets (nee wxWindows), and look at wrapping its elements and leverage that experience. Add new controls/widget later. If it doesn't make boost maybe it could make wxWidgets... Building a RAD tool than generates C++ and resource files including itself in a self hosting way would be an excellent driver. I've never met a gui lib I've liked and I've met quite a few in the street. Ugly critters, they all need a big bath in some sheep drench. Lack of good GUI is a thorn in C++'s side. GUI in C++ is just too hard. Too messy. I want something RADically different. Some new, not just neat C++. The strength of a new approach in C++ could help improve the C++ community. Firstly, I'd like to see it driven by both a user requirement of building the gui and the developer requirement of elegant portable c++. I'd like to see a few things I'd like that are probably a little different to current approaches: 1. The ability to drap and drop complete panels in the builder where they are can be aware of their context and automagically hook up to their context if possible. This means "inheriting" a context where a property can hook up to a provider automagically if there is one that makes sense. E.g. you have a property stock_code, which goes up the structural context of the gui until it finds a match, or it is mapped. This way you can drag and drop components with a minimum of fuss. It is a bit like how events propagate on current windowing systems. This reminds me a little of spirits closure syntax. 1a. An extension to this is addressing properties where the scope of the property is found in the structural hierarchy automagically. Allowing automatic proprogation up and down the hierarchy would be neat. For example, I change my background colour and my parents do too until a parent is reached that doesn't with to. That kind of thing. Also being able to expose data / containers in a similar form so I can just get the stock_code that is relevant to my context by looking up my structural heirarchy... That kind of thing. 1c. Being able to address components and data by structure at run time where that structure may be constructed at run time in a similar way. 2. A natural MVC mechanism where changes flow by default but can have quality of service parameterisation added, like: stop it; all changes, but bundle them up; if there is a queue of changes cause I'm slow, just give me the latest, etc. That kind of thing. QoS is not so important to me but having the design there to support this is. A lot of systems I deal with need this feature as I often have torrents of data. Events would flow down the structural hierarchy similar to point 1. This flow is how gui toolkits already typically work for events. 3. A good sizing mechanism. Either swing or wxWidget sizer like (which often doesn't work out well for small devices) or something that is specifically laid out with pixel accuracy, perhaps with minimum size, with simple ratios of stretchiness. Julian Smart's DialogBlocks is going down this track with wxWidgets. 4. An annoyance of current approaches is that some things are fixed at widget creation time and some things are adaptable properties at run time. I'd like to see them all as run time properties. This could be approached wrapping current kits by buffering the display, deleting and re-creating the widget. Temporary messy implementation for a nice orthogonal concept. 5. Support Metalayout, with windows draggable to tool bars, tabs. Docking at the window edges and the like. wxWidgets frame layout toolkit does this for you. 99. It would be neat to have an abstraction layer where the gui detail was separated from the functional layer via a pipe which could be local or remote to support a fat, thin or chunky client approach. Eventually and approach where the code might migrate from server to client, and vice versa, to support execution where ever it is optimal... I call this the smart client approach :-) These have not much to do with c++, but such an approach in c++ could help c++. If I were to tackle this, I would take wxWindows as my implementation level so I get linux, win32 and mac with native controls and start building a gui composition thing that could generate the c++ and resource files I needed. Concurrently developing the c++ framework. A goal would be to self hosting where you can generate yourself. All the other neat c++ mentioned in this thread still holds true, but I think there needs to be more than just yet another gui toolkit for c++ and the focus needs to be on making a) a nice framework and b) something a little more innovative or added value than just yet another signal / slot or event routing thing. A neat way of simply composing the stuff by taking form of structural context and with a form of structural addressing (I just made that term up) might be the basis of such an innovative approach. A way I like to think of it is a workflow / graph / state machine that is hierarchically composed where each node can address it children and parents and some of the nodes / objects have i/o side affects which might include gui drawing stuff. Does this make sense or is it more of my typically worthless ramble? Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

Re: [boost] FC++ examples?
by Dave Gomboc 03 Mar '04

03 Mar '04

> In any case, I failed to extol other (non-obvious) virtues of > the quicksort example. A lazy quicksort can be used... The skeptic will in turn point to the C++ standard library routines: http://www.sgi.com/tech/stl/partial_sort.html http://www.sgi.com/tech/stl/nth_element.html > Again, the overall point is that some of the "slower" > elements of FC++ can offer you trade-offs: choices you > wouldn't otherwise have. Lists and lazy evaluation may not > always be the best choice for performance- critical portions > of applications, but for other cases they can often yield > novel and/or simpler designs. I think it's too much to ask Brian to defend functional programming as a whole. Some people will use fc++, and some won't -- I don't see how this differs from regex, spirit, etc. Ten years ago if you spoke of generic programming you might get a funny look from people, and "what do I need that for?". That's the reaction I'm sensing about functional programming by some reviewers. I hope that the review manager ignores that reaction, and makes their decision based upon the library itself. Dave

1 0

RE: [boost] Re: First lambda
by Powell, Gary 03 Mar '04

03 Mar '04

>> It sure would've been nice to be able to write _2.count, or count(_2), or >> _2.count(), but we can't, so we bind(). ;-) The regular syntax has its >> advantages, and the initial "member pointer first" surprise is a one-time >> adjustment. >It's an issue of how far the language is, mentally, from the domain >abstraction it represents. > _2.member(&X::count) >maps more directly to > _2.count >than > bind(&X::count,_2) >does. For me. >Dave Abrahams Ahhhh, Now I understand what you want. That's no problem at all. I thought you wanted to be able to do this, vector<X *> xs unsigned long n = accumulate(xs.begin(), xs,end(), 0UL, _1 + _2->count ); where the operator->() of the class LamdaPlaceHolder<2>, returns a lambda object that has a member pointer to "count". Hence my confusion about your earlier email. Yours, -Gary-

1 0

RE: [boost] Re: [named_params] timing trivia and some comments
by Hurd, Matthew 03 Mar '04

03 Mar '04

> On Behalf Of Peter Dimov > Subject: Re: [boost] Re: [named_params] timing trivia and some comments > > > David Abrahams wrote: > >> "Matthew Hurd" <matt(a)finray.net> writes: > >> > >> Why would I want to do this? I would like to use this approach as a > >> way for inserting an intermediary function. Specifically, I would > >> like to call f<direct>(x,y) and have the direct representation > >> called or f<marshal, destination>(x,y) and have an intermediary > >> serialize the params into a block and send it off on a transport > >> where a representation along the lines of f<marshal, source>(x,y) > >> would accept the block in some infrastructure somewhere else. > >> f<queue_for_processing_in_a_thread_pool>(x,y) fits this model too. > >> > >> Any thoughts? > > > > I guess my first thought is: "Whaa??? What does any of the above have > > to do with a named parameters library?" > > > > And then I think: "OK, he wants something that mates the serialization > > library from Robert Ramey with the new tuples (fusion) from Joel de > > Guzman". > > Conceptually, I think that he wants to serialize a boost::function<>. My > advice is "don't bother". I use shared_ptr<Command> for serializeable > polymorphic functions. Not too concerned about this as a simple id association gives me what I need for IPC. I just prefix the associated id to the message. Lots of options for this, just need to pick one. For a local call I'm hoping the mechanism will make the function call implicit and then there will not be a need for a function<> or shared_ptr <> indirection. Thanks for your thoughts. Appreciated. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

FC++ examples?
by Giovanni Bajo 03 Mar '04

03 Mar '04

Hello, I wasn't able to review FC++ due to lack of time. Nonetheless, I have been following the reviews to gather what I can about this library. What am I basically missing is the most obvious question: what is this library for? Boost libraries mostly solve real-life problems of C++ coders. FC++ tries to add FP programming capabilities to C++, but I can't see how this is going to help, within a normal C++ program. The quicksort example was very cool, but it turns out that the generated code is too slow to be used for everything. If I need FP everywhere, I change language. Are there a couple of examples showing real-life C++ problems that can be solved with the help of FC++? -- Giovanni Bajo

2 1

Re:Re: serialization library #17
by Robert Ramey 03 Mar '04

03 Mar '04

Neal Becker wrote: >I have 1 more question. What about an archive that uses mmap? This should >be very efficient for saving/restoring large structures in binary format. >Is this a good idea? I did all the STL collections as I considered these "fundamental". . I did a version of shared_ptr myself as a test/proof of concept. 1 more question? Hmmm so for I have received submissions for serialization of optional, scoped_ptr, date_time library among othersThese are from people who needed to serialize other boost objects that they use. I've stopped incorporating them as the library is getting too big for me to manage. If this library is ever accepted, serialization of boost components will have to be a responsibility separate from the serialization library itself. After, they are really applications of the serialization library rathet than components of the library. So feel free, to make a serializer for any kind of data structure you find useful. All we have to do is to find a place to put it. Robert Ramey

6 9

FC++ -- reminder formal review ends today at midnight PST
by Mat Marcus 03 Mar '04

03 Mar '04

Please remember that the formal review for FC++ ends today at midnight PST. Please post your reviews, comments or questions today. Thanks, Mat ### once again the original notice reproduced below for your convenience The formal review of fcpp by Brian McNamara and Yannis Smaragdakis is now in progress, running from Friday February 13th at 12 noon, PST and and run to Monday, February 23rd, 12 noon PST. The library is currently available at <http://www.cc.gatech.edu/~yannis/fc++/boostpaper/> Here is a brief introduction to the library: FC++ is a library for doing functional programming in C++. The library provides a general framework to support various functional programming aspects, such as higher-order polymorphic functions, currying, lazy evaluation, and lambda. In addition to the framework, FC++ also provides a large library of useful functions and data types. The main utility of the library comes from its ability to implement functional programming designs, especially those which use higher-order polymorphic functions or lazy evaluation in significant ways. The library also contains a number of ancillary components that implement features like currying and lambda for function objects; these features are also useful in their own right. For information about submitting a Formal Review, see <http://www.boost.org/more/formal_review_process.htm> Please try out the library and read the documentation and say whether or not you think the library should be accepted by Boost and why. Compiler notes: This library has been tested with icc7 and with gcc-3.1.1 (and various other gcc-3.x.y versions) on Solaris and Linux. The library is also likely to compile on VC++7.1 and Comeau (prior versions of the library succeeded with these compilers, but this particular snapshot has not been tested with them). The library covers a great deal of the C++ language and thus requires a high degree of standard conformance; compilers like gcc-2.95.x and VC++6 will not be able to compile the library. Getting started: The web page http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ mentions all the basics: The zip file will expand into these subdirectories: fcpp/fcpp/ # the library (.hpp) files fcpp/fcpp_clients/ # the example (.cpp) files Running the examples just involves invoking the complier with the right #include paths; for example, # in the fcpp_clients directory g++ -I/path/to/boost -I../fcpp some_example.cpp There is also a gnu-style Makefile included with the clients (examples), which will compile all of the examples in batch (you will have to edit a tiny bit at the top of the Makefile). The examples in the clients directory are a mix of both (regression-type) tests cases which cover the features of the library and example applications which demonstrate some of the library's utility. The README file in the client directory gives a short explanation of some of the more interesting clients. The documentation at http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ provides a walkthrough and reference for most of the main features of the library. There are also some pointers out to other papers and documentation on the main FC++ web site: http://www.cc.gatech.edu/~yannis/fc++/ Conformance to Boost guidelines: The library meets most of the requirements described at http://www.boost.org/more/lib_guide.htm Here are a few notable exceptions: - the current library headers are too "monolithic"; you #include "prelude.hpp" and suck in all of the library - some of the lambda internals should be rewritten to use MPL rather than hand-rolled metaprogramming code - only a few of the example programs utilize the Boost testing framework (to automate regression testing) Should the library be accepted into Boost, Brian will remedy these deficiencies. (If you notice other major problems along these lines, please bring them to Brian's attention during the review.) The Formal Review manager is Mat Marcus.

6 7