- Boost - lists.boost.org

1.32 Draft Tarball: MPL docs completely missing?
by Stefan Slapeta 15 Nov '04

15 Nov '04

Currently, mpl/doc/index.html shows this information: The Boost MPL library documentation is currently undergoing a major overhaul for the 1.32 release. Please come back in a few days. :-( Stefan

2 1

[graph] bellman_ford_shortest_paths interface
by Vladimir Prus 15 Nov '04

15 Nov '04

Hi, after trying to use the bellman_ford_shortest_paths I think it's a little bit strange. First of all, user is required to initialise distance map before calling the algorithm. The distance to the source vertex must be set to zero and distances to other vertices to infinity. Why can't the algorithm accept a source vertex as parameter and do initialisation itself? Dijsktra surely does not require such initialization. Another problem is that number of vertices is passed as parameter. I realize this is more flexible (for example I can compute the maximum length of all paths with less than N edges), but it's also confusing and dangerous. I've just passed a wrong variable to that parameter and spend quite some time debugging. Is it possible to provide a version of the algorithm which (1) takes just graph, without vertex number parameter (2) takes start vertex, and initialises distance map itself - Volodya

2 6

Still OK to merge changes into 1.32.0?
by Beman Dawes 15 Nov '04

15 Nov '04

I've just fixed a minor Windows only filesystem::path bug in the CVS head. Is it OK to merge the fix into 1.32.0, or is 1.32.0 closed? --Beman

2 3

[1.32 release] RC_1_32_0 branch is closed for any modifications
by Aleksey Gurtovoy 15 Nov '04

15 Nov '04

Please see the subject. If you think that something just *has* to be committed to the branch, please post a query to the list before doing so, however trivial the change is (this includes fixes to the documentation and likes). Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

[BGL] Determining whether a path exists from vertex U to vertex V
by David M. Jones 15 Nov '04

15 Nov '04

I have looked at the BGL User Guide/Reference manual book but I can't seem to find the answer to this seemingly basic question. I have a directed BGL graph. Given two vertices U and V, I want to know whether there is a path from U to V. I don't care what path it is; I just want to know whether one exists or not. It looks like I might be able to use the BFS or DFS to do this, but that seems like attacking a mosquito with a tank. A slightly more complicated problem that I want to solve is: given vertices U and V, I want to know whether there is a path from U to V such that all edges along the path have a certain property. Again, I don't care to know what the path is or its length; only whether or not such a path exists. Thanks in advance, David Jones

3 3

Re: GUI Library Proposal for a Proposal
by George van den Driessche 15 Nov '04

15 Nov '04

> Message: 11 > Date: Fri, 12 Nov 2004 22:18:53 +0200 > From: John Torjo <john.lists(a)torjo.com> > Subject: Re: [boost] Re: GUI Library Proposal for a Proposal > To: boost(a)lists.boost.org > Message-ID: <41951AAD.20208(a)torjo.com> > Content-Type: text/plain; charset=us-ascii; format=flowed > > >> >> You have made a good point. I still feel uncomfortable about parsing >> header >> files to determine type information. If header files were used, since >> run-time reflection does not exist, one would have to inject the >> correct >> code into source files based on design-time decisions. But it does >> seem as > > I think reflection in general is very different from reflection for a > GUI. > > When you have a GUI control, you want to apply reflection for a few of > its properties. You won't have #ifdefs (or at least I would consider it > bad design). Case in point: its interface should be extremely simple > and > easy to parse. > > You shouldn't need complex information like reflection for virtual > functions, overloading etc. > > Even reflected property types should be of trivial types: > 1. build in types > 2. std::string > 3. types that can simply be read from /written to strings. > > For case 3., you might also have a validation function which will be > used in design-mode to validate user input. > > At least that's what I want. I *think* what you envisage is based around collecting data from the user via dialogs. So in your view of things, there would be a C++ object that holds the collected data, a set of validation routines, and a reflection map that binds these to the UI. But you don't do anything to the program state until the user clicks "OK" in your dialog, at which point you suck the data out of your simple C++ object and act on it. In contrast, other people (myself included) are considering binding properties and member functions to the UI for similar purposes to why you would expose them to script: to allow the user to drive them. So, for a simple example, let's suppose you have some object that corresponds to a file: class file_backed_t { public: std::string get_filename(); /// This actually renames the file on disk. void set_filename( std::string const& ); }; Now, when you bind the filename property to the UI, you'll automatically do the rename as soon as the user changes the text in the edit box. (Probably that isn't the desired behaviour in this case, but it serves as a demonstration.) This usage pattern corresponds better to modeless dialogs where you don't have an "OK" button. Of course if you are using a generalised reflection architecture like I mentioned yesterday, then you can do both approaches: > One of the things that I noticed about serialisation code is that > there's > generally a symmetry between the reading and writing routines. So > rather > than write "this is how I load an X, and this is how I save one" I'd > want to > write "these are the things in X that need to be saved" and let some > templates figure out what the corresponding routines are. And then it > was > this desire to serialise things automatically by specifying properties > that > led me on to think about a common architecture for language binding and > serialisation. Maybe in the end you'd get declarations like: > > /// Properties for serialisation > boost::properties< my_t, "my_t", boost::serialisation > > .def( "my_int", &my_t::my_int, &my_t::set_my_int ) > // After serialisation format version 4,a > // my_float no longer needed to be serialised > .def( "my_float", &my_t::my_float, &my_t::set_my_float, > boost::serialisation::in_format_version_range<>( 0, 4 ) ) > ; > > /// Properties for scripting > boost::properties< my_t, "my_t", boost::langbinding > > // Use serialisation properties to implement pickling. > .def_pickle( default_pickle_suite< my_t >() ) > .def( "my_int", &my_t::my_int, &my_t::set_my_int, > boost::langbinding::return_internal_reference<>() ) > // We don't want to bind my_float, for whatever reason. > ; boost::properties< file_backed_t, "file_backed_t", boost::gui > // This is a heavyweight property for a modeless dialog .def( "filename", &file_backed_t::get_filename, &file_backed_t::set_filename ) ; // dialog_data_t is just a struct to store data for a modal dialog till // the user clicks "OK", which is when we process it. struct dialog_data_t { std::string filename; // Says whether to back up the specified file before // processing it. bool make_backup; }; // Helper function for dialog_data_t reflection. bool is_good_filename( std::string const& ); boost::properties< dialog_data_t, "dialog_data_t", boost::gui > .def( "filename", &dialog_data_t::filename, boost::gui::validator( &is_good_filename ) ) // No validation required for this simple bool. .def( "make_backup", &dialog_data_t::make_backup ) ; George

2 1

Some problems with shmem vs. thread jam building
by ION_G_M 15 Nov '04

15 Nov '04

Hello to all, I keep on working on a shared memory boost library proposal. I've followed Boost.Build guidelines to write the jam file, and auto_link header, but when writing and executing the jam file I have the following errors (I'm new to jam and dll building, so forgive me if you find any question too simple): 1) DLL-s I wanted to reuse detail::thread::lock class for process shared mutexes in order to follow the same structure as thread::mutex, but when building my library dll-s from boost root using bjam "-sTOOLS=vc-7_1" stage/install the linker complains that it can find thread library dlls (I suppose due to auto_link headers). I don't know if linking a dependant library is needed when building a dll (in my embedded world, i never design dll- s so I don't know that). If the library is needed, should I specify a <library-path> for that in dll building rule? If not needed, do I have to define a symbol to disable auto_link feature for boost::thread in my dll rule? 2) boost::thread config Apart from this, when building static libraries, I can't compile boost::detail::thread::scoped_lock if I use it as main locking scheme for process shared mutexes when building single threaded shared memory static library, since thread headers check for correct multithread configuration (I suppose looking for _MT defines). - - - - - - - - - - - - For the moment I've decided to copy thread scoped_lock to my library changing the namespaces so that I can compile my library and continue integration. I would like to know if it is convenient to reuse thread scoped_locks for process shared mutexes. For a simple proposal that can be easily rejected, I'm not requesting any change, but I would like to point out that maybe scoped_locks should be reused for both thread and process shared mutexes in the future. But my main concern is the linker error when building a dll for a boost library that depends on other boost library. Best regards, Ion Gaztañaga

