- Boost - lists.boost.org

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

Boost Iterable Range Library update (v1.5)
by John Torjo 12 Nov '04

12 Nov '04

Dear boosters, I have updated the Iterable Range Library (formely known as Range Templates Library). It makes dealing with containers/STL algorithms simpler by using ranges (as opposed to iterators). Simply put, a range is a smarter std::pair<iterator,iterator>. Here's a taste: for ( crange<some_array_type> r(some_array); r; ++r) do_something( *r, some_data); Also, the library provides wrappers for all STL algorithms (for the purpose of STL algorithms, all containers are ranges as well): typedef std::vector<std::string> word_array; word_array v; // STL version std::copy( v.begin(), v.end(), print); // rng:: version rng::copy( v, print); Also, the counterparts for STL algorithms that return an iterator will return a range, allowing for: // fill a vector with all the indexes at which a certain string is found std::string str = "I'm a cool programmer, really cool that is", find = "cool"; std::vector<int> result; crange<std::string> r(str); while ( r = rng::search(r, find)) result.push_back ( r.begin() - str.begin() ); And it provides for range adaptors, allowing for composition. bool from_ro(const employee & e) { return e.country == "Romania"; } std::string get_empl_name(const employee &e) { return e.name; } typedef std::vector<employee> array; array empls; // take all employees from Romania, and print their names rng::copy( transformed( filtered(empls,from_ro), get_empl_name), std::ostream_iterator<std::string>(std::cout," ")); Changes in this version: - improved algorithms.hpp (no more use of macros) - solved small bugs - added documentation Download it from here: http://www.torjo.com/rangelib/ Feedback is welcome. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html

10 27

Re: Generalised reflection
by George van den Driessche 12 Nov '04

12 Nov '04

> Message: 4 > Date: Fri, 12 Nov 2004 07:34:27 -0500 > From: "Neal D. Becker" <ndbecker2(a)verizon.net> > Subject: [boost] Re: Generalised reflection > To: boost(a)lists.boost.org > Message-ID: <cn2akj$qij$1(a)sea.gmane.org> > Content-Type: text/plain; charset=us-ascii > > George van den Driessche wrote: > > [...] > > Yes. Now imagine that I've got some helper functions for use with > > Boost.Python's pickling suite. But I want to use them with a C++ > > serialisation library. I'm going to have to factor a bunch of code out of > > those helper functions so that I can invoke them without using > > boost::python::tuple, and then write wrappers to use the factored-out code > > with the Boost.Python pickling suite. Instead, I want to write just the > > C++ serialisation code, and have that automatically wrapped up for use > > with Boost.Python pickling. It's a similar separation of layers. > > > > Incidentally, I wrote about sharing boost c++ serialization with > boost.python pickling, and posted code demonstrating this. Nobody seemed > very interested. I think it's this post: http://tinyurl.com/6dbhb that you're referring to. In which case, I missed it, but yes, you're on the same topic. 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, // 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. ;

2 1