January 2006 - Boost - lists.boost.org

[program_options] Bug: "ambiguous" option shouldn't be
by Braden McDaniel 09 Jan '06

09 Jan '06

When the attached test program is run as $ program-options-test --foo program_options in Boost 1.33.1 thinks the option is ambiguous; apparently because there is another option that starts with "foo" followed by a dash. This is a regression with respect to 1.32.0. -- Braden McDaniel e-mail: <braden(a)endoframe.com> <http://endoframe.com> Jabber: <braden(a)jabber.org>

2 1

[program_options] split_winmain bug (Was: Bug in boost::program_option)
by Vladimir Prus 09 Jan '06

09 Jan '06

Hi Tilman, On Thursday 05 January 2006 14:57, you wrote: > see src/program_options/winmain.cpp: > > #ifndef BOOST_NO_STD_WSTRING > BOOST_PROGRAM_OPTIONS_DECL std::vector<std::wstring> > split_winmain(const std::wstring& cmdline) > { > vector<wstring> result; > vector<string> aux = split_winmain(to_internal(cmdline)); > --> for (unsigned i = 0, e = result.size(); i < e; ++i) > result.push_back(from_utf8(aux[i])); > return result; > } > #endif > > Correct ist (aux and not result!): > > for (unsigned i = 0, e = aux.size(); i < e; ++i) You're right, the change is just committed. Thanks! BTW, it's better to send proposed code changes to the Boost mailing list, so that other users are aware. Thanks, Volodya

1 0

[mpl] mpl::is_sequence problem
by Joel de Guzman 09 Jan '06

09 Jan '06

Hi, A few months ago, I had a problem with mpl::is_sequence. It seems that the problem is not yet fixed. Anyway, to simplify, here's the code that exhibits the problem: #include <boost/mpl/is_sequence.hpp> int main() { bool r = boost::mpl::is_sequence<boost::mpl::int_<0> >::value; return 0; } The code does not compile on all compilers that I use regularly (VC++, g++ and Comeau). Here's a another code that does not compile: #include <boost/mpl/is_sequence.hpp> struct x { typedef int tag; }; int main() { bool r = boost::mpl::is_sequence<x>::value; return 0; } Is there any chance for this to be fixed in the immediate future? I rely on mpl::is_sequence for constrained genericity and concept checking in fusion. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

2 2

library proposal: garbage collection
by Achilleas Margaritis 09 Jan '06

09 Jan '06

