- Boost - lists.boost.org

Does Boost has an utility to replace all OLD Keys with NEW one for MultiMap/Map?
by Tushar Chowdhury 08 May '09

08 May '09

Hi Guys, As of now I failed to get such an algo. I've come up with an proposed solution. Please verify: namespace Boost{ template <typename CONTAINER> void replace_key(CONTAINER& container, const typename CONTAINER::key_type& oldKey, const typename CONTAINER::key_type& newKey) { typename CONTAINER::iterator begin(container.find(oldKey)); for(;;){ if(begin != container.end()){ container.insert(typename CONTAINER::value_type(newKey, begin->second)); container.erase(begin++); begin = container.find(oldKey); } else{ return; } } } } make sense?

6 11

[test] Automatic registration of tests created with BOOST_PARAM_TEST_CASE
by JS 08 May '09

08 May '09

Hi, I want to create a test that a) runs the same testing function with different sets of input data AND b) registers automatically Obviously I can use BOOST_PARAM_TEST_CASE macro for a), but how do I achieve b) at the same time? I've been fighting with the problem for many hours and I have no idea how to do it. Unfortunately the documentation is very cryptic. Here's what I came up with so far: boost-main.cpp : #define BOOST_TEST_DYN_LINK #define BOOST_TEST_MAIN #define BOOST_TEST_MODULE My Master Test Suite #include <boost/test/unit_test.hpp> testSomeFunctions.cpp : using namespace boost::unit_test; class DataSet { public : DataSet( /* params */ ) { /* setup single data set */ } ~DataSet( ) { /* teardown single data set */ } /* some fields */ } class DataProvider { public : DataProvider() { dataSet.push_back( new DataSet( /* params */ ) ); /* add more if necessary */ } ~DataProvider() { /* free memory*/ } std::vector<DataSet*> dataSet; } void testMethod( DataSet* data ) { /* do something with method that's being tested. Use data somehow */ BOOST_CHECK( /* assertion */ ); } BOOST_AUTO_TEST_CASE( TestName ) { DataProvider dataProvider; test_suite* test = BOOST_TEST_SUITE( "I don't think the name matters" ); test->add( BOOST_PARAM_TEST_CASE( &testMethod, dataProvider.dataSet.begin(), dataProvider.dataSet.end() ) ); framework::run( test ); } However this is not correct since test cases created with BOOST_PARAM_TEST_CASE are not registered in the master test suite. If one of the tests fails I get the following log : Running 1 test case... ../test/functions/testSomeFunctions.cpp(67): error in "testMethod": check data->a == data->b failed [2 != 3] *** No errors detected I tried replacing "framework::run( test );" with "framework::master_test_suite().add( test );" but that doesn't work at all (log says that no errors were detected, while there should be one test that fails). I also tried something like this : BOOST_AUTO_TEST_CASE( ActivationFunctionTest ) { DataProvider dataProvider; framework::master_test_suite().add( BOOST_PARAM_TEST_CASE( &testMethod, dataProvider.dataSet.begin(), dataProvider.dataSet.end() ) ); } but the result is the same (No errors detected). What should I do? Jan

2 1

[spirit2] conflict with asio header
by Michael Caisse 07 May '09

07 May '09

I'm not certain if this is an asio issue or spirit2 issue (or user error). I checked Spirit out from the trunk and placed it into a 1.37 boost tree. I'm running gcc 4.3.2. Creating file foo.cpp with the following: --------------- #include <boost/asio.hpp> #include <boost/spirit/include/qi.hpp> --------------- Produces a string of errors including this snippet: from ../src/foo.cpp:3: ../../../library/vendor/boost/boost/proto/make_expr.hpp: At global scope: ../../../library/vendor/boost/boost/proto/make_expr.hpp:935: error: expected nested-name-specifier before numeric constant ../../../library/vendor/boost/boost/proto/make_expr.hpp:935: error: expected â>â before numeric constant ../../../library/vendor/boost/boost/proto/make_expr.hpp:940: error: type/value mismatch at argument 3 in template parameter list for âtemplate<class Tag, class DomainOrA0, class A0, class A1, class A2, class A3, class A4, class Void> struct boost::proto::result_of::make_exprâ ../../../library/vendor/boost/boost/proto/make_expr.hpp:940: error: expected a type, got â0â ../../../library/vendor/boost/boost/proto/make_expr.hpp:940: error: expected initializer before âconstâ Swapping the include order resolves the error. Should I enter a ticket? Michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

