November 2004 - Boost - lists.boost.org

[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

[Variant] Sample doesn't compile because of missing 'const'
by Stefan Slapeta 14 Nov '04

14 Nov '04

In the code sample in 'Binary visitation', the const modifiers for the two operator () are missing; thus, the sample doesn't compile at all! Stefan

2 1

Re: BOOST_LOG
by Reece Dunn 13 Nov '04

13 Nov '04

Eljay Love-Jensen wrote: > Hi Reece, > > You'd have to run the source code through the pre-processor twice to remove > the comments. > > Comments are stripped out first, then macro-expansion. (Not surprisingly, > Microsoft's compiler is non-compliant, and the trick works on their > platform.) How about: class null_log { public: template< typename T > null_log & operator<<( const T & ) { return *this; } }; null_log log; #define BOOST_LOG(id) log This should work and a good compiler should be able to optimize away the log output, leaving only the small footprint of the global variable. It also has the advantage of being multi-line compatible: BOOST_LOG(dbg) << "message: " << foobar; Regards, Reece

1 0

[ANN] Format Lite
by Jonathan Turkanis 13 Nov '04

13 Nov '04

Dear All, I've just finished documenting a small library, available here: http://home.comcast.net/~jturkanis/format_lite/ It's a lightweight version of Reece Dunne's recently reviewed Output Formatters library. It was inspired by the discussion of Reece's library on this list and by the discussion of TR1 tuple i/o at the recent standards committee meeting in Redmond. ----- Format Lite is a lightweight, easy-to-learn framework for formatting data structures such as standard library containers and Boost tuples. It provides a reasonable degree of customizability with an emphasis on human-readable output formats useful for testing and debugging. A future version of Format Lite could be a candidate for incorporation into C++0x, to compensate for the lack of standard iostreams inserters and extractors for standard library containers, and to make existing inserters and extractors - such as those provided in <complex> - more flexible. Format lite provides three function templates: * boost::io::punctuate, used to specify punctuation sequences and options for line-breaks and indentation. * operator<<, used to insert ranges and tuple-like objects into standard output streams. * operator>>, used to extract ranges and tuple-like objects from standard input streams. ----- Best Regards, Jonathan

9 27

Testing interest for a shared memory/STL library proposal
by Ion Gaztañaga 13 Nov '04

13 Nov '04

Hello to all, My name is Ion Gaztañaga, a telecommunication engineer working in railway industry R&D . I've been lately working on a CUJ article about placing STL containers (and any other object) in shared memory using smart pointers instead of raw pointers as allocator::pointer. The article has been accepted for a future issue and is currently in a editing/reviewing phase. Working in this article, I've created a library/framework, developing some classes that I think can be useful for a new boost library. I would like to know if there is any interested in boost for developing such classes, based or not in my article ideas or code. If there is any interest, I would be glad to present a boostified version of the library/framework for a review proccess. Currently, the framework uses these ideas: -> Relative pointers (smart pointers) for placing them in shared memory. -> OS basic mechanism abstractions: shared-memory creation, process-shared mutex, named semaphore -> Shared memory allocator for dynamic allocation/deallocation of parts of a shared memory segment. -> Named shared memory allocation manager, so that any process can look for an object in shared memory. -> Pooled shared memory allocator for node containers. -> Some STL-like container examples that can be placed in shared memory for systems with no smart-pointer allocator::pointer supporting STLs -> others... The framework works with Win32/Visual.NET 2003, QNX6.x/gcc-2.95.2,Mandrake Linux10.1/gcc-3.4.1 and partially (relative pointers and raw shmemory allocation) with Win32/VisualC++ 6.0. I've put a special full-length article in html and the source code in the file http://ice.prohosting.com/newfunk/boost_shmemSTL.zip, so that anyone can take a look. Please, you don't need to waste much time in the article, since I just want to know if contained ideas are interesting for boost. Please remember that some classes such as scoped-locks, etc... are in boost but I wanted the framework to be independent of any other library for this article. Of course, this would change in an hypotetic boostified version, since this is only to get an idea. Please, feel free to comment/critisize. Regards, Ion

6 7