March 2004 - Boost - lists.preview.boost.org

Re: GUI library - another one
by Jesse Booher 04 Mar '04

04 Mar '04

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.

3 2

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

04 Mar '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Shannon Stewman > Sent: Thursday, 4 March 2004 2:42 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] GUI library - another one > > On Wed, Mar 03, 2004 at 10:30:47PM -0500, Hurd, Matthew wrote: > > > On Behalf Of Beman Dawes > > > > <snip> > > > > > Even the "why not" version seems overly complex compared to a console > > > iostreams "Hello, world". Why not just: > > > > > > winout << title("Example window") << button("Hello, world!") > > > << wait_for(delete_signal); > > > > > > I'm not necessarily pushing that exact approach, but just pointing out > > > more > > > C++-like alternatives. > > > > I understand you're not pushing that approach. It couldn't quite work > > like that as you're trying to structure a tree rather than a sequence. > > This is beside the point. Trees are isomorphic to lists that contain > lists. For example: > > winout << title("Example window") > << divider(2) << up << ( panel << vertical > << label("Hello, world!") > << textentry("Name: ") ) > << down << ( panel << horizontal > << button("OK") > << button("Cancel") ); > > Which, assuming my parens are right, could give you something > like: > > +---------------------------------------------+ > | Hello, world! | > | Name: ____________________________ | > +---------------------------------------------+ > | /-------\ /--------\ | > | | OK | | Cancel | | > | \-------/ \--------/ | > +---------------------------------------------+ > For sure, to be sure. Not sure I like the approach though. You could off add and << as alternative for the same thing. I see that you could have multiple properties for the same container by having the result as the container too. Some_widget << colour_red << width(pixel(100)) << text_box << font("Arial") << height(millimetres(8)); Not unreasonable and you could format it like Some_window << ( some_widget << colour_red << width(pixel(100)) << some_other_property ) << ( panel << horizontal << ( button("OK") << click_event( dooby_doo::on_click ) ) << button("Cancel") ) ; Not as bad as I thought before I started typing this mail... 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] GUI library - another one
by Hurd, Matthew 04 Mar '04

04 Mar '04

> On Behalf Of Beman Dawes <snip> > Even the "why not" version seems overly complex compared to a console > iostreams "Hello, world". Why not just: > > winout << title("Example window") << button("Hello, world!") > << wait_for(delete_signal); > > I'm not necessarily pushing that exact approach, but just pointing out > more > C++-like alternatives. I understand you're not pushing that approach. It couldn't quite work like that as you're trying to structure a tree rather than a sequence. Your << approach might be nice syntactic sugar for adding an element and event_handlers or listeners and / or modifying a property. 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.

3 2

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