- Boost - lists.boost.org

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

RE: [boost] Re: GUI library - another one
by Powell, Gary 03 Mar '04

03 Mar '04

>>> 9. (really 0 in my view) It should use an extensive resource >>> description schema or language (for widget properties, >>> layouts and relations) that is either interpreted at run time >>> or (though I like it less) compiled into code transparently >>> to the user. This resource description should probably be XML-based. >> >> I agree, and would definitely go with a XUL-like approach for any new GUI >> library, i.e., have the GUI defined completely in an XML file. Maybe even >> handling Microsoft's future XML descriptors for GUIs (XAML?) >Well, I'd hope there would be a user-readable/writable format that >could be used as a front-end. You can go a long way in plain text: > +--------+ > | button | > +--------+ > * radio > * buttons > [ ] checkbox > you get the idea, I hope. >-- >Dave Abrahams While a human readable front end is nice, a machine parsable file is key. I've written I think 3 or 4 of these data format file GUI's and it always starts out as some simple GUI and rapidly becomes an embedded control language. Why because programmers don't want to spend time doing layout and button control! It is just a huge time suck. And every manager has a different opinion. What you want is out of that loop. Let the art director and the manager haggle over what the buttons look like and do. Ideally you create a flexible file format, and XML comes to mind, and then write a GUI tool to let the artists create button art, and tell it how where and how its connected. Then programmers write code which is event based. Then no matter the button is, or how its pressed, the program still runs. Last minute art is no problem. Last minute GUI changes, easy. The button "Quit" still sends a "quit" message. And no recompile, or new binary is necessary. I also despair of a multi platform GUI, it always seemed that each platform had its own look and feel and that users hated anything that reminded them of the other platform. Hence if you can abstract the "message" from the "button" you can have a dropdown menu in one platform and a radio button on another and the program should not care. So if you are selling software, do everything you can to get the "button" logic out of the program and into the art/menu/GUI control system. Layout. Its really nice if you can attach one piece of art to another so that they always line up. But that usually means "pixel" coordinates. Ever look at a game and see that the title is in flames and wonder what's going on? It's like 12 pieces of flame art all designed to run in a cycle. A good GUI can handle that easily. It's enter 12 pieces of art file names, and a sleep time between each in milli seconds and a set of coordinates for each art file that is exactly the same. It's one thing to have layout art such that no matter what size the window is, the art moves to fit, its another to have that same art "burn". Those positions are relative but "exact". A rollover button that highlights as you drag your mouse over it? 2 pieces of art at the same position with another sleep so it doesn't "flash". Depress it and there is a depress "on" followed by a undepressed "on". rollover that and its "highlighted on" art. It looks very 3D but is just wads of art. My recommendation is write a "control from the menu" library. A drawing library, a parse the dang Art file library. Make it send 'text' messages to the control library. Yes this is a bit heavyweight but all the light weight libraries I ever wrote became heavyweight in about 30 seconds due to changed requirements. So start with a resource file that can grow, write a quick text to resource file parser and then an artist GUI to resource file tool. I bet if you look at the game developer sites you'll find some of these already written (But not as well as you'd like.) Yours, -Gary-

1 0

Nightly CVS snapshot
by David Abrahams 03 Mar '04

03 Mar '04

Has anyone else tried to bunzip2 the nightly Boost CVS snapshot recently? My cron job keeps telling me there's a broken pipe; maybe there's something wrong with the archive file? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[named_params] timing trivia and some comments
by Matthew Hurd 03 Mar '04

03 Mar '04