Dear boost developers, the following proposal is about a small library for multithreaded garbage collection using only boost threads. The major issues for a garbage collection system in C++ are the following: 1) knowing the root set of pointers. 2) knowing which objects are garbage collected. 3) performance of the collector in relation to multithreading. 4) the garbage collection algorithm. I believe it is possible to make a garbage collection system using standard C++ and boost threads only. The following paragraphs analyse the issues and the proposed solutions. -------------------------------------------------------------------------------------------------------- 1) knowing the root set of pointers. The root set of pointers is composed of: a) the set of global pointers of the main thread. b) the set of pointers allocated on the stack of each thread. Since it is not possible to know where the stack of each thread is without using low-level non-portable techniques, I propose the following: a) each garbage-collected thread shall have its own pointer stack allocated as thread-local-storage. The size of the pointer stack shall be analogous to the size of the hardware stack for the size of pointer of the machine. b) a special pointer class will: 1) push itself in the current thread's pointer stack mentioned above, on construction and 2) pop itself from the current thread's pointer stack, on destruction. The above solution makes it possible to: a) know exactly where root pointers are: in the pointer stack of a garbage-collected thread. b) be quite fast, since there is not going to be any synchronization: each thread will take care of its own pointer stack. -------------------------------------------------------------------------------------------------------- 2) knowing which objects are garbage collected. The usual approach to knowing which objects are garbage-collected is to add each garbage-collected object to a global list of objects. But that solution is slower than what it could be, since access to the global list of objects must be serialized for all active threads. My proposal is to have one thread-specific linked list of garbage collected objects; a special object class will provide 'operator new' that adds the allocated block to a thread-specific linked list of garbage collected objects. This class will also provide 'operator delete', in order to have manual object deallocation as well as automatic one. -------------------------------------------------------------------------------------------------------- 3) performance of the collector in relation to multithreading. Since my proposal utilises thread local storage, there is no serialization penalty; therefore, the system can have as many threads as needed, without impact on performance. -------------------------------------------------------------------------------------------------------- 4) the garbage collection algorithm. My proposal for the garbage collection algorithm is the following: step 1: suspend all known garbage collected threads, except the current one. step 2: traverse the root set of pointers of all known threads; mark reachable objects. step 3: delete unreachable objects. step 4: resume all previously suspended threads. The algorithm should be invoked from inside 'operator new' when the amount of allocated memory exceeds a user-defined limit. I propose a simple stop-the-world, then mark-and-sweep algorithm for the following reasons: a) it is easy to implement. b) it does not require access to the platform-specific stuff. -------------------------------------------------------------------------------------------------------- In this section I present the proposed solution in the form of C++ code mixed with pseudo-code and comments, in order to understand the proposal better. class gc_thread : public boost::thread { public: gc_thread() { allocate thread-specific pointer stack allocate thread-specific object list place the thread-specific object list in a global list of object lists add thread in the global list of garbage-collected threads } ~gc_thread() { delete the thread-specific pointer stack } }; template <class T> class gc_ptr { public: gc_ptr() { push this pointer to the current thread's pointer stack } gc_ptr(const gc_ptr<T> &ptr) { push this pointer to the current thread's pointer stack } ~gc_ptr() { pop this pointer from the current thread's pointer stack } }; class gc_object { public: virtual ~gc_object() { } void *operator new(size_t size) { if (gc_memory_size > gc_max_memory_size) collect_garbage(); block *result = ::operator new(size + sizeof(block)); block->iterator = insert new block in the current thread's list of objects block->size = size; return result; } void operator delete(void *ptr) { erase iterator of block from current thread's list of objects if the current thread's list of objects is orphan (i.e. the thread has finished) and the list is empty, delete the list ::operator delete(ptr); } static void collect_garbage() { suspend all garbage-collected threads (except this) //change the mark flag in order to catch unreachable objects gc_mark = !gc_mark; //mark phase for each pointer stack S of each garbage-collected thread { for each pointer P in S { if P != null { mark(P); } } } //sweep phase for each block B of each object list of each garbage collected thread { if (B.mark != gc_mark) delete B; } resume all garbage collected threads (except this) } private: struct block { block_iterator it; size_t size; bool mark; }; static bool gc_mark = false; static size_t gc_memory_size = 0; static size_t gc_max_memory_size = GC_DEFAULT_MEMORY_SIZE; static void mark(block *b) { if (b->mark == gc_mark) return; //block already marked b->mark = gc_mark; for each pointer P in block { if P is pointer then { mark(p); } } } }; -------------------------------------------------------------------------------------------------------- Thank you for your attention. Achilleas Margaritis

1 0

Re: [boost] Performance comparison between ptr_vectorandvector<cow_ptr<Shape> >, vector<copy_ptr<Shape> >
by boost 08 Jan '06

08 Jan '06

"Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message news:<dprgjh$1p5$1(a)sea.gmane.org>... > David Maisonave wrote: > > >>>I'm not sure what you're referring to here. Can you post an > >>>example? > >> > >>*ptr = *ptr2; > > > > > > Can you please give a more complete example? > > Which is the smart pointer, here, and exactly what type of pointers? > > let's assume non of the types involved are abstact. > > Anyway, we have been here before and are starting to move in circles. Even if we assume none of the types are abstract, I still don't understand what's suppose to happen in above code. What type is what in above example? By the way, I figured out why some of the results were so poor for copy_ptr and cow_ptr. Some of it had to do with assert logic, and some of it had to do with the boost pointer performing slicing. I had a derived derived class that I left out the clone function intentionally for a different test, and I mistakenly used it for the performance test. The cow_ptr still suffers in performance when populating the container compared to boost pointer. It's a approximately a two to one ratio. But the cow_ptr also still out performance the boost container by abut 4 to 1 when doing a copy of the container. I think the call to new in the cow_ptr constructor is what's making the difference when populating the container. The copy_ptr has similar results to the boost pointer container, except for the copy container test, in which it seems to out perform the boost pointer by about %20. You can download the new code via following link: http://code.axter.com/copy_ptr.h http://code.axter.com/cow_ptr.h http://code.axter.com/shape_test.h http://code.axter.com/boost_ptr_containers/main.cpp Here are the new results: Test performance for interating through a container of pointers via []. vector<copy_ptr<Shape> > 1.80 s boost::ptr_vector<Shape> 1.81 s vector<cow_ptr<Shape> > 2.06 s Test performance for interating through a container of pointers via iterators. vector<copy_ptr<Shape> > 1.80 s boost::ptr_vector<Shape> 1.77 s vector<cow_ptr<Shape> > 1.94 s vector<copy_ptr<Shape> > 1.78 s boost::ptr_vector<Shape> 1.78 s vector<cow_ptr<Shape> > 1.95 s Test performance for populating container of pointers via factory method. vector<copy_ptr<Shape> > 2.13 s boost::ptr_vector<Shape> 1.86 s vector<cow_ptr<Shape> > 3.63 s vector<copy_ptr<Shape> > 2.13 s boost::ptr_vector<Shape> 1.88 s vector<cow_ptr<Shape> > 3.66 s Test performance for initializing and copying container of pointers. vector<copy_ptr<Shape> > 28.91 s boost::ptr_vector<Shape> 36.11 s vector<cow_ptr<Shape> > 9.34 s vector<copy_ptr<Shape> > 28.38 s boost::ptr_vector<Shape> 35.70 s vector<cow_ptr<Shape> > 9.41 s

1 0

Unlisted utilities
by Daryle Walker 08 Jan '06

08 Jan '06

Did you know that we have a BOOST_ASSERT? Its documentation page is at <http://www.boost.org/libs/utility/assert.html>. Unfortunately, that page isn't reachable through our library listing at <http://www.boost.org/libs/libraries.htm>. I found it through the Google-enabled search on the front web page. I guessed, and found, a web page at <http://www.boost.org/libs/utility/> that listed the assert, but that page isn't on the main list either. Of the utilities listed, the assert, iterator adaptors, and throw exception have no corresponding entry in the main library list. We should fix this. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 2

[test]exception safety testing
by Gennadiy Rozental 08 Jan '06

08 Jan '06

Hi, This update includes my first steps in new areas of interaction based testing. One important branch is automated exception safety testing. This scheme was originally used by Dave A. in his work for STLPort testing. And also there was some variation covered in April 2001 CUJ. To employ this new facility one need to include exception_safety.hpp and (most probable) mock_object.hpp. The interface is a single invocation function: namespace itest { void exception_safety( unit_test::callback0<> const& F, unit_test::const_string test_name = "" ); } The function under test should include some statements to be tested for exception safety and checks for invariants using regular Test Tools. Boost.Test will make sure all possible execution patches are tested Faking failures in different locations. Any Test Tool failure is treated as failed invariant and abort specific execution path. Interface also include a helper macro that support auto registration and slightly simplify users life: ------------------------------------------ BOOST_TEST_EXCEPTION_SAFETY( test_name ). ------------------------------------------ Here is an example usage: --------------- // Here is an exempt from simple (incorrect) stack implementation; It is instrumented to better identify failure locations template<class T> class stack { public: explicit stack( int init_capacity = 10 ) : m_capacity( init_capacity ) , m_size( 0 ) , m_v( BOOST_ITEST_NEW(T)[m_capacity] ) { BOOST_ITEST_SCOPE( stack::stack ); } ~stack() { delete[] m_v; } void push( T const& element ) { BOOST_ITEST_SCOPE( stack::push ); if( m_size == m_capacity ) { m_capacity *= 2; T* new_buffer = BOOST_ITEST_NEW( T )[m_capacity]; for( unsigned i = 0; i < m_size; i++ ) { new_buffer[i] = m_v[i]; } delete [] m_v; m_v = new_buffer; } m_v[m_size++] = element; } unsigned size() { return m_size; } private: unsigned m_capacity; unsigned m_size; T* m_v; }; //____________________________________________________________________________// BOOST_TEST_EXCEPTION_SAFETY( test_stack_push ) { stack<mock_object<> > st( 2 ); for( unsigned i = 0; i < 3; ++i ) { try { st.push( simple_mock ); } catch( ... ) { // this invariant checks that in case of failed push number of elements doesn't change BOOST_CHECK_EQUAL( i, st.size() ); throw; } } } This examples shows memory leaks and failed invariants in specific execution paths. Execution path is reported and leaking memory is dumped. New parameter is introduced for Unit Test framework: --break_exec_path=<test_name>:<execution_path_index> Using parameter in conjunction with --catch_system_error=no should allow you to see an execution path causing a memory leak in debugger(Boost.Test will force an abort in failure location). test_name above is the name of the test case and execution_path_index is reported index of execution path containing a memory leak. I would appreciate any comments and subjections for this new facility. Regards, Gennadiy

3 13

Re: [boost] Interest in dimension/unit-checking library?
by Keith Nicewarner 08 Jan '06

08 Jan '06

Geoffrey Romer wrote: > Would there be any interest in a library for attaching units (physical > or otherwise) to numeric variables, so that the type system could > enforce dimension- and unit-consistency in all calculations, and > convert semi-automatically between compatible units? I'm fairly new to boost, so forgive my late entry into this discussion. I too recognized the need for this kind of library back in the late 90s and wrote this library available on SourceForge: http://tuoml.sourceforge.net/ It's pretty stable and used on several projects (there's a military simulation tool that has standardized on it). I've recently discovered the meta-programming method for dimensional quantities by Scott Meyers: http://se.inf.ethz.ch/~meyer/publications/OTHERS/scott_meyers/dimensions.pdf This inspired me to revisit my library and it is turning out to be a fairly easy conversion. The old library had to explicitly represent each unit combination of interest (e.g., Speed = Length/Time), which is ugly and doesn't allow arbitrary combinations. The new method fixes all this (in fact, it simplifies things to the point where there is no library object file any more -- just headers). A key concept I tried to enforce is that any time the programmer sets or gets a numeric value, the specific units (i.e., Feet, Meters, etc.) must be specified. I don't want any units to be implicit. My library provides ostream formatting for handy printing. I also provide scalar, 2D, and 3D types. For the 2D/3D types, I provide various transformation operators like rotation. For 3D rotations, I provide the option of cosine matrix or unit quaternion. It's been suggested to me that I submit my library to boost. Being new to boost, I'm not sure how complete and tested the code needs to be. Any feedback or suggestions are welcome. Keith.

11 37

Re: [boost] Performance comparison between ptr_vectorandvector<cow_ptr<Shape> >, vector<copy_ptr<Shape> >
by David Maisonave 08 Jan '06

08 Jan '06

"Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message news:<dpmc2d$f75$1(a)sea.gmane.org>... > David Maisonave wrote: > > "Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message > > >>I'm not sure I fully understand how the detection mechanism would > >>work in your cow_ptr. > > > > > > Example code: > > template<typename T_obj> > > cow_ptr(T_obj* type): m_ref_count(new ref_count(type, > > get_alloc_func(type))) > > { > > assert(typeid(*type) == typeid(T_obj)); > > } > > how can that assertion ever fail when T_obj is deduced? The only way that cow_ptr and copy_ptr can get slice is if the wrong type is pass to the constructor. Example code: Derivedtype* p = new DerivedDerivedType; cow_ptr<BaseType> pBase(p); //This will cause an assertion since p type does not match the pointee > > > Since the cow_ptr works by capturing the type on the constructor, it > > can easily determine if the right type is being passed in, and if it > > matches the pointee type. That can't be done with the boost pointer > > containers because they don't catch the type on the constructor, nor > > is it part of the required logic for using a clone function method. > > > > > >>Nevertheless, as soon as the object is outside > >>a cow_ptr might be sliced. That's reason enough not to allow it. > > > > > > I'm not sure what you're referring to here. Can you post an > > example? > > *ptr = *ptr2; Can you please give a more complete example? Which is the smart pointer, here, and exactly what type of pointers?

2 1

[variant] Feature request
by Ion Gaztañaga 08 Jan '06

08 Jan '06

Hi, These days I was trying to use boost::variant to create a read-write lock with many priority policies (reader priority, writer priority, alternating...). Each of this policies need different members (some need one mutex and two condition variables, other two mutexes and one condition variable...). These can be expensive OS resources. Trying to optimize resources I wanted to use boost::variant. The constructor of the read-write lock takes an argument with the wanted policy (just like boost::read_write_mutex) and I need to initialize resources according to this run-time policy. The problem is that I can't directly call the correct constructor, because boost::variant requires a convertible type to possible internal types to call that constructor. What I would propose is the possibility of selecting via integer value which member of boost::variant will be constructed, just like which() returns the index of constructed member. This way, we can efficiently compact members of classes. class MyRWLock { public: enum { r_prioriy, w_prioriy, a_prioriy }; MyRWLock(int run_time_policy); private: struct r_prioriry_members { //... }; struct w_prioriry_members { //... }; struct a_prioriry_members { //... }; //Union of needed members boost::variant<r_prioriry_members, w_prioriry_members, a_prioriry_members> m_data; }; inline MyRWLock::MyRWLock(int run_time_policy) : m_data(/*what do I have to do to select a constructor?*/) { } Since an integer can be a convertible parameter of one variant type constructor, maybe we can use a wrapper holding the integer as variant argument. namespace boost { struct int_selection { explicit int_selection(int selection) : m_selection(selection){} int get_selection const { return m_selection; } private: int m_selection; } } I don't know if this feature is hard to achieve generically (that would require big meta-programming implementation, surely), but this bounded factory-like interface (constructing one of selected types from an integer) would be in my opinion a big win. One alternative is to have the first variant type as a dummy type whose default constructor is trivial and after that use operator=. But that can require dynamic memory (according to variant documentation). Do you see this as an unneeded feature or it's just too hard to implement? Regards, Ion

2 1