2 1

transparent INF - does it exist
by Manfred Doudar 15 Nov '04

15 Nov '04

c/- All: In taking a holistic look at some of the work I do, I've come to realize a need for a "transparent" data type, and wondering whether or not it exists. As all of you would have experienced, any organization has such a representation of such a type; be it called: "Null value", "Missing value", "Fill value", "Infinity" , or whatever. What I am hoping for is support for such an representation, with existing containers and algorithms; such that if you perform any mathematical operation, (arithmetic, transcendental; inverse; anything really ...); that you get back the *same* object (ie. it passes transparently through any operation), and not raise any exception if you so choose. Example: missing_val == atan(missing_val) - missing_val; missing_val == 1 / missing_val; missing_val == missing_val + missing_val; missing_val == missing_val - missing_val; typedef std::vector<any_type> dVec; dVec some_vector; ... populate some_vector ... dVec::iterator = some_vector.find(missing_val); Boosters, do we have such a representation; is there value in having such a thing in Boost; is there a (simple) alternative work-around ?? All ideas and comments appreciated. Cheers, -- Manfred MetOcean Engineers

2 2

RE: [boost] Re: GUI Library Proposal for a Proposal
by Brian Braatz 15 Nov '04

15 Nov '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Edward Diener > > Brian Braatz wrote: > > (was RE: [boost] Re: GUI library - something to think about) > > > > Both > > http://www.torjo.com/win32gui/save_dlg.html > > > > and > > > > http://www.litwindow.com/Library/Documentation/documentation.html > > > > are extremely interesting. > > > > What I see (just after taking a peek at both): > > > > Win32Gui > > Interesting design > > No macros > > Looks tied to Win32Gui > > > > LitWindow > > Also interesting design > > Does have macros > > Also sits on top of WxWidgets, but it looks like the WxWidgets > > layer could be abstracted out. > > > > I propose that BOTH authors collaborate (on this list) to achieve the > > following: > > > > * Combination of the best of both frameworks > > * Can sit on WxWidgets OR can have a win32 and xwindows underlying > > implementation > > No !!!!! WxWidgets has almost nothing to do with modern C++. Let's no go > there, or have anything to do with supporting any other GUI > implementation. > > [Brian Braatz] PLEASE Re-Read my words. "> > * Combination of the best of both frameworks > > * Can sit on WxWidgets OR can have a win32 and xwindows underlying > > implementation" If you have a good abstraction - then the ability to "plug in" the underlying implementation (through various mechanisms) means you are not tied to WxWidgets. This also means that conversely, you CAN take advantage of something in WxWidgets (or qt, or win32 or whatever) if you so desire. Boost::gui should not be trying for a kitchen sink approach (like WxWidgets or Qt), but instead would provide a simple and clean abstraction for common functionality. I will always (or frequently) have to write WxWidgets specific code or os specific code, but having a abstraction available from boost would mean most of my code would be portable across framework. I suggest a "first cut" would have a xwindows "plug in" and a win32 plug in, and potentially a WxWidgets and or Qt It is more than practical to have the boost gui abstraction cover the most common concepts. This not only makes it small and easy to implement, but also allows me to write directly to WxWidgets where it makes sense. This is what I would call "having balance" between a standard approach and still allowing for a developer to have the choice to take advantage of specific OS or gui framework feature as they desire. The fact that WxWidgets does not have "modern techniques" is a plus for boost::gui. The fact that WxWidgets is huge and covers a lot of things (and has been around for awhile) is a plus for them. A well designed "gui abstraction layer" would have the following properties: * move the technology of binding forward * Not try to be everything for everybody * allow for the choice of being able to write "boost standard gui code" vs taking advantage of whatever specific thing you are working with These principles, also have the advantage of placing a combination of ltwindows and win32gui in a spot where a combination of the two would in fact meet those properties. AND it would be accomplishable in a short timeframe. And that, is my point :)

4 6

[1.32 release] is the codebase already frozen?
by JOAQUIN LOPEZ MU?Z 15 Nov '04

15 Nov '04

Some days ago an imminent codebase freezing was announced, but I won't know whether it is already in effect. Do I still have time to fix some things in my library? The fixes are not crucial, so I can as well wait after the release is out, but well if granted a day or two I'd prefer to address this now. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1