Been looking at the very cute named_params in the sandbox. Getting around to trying to do some stuff with it. Noticed something interesting w.r.t. vc7.1 optimization: BOOST_NAMED_PARAMS_FUN(double, power, 0, 2, power_keywords ) { double b = p[base | 10]; double e = p[exponent | 1]; return pow(b ,e); } double pow_wrap(double b, double e) { return pow(b,e); } are the same speed, around 25 nanoseconds on my machine, when called with some variable parameters ( now = pow_wrap(t.elapsed(),t.elapsed() / (rand() * t.elapsed())); ) to defeat the chance of variable elimination and constant propagation. But interestingly, BOOST_NAMED_PARAMS_FUN(double, power, 0, 2, power_keywords ) { return pow(p[base | 10] , p[exponent | 1]); } is more than five times slower at 144 nanoseconds. Which is the opposite to what I would of expected... Anyway, I found it interesting :-) It seems the take home message for me is that it is possible to use the named_params library with no, zippo, notta bit of abstraction overhead even for a very simple function wrap. I'm deeply impressed. Well done Dave and Daniel. 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> {}; The pre-processor trickery to do this is beyond me I'm afraid. I am interested in being able to iterate over the parameters extracting keyword_types, argument types and argument values. 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? Regards, Matt Hurd. __________________________________________ First case results: ---------------------------------------------------------------------------- ---- looper invasive timing estimate simple_named_params ---------------------------------------------------------------------------- ---- median time = 24.88038277512962 nanoseconds 90% range size = 9.926167350636332e-015 nanoseconds widest range size (max - min) = 10.8665071770335 microseconds minimum time = 24.88038277511962 nanoseconds maximum time = 10.89138755980862 microseconds 50% range = (24.88038277512962 nanoseconds, 24.88038277512962 nanoseconds) 50% range size = 0 nanoseconds ---------------------------------------------------------------------------- ---- looper invasive timing estimate simple_wrap ---------------------------------------------------------------------------- ---- median time = 24.88038277512962 nanoseconds 90% range size = 9.926167350636332e-015 nanoseconds widest range size (max - min) = 10.51913875598087 microseconds minimum time = 24.88038277511962 nanoseconds maximum time = 10.54401913875599 microseconds 50% range = (24.88038277512962 nanoseconds, 24.88038277512962 nanoseconds) 50% range size = 0 nanoseconds Second case: ---------------------------------------------------------------------------- ---- looper invasive timing estimate simple_named_params ---------------------------------------------------------------------------- ---- median time = 144.4976076555124 nanoseconds 90% range size = 0 nanoseconds widest range size (max - min) = 1.#INF seconds minimum time = 144.4976076555077 nanoseconds maximum time = 1.#INF seconds 50% range = (144.4976076555124 nanoseconds, 144.4976076555124 nanoseconds) 50% range size = 0 nanoseconds ---------------------------------------------------------------------------- ---- looper invasive timing estimate simple_wrap ---------------------------------------------------------------------------- ---- median time = 24.88038277512962 nanoseconds 90% range size = 3.308722450212111e-015 nanoseconds widest range size (max - min) = 1.#INF seconds minimum time = 24.88038277512295 nanoseconds maximum time = 1.#INF seconds 50% range = (24.88038277512962 nanoseconds, 24.88038277512962 nanoseconds) 50% range size = 0 nanoseconds

3 3

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

03 Mar '04

Neal D. Becker wrote: >Thanks. Actually, though, what I'm talking about is a different archive >type, not a data structure. Right now binary data is saved/restored using >read/write. mmap is potentially much more efficient for large data >structures. OTOH, there is one big problem for it, which is that mmap can >only be applied to one contiguous memory region. I believe you would have >to serialize one object to one file, and if you want more objects you would >need multiple files to map them to. Still, might be interesting. Hmmm - wouldn't be better to implement a new derivation of std::;basic_streambuf for memory mapped i/o. This would be useful for a lot more than serialization. Of course, all the archive already provided are implemented in terms of streams so they would automatically inherit all the features of memory mapped i/o. The whole topic of custom stream_buf versions or better yet, composable stream_buf adaptors has been under appreciated in my view. I know there was some discussion and work done. I don't know what happened. I suspect it turned out to be "too big" to finish to boost standards in the amount of time that the developer could allocate. I do much appreciate feedback on the serialization library on this list. It is very helpful and encouraging. Note that others have made significant efforts well. These are people that have been experimenting with the library in their own projects. They have been very patient and helpful. Among others I would mention Pavel Vozenilek, Vladimir Prus, David Tonge, and Jeff Finn. Robert Ramey

5 6

bug in string_algo
by John Torjo 03 Mar '04

03 Mar '04

