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

GUI Windowing Framework in C++
by Reece Dunn 28 Sep '04

28 Sep '04

A windowing framework should abstract the windowing facilities of a particular platform. Here are my list of requirements for this type of framework: [1] Support constructor-based window creation, e.g.: frame.add( new gui::button( "Boost!" )); The justification for this is that I find using an OnCreate + Create style for creating windows (MFC and WTL) or similar is too complex: the above method for creating a component is 1 line compared to many lines in other frameworks. For the record, I have a basic version of the above implemented in Windows where the add function changes the parent of the child component. This would make it easy to implement advanced GUI like docking controls. [2] Support for lightweight components: components that do not use native window handles. This will allow for advanced facilities like layout managers. The infrastructure should be such that using native and lightweight components is transparent. Component positioning should be allowed to be set explicitly (absolute position - using the units library?) or set using layout managers. There should be wrapping, clipping and stretching position schemes for the various layout managers. [3] The event manager should be platform independent, flexible and extensible. That is to say, if you are using Windows, you should be able to register a handler for a Windows-specific message. In general, the library should match system messages to an independent version wherever possible. It should also support message reflection where a message for a component is handled by a different window or object (e.g. responding to a close message on an application object). When an event is handled, the handler should inform the manager how to process the event: (1) the event has been handled (e.g. focus events); (2) the event was not handled - try the next handler; (3) the event was handled, but processing should continue (e.g. draw events) There has been discussions in earlier threads (Java style GUI in C++) about using boost::signal as an event handler. I have two questions regarding this: (1) if I have n message types, do I need n boost::signal objects? If so, this would increase the size of each component. Also, what if you want a "handle all events" handler. (2) if generic events are defined in an 'event' object, and a handler function has the form: event_handled_type eventfn( const event & e ); what if you want to support: event_handled_type pressed( const mouse_event & me ); event_handled_type key_down( const key_event & ke ); Regards, Reece

6 13

Re: [boost] [uBLAS] Linux regressions
by Michael Stevens 28 Sep '04

28 Sep '04

On Monday 27 September 2004 15:25, Martin Wille wrote: > Possibly stale results. I'll remove all ublas results > before the next run. Martin thanks for responding to this. I have been watching the results for a while. I just looked at todays results and there are still errors. Last week I intentionally add some blank lines into some source files to change the line numbers in runtime asserts. Todays results are still showing the old line numbers. Since you removed old ublas results before the test I suspect there must be some problem with your CVS updates. I have double checked and Boost CVS has the new file versions. For example boost/numeric/ublas/vector_assign.hpp should be labeled: Revision 1.25 Fri Sep 24 06:31:48 2004 UTC (4 days, 1 hour ago) by mistevens Thanks and good luck, Michael

2 2

[uBLAS] Linux regressions
by Aleksey Gurtovoy 28 Sep '04

28 Sep '04

uBLAS "test2" currently fails with most of Linux toolsets, and it used to pass in the previous release -- http://tinyurl.com/3vmlv. Does anybody has any idea what's up here? -- Aleksey Gurtovoy MetaCommunications Engineering

2 3

serialization: buffers
by Darren Cook 28 Sep '04

28 Sep '04

I've a class like this: class Example{ int str[BSize]; int *p; }; Where p points to next available element (p==str+BSize is possible when it is full). I.e. str is like begin() and p is like end(). I want to add a serialize() function, something like this: template<class Archive> void serialize(Archive &ar,const unsigned int){ ar & BOOST_SERIALIZATION_NVP(buf,p); } but there seems to be no support for buffers like this? For the moment I've implemented using separate load/save functions, where save writes the buffer size and load starts by reading it. While much simpler than the load/save code I'm replacing, the above 1-liner is even more appealing. Darren

1 0

RE: [boost] lexical_cast.hpp:102: error: `wstring' is not a member of `std' ?
by DY, JERRY U (SBCSI) 28 Sep '04

28 Sep '04

Could be related to the following g++ problem. Scheduled to be fixed in gcc 3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17005 -Jerry -----Original Message----- From: Rob [mailto:spamrefuse@yahoo.com] Sent: Sunday, September 26, 2004 9:17 PM To: boost(a)lists.boost.org Subject: [boost] lexical_cast.hpp:102: error: `wstring' is not a member of `std' ? Hello, I'm not a boost expert, but I'm using LyX, which has boost (version 1.31.0) included in its source code. I have FreeBSD (4.10) and use gcc 3.4.2. When I compile LyX, I get an error from boost: [...] ../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a member of `std' ../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a member of `std' ../../boost/boost/lexical_cast.hpp:103: error: template argument 1 is invalid ../../boost/boost/lexical_cast.hpp:103: error: explicit specialization of non-template `<type error>' ../../boost/boost/lexical_cast.hpp:162: error: declaration of `operator>>' as non-function ../../boost/boost/lexical_cast.hpp:162: error: expected `;' before '(' token ../../boost/boost/lexical_cast.hpp:168: error: expected `;' before "private" When I reported this to the LyX list, I was told to forward the problem to the boost list. There may be a problem here with FreeBSD, gcc 3.4.2 and boost. Any idea what is going on here? Thanks, Rob. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

regression results? (where's the beef??)
by Victor A. Wagner Jr. 28 Sep '04

28 Sep '04

Is it just me, or have the regression results not been picked up by metacomm in the past 24 hours? Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

3 2

Re: immutable string
by Igor Kholodov 28 Sep '04

28 Sep '04

>> Agree, but which name should we used - >> "reverse_const_iterator" >> or "const_reverse_iterator"? >> I thought it was the latter. > >Now I see :) Will fix it. Great, after the fix I will run the same tests with VC 7.1. It is amazing how many strings are const_string-compatible objects! Thanks, Igor Kholodov cttl(a)users.sourceforge.net http://cttl.sourceforge.net/

2 1

[boostbook] link to an enum
by Angus Leeming 27 Sep '04

27 Sep '04

I can define a link to a class with: <classname alt="boost::glob_predicate">glob_predicate</classname> How do I define a link to an enum? It seems that a shorthand notation is missing. Is there a longhand way? Regards, Angus

3 3

[boostbook] mangling of names of generated docs
by Angus Leeming 27 Sep '04

27 Sep '04

I find that if I have a header file "foo_bar.hpp" containing the declaration of a function "foo_bar" (there may be other functions in there too of course), then the generated html docs are: Writing foo_bar.html for refentry(foo_bar) Writing id2767798.html for section(id2767798) foo_bar.html contains the docs for the function whilst id2767798.html contains Header <foo_bar.hpp> namespace boost { namespace child { void foo_bar(std::string const &); } } I can see why this is done, but why not modify the mangling so that id2767798 becomes foo_bar_hpp and id2767798.html becomes foo_bar_hpp.html? Especially since each regeneration of the docs results in a different ID. Regards, Angus

1 0

Re:Re: [boost] Re: FORMAL review of "Output Formatters" - votes needed
by Robert Ramey 27 Sep '04

27 Sep '04

Reece wrote: >Roland Richter wrote: > John Torjo wrote: > >> The dilemma I see is that the outfmt library is somewhere between >> serialization (boost::serialization) and pretty-printing >> (boost::format). IMO, outfmt provides *both* at a basic level in that >> it simply adds streaming operators << and >> to STL containers, >> which, for some reason, are currently missing. What advantages does using the output formatters for output/input have over using the serialization library to do the same thing? Robert Ramey

1 0