3 2

Submitting a patch to the bug/ticket list
by Juan Antonio Zaratiegui Vallecillo, a.k.a. Zara 07 May '09

07 May '09

Well, I have submitted a patch for dynamic_bitset.hpp, and I have seen that the ticket is now 'closed' and 'fixed'. I don know if it is an automatic response from the system, or if I have done something wrong (like, for instance, clicking where I should not click), and in such case I should reopen the ticket. Please, tell me which is the case and what should I do, because I am not happy leaving it this way. BTW, the bug owner is listed as gennaro_prota. Should I try to contact him directly? TIA Zara

2 3

gcc-4.4.0 and boost::optional is giving (spurious?) strict-aliasing warnings
by Brad Spencer 07 May '09

07 May '09

Before I get to the details, let me start by saying that I suspect that these warnings are probably spurious. But, before I go and start asking the compiler folks if they are bugs, I'd like to check here first. If you take unmodified boost-1.38.0 and try to use boost::optional with gcc-4.4.0 -Wall -O3, you seem to get warnings about strict-aliasing rules being broken. If boost::optional (and boost::function) are really broken, then we're probably in trouble :) test.cc: #include <boost/optional.hpp> boost::optional<int> x; int func() { return *x; } On x86_64-unknown-linux-gnu: $ /opt/gcc-4.4.0/bin/g++ -Wall -O3 -I. -c -o test.o test.cc test.cc: In function ‘int func()’: test.cc:5: warning: dereferencing pointer ‘<anonymous>’ does break strict-aliasing rules ./boost/optional/optional.hpp:594: note: initialized from here I have seen some similar issues with boost::bind and boost::function, but I haven't isolated them down to something this simple yet. I figured I'd start by asking about this. So, is it safe to presume that boost::optional is not really breaking the strict aliasing rules? (It's not immediately obvious.) If so, then I can ask the gcc folks about this. Thanks! -- ---------------------------------------------------------- Brad Spencer - spencer(a)starscale.com - www.starscale.com

4 3

[thread] on_tls_prepare in win32\tss_pe.cpp incompatible with static linkage to a /clr object
by Matthew Chambers 06 May '09

06 May '09

I'm very interested in being able to have a native C++ executable which makes use of boost's TSS and also be able to wrap .NET modules with C++/CLI (i.e. /clr). And I much prefer it to be statically linked. The C++/CLI wrappers work fine when they are dynamically linked, but they cause a runtime initialization error (0xc000007b) whenever they are connected in only static links. It doesn't matter whether the host executable is compiled with /clr or not - somehow the MSVC linker knows to add some CLR initialization voodoo to the PE header whenever a static link to a /clr-enabled object is made. And that PE header voodoo seems to be incompatible with some of boost::thread's own brand of PE header voodoo which appears to be intended to provide TLS support for Windows. But as far as I can tell, I was able to get TLS working with MSVC9 even after commenting out the on_tls_prepare lines in tss_pe.cpp - commenting out the other lines wasn't necessary: > #if (_MSC_VER >= 1400) > //#pragma section(".CRT$XIU",long,read) > #pragma section(".CRT$XCU",long,read) > #pragma section(".CRT$XTU",long,read) > #pragma section(".CRT$XLC",long,read) > static __declspec(allocate(".CRT$XLC")) _TLSCB > __xl_ca=on_tls_callback; > // static __declspec(allocate(".CRT$XIU"))_PVFV p_tls_prepare = > on_tls_prepare; > static __declspec(allocate(".CRT$XCU"))_PVFV p_process_init = > on_process_init; > static __declspec(allocate(".CRT$XTU"))_PVFV p_process_term = > on_process_term; > #else I put together a test case that I'm pretty sure shows that TLS still works without that function. At the very least, can there be some preprocessor define to manually disable it for CLR compatibility? Or perhaps there is a way to adjust this voodoo to be compatible with the CLR initialization? I'm hosting the test case at: http://fenchurch.mc.vanderbilt.edu/files/TLS_CLR_Test.7z It includes a main function which runs a test of the TSS semantics, and a CLR class which tests console output via C++/CLI. I included binaries and the boost_thread.lib files for both the broken and "fixed" versions of tss_pe.cpp. Thanks, Matt Chambers

2 2

[smart_ptr] boost::auto_ptr?
by Preston A. Elder 06 May '09

06 May '09

