- Boost - lists.boost.org

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

serialization library #17
by Robert Ramey 03 Mar '04

03 Mar '04

Fellow boosters, I have just uploaded serialization17.zip to the boost files section at Yahoo.com. A copy can also be found at www.rrsd.com This is the latest version of my serialization library. It has been built and tested in debug and release mode with VC++ 6.0, VC++ 7.0, VC++ 7.1, GCC 3.2, and GCC 3.3. It requires boost 1.31 to function. It has no known bugs. Compared to previous versions, documentation, examples, tests and portability have all been enhanced. I would like this library to be placed in the review queue. Robert Ramey

4 6

Re: [boost] Re: [Threads] Simple active object wrapper, take 2
by Mark Blewett 03 Mar '04

03 Mar '04

At 01:02 28/02/2004, you wrote: >scott <scottw <at> qbik.com> writes: > > ps: > > the sample code from mark blewett looks very promising? > > > >Yes. Although from my point of view, it has the same drawback with switching >on messages that you have. I wonder if the queue of messages in the servant >class could be a queue of fully-bound function calls, I'm halfway there, in that the queue holds callbacks, eg in Servant::dispatch the "do something with m" simply executes the callback. To give a usage example class MyServant : public Servant { public: MyServant(Scheduler* scheduler) : Servant(scheduler) {} void do_fn(int x, int y) { std::cout << x << " " << y << std::endl; } }; int main() { Scheduler scheduler; scheduler.start(1,1); MyServant my_servant(&scheduler); my_servant.post_call(new CallbackVAA<MyServant,int,int>(&my_servant, &MyServant::do_fn, 1, 2)); scheduler.stop(); return 0; } will result in the output "1 2" via one of the schedulers worker threads >generated by proxy >objects which describe interfaces? (Yes, I am quite enamoured of that >idea :)) Interesting idea... assuming I'm understanding correctly.. in that the callback is created by an object in the servant class, the above becomes; class MyServant : public Servant { public: MyServant(Scheduler* scheduler) : Servant(scheduler), fn(this, &MyServant::do_fn) {} MethodProxy<MyServant, int, int> fn; private: void do_fn(int x, int y) { std::cout << x << " " << y << std::endl; } }; int main() { Scheduler scheduler; scheduler.start(1,1); MyServant my_servant(&scheduler); my_servant.fn(1, 2); // certainly a lot easier to understand than previous example! scheduler.stop(); return 0; } Regards Mark --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.573 / Virus Database: 363 - Release Date: 28/01/2004

3 3

RE: [boost] Container Traits
by Powell, Gary 03 Mar '04

03 Mar '04

This library is an interesting concept but when I looked in it, it didn't have what I would have thought were "container traits" the way I think of "iterator traits". From the VTL library I wanted to be able to query the container to see if it was an associative container, or a sequence container or a random access container, i.e. had an operator[]() etc. Can one of the authors explain the purpose of this library? Yours, -Gary-

4 3