Hi Pavol, Downloaded the latest string_algo from the CVS. It seems to be buggy. First of all, I expect the following to work: std::string result; boost::replace_range( result, "\r\n", "\n"); It fails, with a couple of errors (I'm using VC7.1). Since the above failed, tried to create a function to be equivalent: void replace( std::string & str, const char * find, const char * replace) { boost::replace_range( str, boost::make_range(find, find + strlen(find)), boost::make_range(replace, replace + strlen(replace)) ); } This also fails to compile: d:\boost\boost_latest_sandbox\boost-sandbox\boost\string_algo\iterator_range.hpp(96) : error C2664: 'std::basic_string<_Elem,_Traits,_Ax>::iterator::iterator(std::basic_string<_Elem,_Traits,_Ax>::iterator::pointer)' : cannot convert parameter 1 from 'const char *' to 'std::basic_string<_Elem,_Traits,_Ax>::iterator::pointer' with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] and [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] Conversion loses qualifiers d:\john\projects\logview\log_handler.cpp(6) : see reference to function template instantiation 'boost::iterator_range<IteratorT>::iterator_range<const char*>(const boost::iterator_range<const char *> &)' being compiled with [ IteratorT=boost::string_algo::container_traits<std::string>::iterator ] d:\boost\boost_latest_sandbox\boost-sandbox\boost\string_algo\iterator_range.hpp(96) : error C2664: 'std::basic_string<_Elem,_Traits,_Ax>::iterator::iterator(std::basic_string<_Elem,_Traits,_Ax>::iterator::pointer)' : cannot convert parameter 1 from 'const char *' to 'std::basic_string<_Elem,_Traits,_Ax>::iterator::pointer' with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] and [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] Conversion loses qualifiers This seems pretty unacceptable to me. Best, John

2 1

Indexed Set: design/naming thoughts
by Darren Cook 03 Mar '04

03 Mar '04

Hi, Some thoughts on design/naming after reading docs of indexed_set (version 9). I've not tried compiling anything yet. 1. The naming here seems redundant: employee_set::nth_index_type<1>::type employee_set::index_type<name>::type Can't the "::type" bit be dropped"? Or the _type, e.g. employee_set::nth_index<1>::type employee_set::index<name>::type 2. Do tags have to be structs? struct name{}; ... non_unique<tag<name>,member<employee,std::string,&employee::name> ... employee_set::index_type<name>::type While it looks okay in tutorial examples, I can see not wanting that in the main namespace in a real program. But then having to use a namespace each time I use the tag will be make it a bit ugly: non_unique<tag<tags::name>,member<employee,std::string,&employee::name> ... employee_set::index_type<tags::name>::type If it was a string instead is it less efficient (or maybe it does not compile)? non_unique<tag<"name">,member<employee,std::string,&employee::name> ... employee_set::index_type<"name">::type 3. I think the compose_key example will be needed enough that it should be part of the main library. 4. I think some macros would be useful to enhance readability (rather than just to handle compiler incompatibilities as currently). I'll see what I come up with as I try to use the library. Darren

2 3

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

03 Mar '04

Jeff Garland wrote >Just so you know, the compile blows up with the CVS as of about a day ago. >I'm sure not your fault, but so you know... Well, as you can imagine, I'm happy to know that. At times during this development I used the development tree and other times I used the latest release. Basically I use the latest release rather until I need something that is only in the development tree. This happened with new iterators and mpl. When the release candidated 1.31 came out I switched back to that. My motivation for preferring the latest release is that I would like to upload something that I can expect to work and other people can test with a minimum amount of hassle. I'm mean I have enough problems with my own flakey ( er.. experimental) code with out adding in everyone else's. So as things stand now I'm inclined to work to the 1.31.0 . Having said that, it seems to me the development tree is considered "experimental" where as I would prefer that it be considered "Candidate for Release" That is, I think code is uploaded without out being fully tested in one's local environment. I think this creates a chain reaction at release time. Its not that I think anyone is really wrong, just that I think things would be better if developer's were a little more conservative. (But then, I'm getting old, I think that about everybody) In this case presumable something in new iterators has changed and caught me with my pants down (for the second time !). Oh well. I'll worry about it if we ever get to incorporating the library in a release. Robert Ramey

3 2