I was wondering if the maintainer of the smart pointers could create an analogue to auto_ptr in the boost namespace. Specificlly to allow the addition of a deallocator like that which exists in shared_ptr? Right now, none of std::auto_ptr, shared_ptr or scoped_ptr will quite fit this niche. - std::auto_ptr - always uses delete ptr; There not only no standard way to supply an allocator, but also no way to specify a one-off deleter. - scoped_ptr - is noncopyable (by design), I want to use it like an auto_ptr. - shared_ptr - has more overhead for thread safety and multiple usage concerns than is desired in this circumstance. Not to mention that it doesn't function like auto_ptr ('nullifying' after operator=). Quite simply, I'd love to do: boost::auto_ptr<MyClass> obj(ptr, deleter); Just like I can with boost::shared_ptr, and use it like regular std::auto_ptr. Can someone add this to boost? Pretty please? :) Incidentlly, I have another question, about enable_shared_from_this. Will this play well with a regular shared_ptr? For example - say I have MyClass and MyOtherClass. MyClass is going to invoke a function on MyOtherClass that will cause MyOtherClass to store the shared_ptr. For example: class MyClass { public: void foo(MyOtherClass &moc) const { moc.foo(shared_from_this()); } }; class MyOtherClass { shared_ptr<MyClass> mc; public: void foo(const boost::shared_ptr<MyClass> &in) { mc = in; } }; If I did: shared_ptr<MyClass> mc(new MyClass); MyOtherClass moc; mc->foo(moc); Ignoring the abserdity of the example (obviously real-life situations would be much more complex), would the mc and moc.mc shared ptr's be in sync? would they play nice together? or would there be chaos and destruction? What if I instead did: MyClass *tmp = new MyClass; shared_ptr<MyClass> mc(tmp->shared_from_this()); Would that fix the above if the above is a problem? I am curious, because right now, I have several instances where I am making constructors private, adding a weak_ptr to a class and adding a static create() function that takes the constructor arguments. Then my create() function will construct the object, putting it in a shared_ptr, then initialize the weak_ptr from the newly created shared_ptr, and then return the shared_ptr - all of this is quite cumbersome. Thanks, PreZ :)

1 1

[aligned storage] support for empty storage
by Thorsten Ottosen 06 May '09

06 May '09

Hi all, Currently the following fails: typedef boost::aligned_storage< 0, 4u > storage; storage s; because this will try to create an empty array. Does anybody have anything against adding the following specialization: template< std::size_t alignment_ > struct aligned_storage_imp<0u,alignment_> { /* intentionally empty */ }; Also, I would like to derive from aligned_storage_imp to get the EBO: template < std::size_t size_ , std::size_t alignment_ = std::size_t(-1) > class aligned_storage : private detail::aligned_storage::aligned_storage_imp<size_, alignment_> { ... } The above changes enable the following program typedef boost::aligned_storage< 0, 4u > storage; struct simple : storage { int i; }; #include <iostream> int main() { std::cout << sizeof(storage) << " " << sizeof(simple); } to output "1 4" instead of "1 8" on gcc. In case your are wondering, then I need this functionality in boost::auto_buffer to get rid of the extra word when the stack-buffer is empty (thus making auto_buffer as small as vector). Comments? -Thorsten

2 4

BOOST_ASSERT_IF() [again]
by Thorsten Ottosen 06 May '09

06 May '09

Hi Everyone, Does anyone oppose that I add this macro to supplement BOOST_ASSERT()? It's defined simply as #define BOOST_ASSERT_IF(IF,X) BOOST_ASSERT( (!(IF)) || (X) ) I think it renders assertions somewhat easier to read. -Thorsten

3 3

inline specifier within in class definition
by Mateusz Loskot 05 May '09

05 May '09

Hi, Could anyone explain why some static member functions defined within class definitions are specified with inline keyword? For instance, in boos/serialization/export.hpp template <class Archive, class Serializable> struct export_impl { ... inline static void enable_load(mpl::false_) {} inline static void enable_save(mpl::false_) {} }; AFAIU what the C++ Standard says in chapter "9.3 Member functions", it should be enough to define a member function in its class definition, "in which case it is an inline member function". On the other side, the standard also uses this technique, for instance in example presented in "18.2.1.5 numeric_limits specializations". I'm having problem with catching what's the rationale of using extra inline specifier. I was trying to find answer in the guidelines, but it seems it isn't explained. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

6 10