- Boost - lists.boost.org

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

Reviewer needed for a C++ committee paper candidate
by joaquin＠tid.es 05 May '09

05 May '09

Hello, My excuses is this is slightly OT, but I think it touches with issues definitely of the interest of the Boost community. I'd like to send a paper to the C++ committe, a revision of the already sent http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2009/n2820.pdf and would appreciate if some volunteer with interest in and knowledge on the subject matter can review it. If you're such a volunteer please contact me privately and I'll send you the doc. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Boost.Python def and member function overloads
by Matt Calabrese 05 May '09

05 May '09

I attended Troy Straszheim's Icefishing for Neutrinos Boostcon session today, which was a great talk on Boost.Serialization and Boost.Python in a very interesting context. I have not worked with Boost.Python in practice, having only skimmed the documentation, but was amazed at just how powerful and easy to use it is. However, in his examples, he included exposing classes from C++ that have member functions with multiple overloads and noted that it is somewhat cumbersome due to the fact that you have to explicitly cast your member function pointers when calling .def. For a type "your_type" with a member function "foo" having two overloads, one that takes an int, and another that takes an int and a float, the current syntax comes down to something along the lines of: /*class_ specification here */ .def( "foo", static_cast< void (your_type::*)(int) >(&your_type::foo)) .def( "foo", static_cast< void (your_type::*)(int, float) >(&your_type::foo)) ; Disambiguation is obviously necessary here, but I wonder if it could be handled in a much simpler way such as to avoid explicitly casting or even the explicit use of member function pointer types at all. I propose doing this by allowing users to explicitly pass in a non-member function type as a template argument to def, using a metafunction to translate that type to the appropriate member function type, and having that calculated type be the 2nd parameter type of the function. The suggested syntax would be something along the lines of: /*class_ specification here */ .def< void(int) >( "foo", &your_type::foo ) .def< void(int,float) >( "foo", &your_type::foo ) ; which I feel would be a significant simplification of use and should not be difficult at all to implement (just detect if the first template argument to def is a function type and if so do the appropriate transformation to yield the 2nd function parameter type, otherwise have it work like existing definitions). Would this be a feature that people find useful and be worth pursuing? -- -Matt Calabrese

2 1

[thread] boost::shared_mutex vs. pthread_rwlock_unlock
by Rush Manbert 05 May '09

05 May '09

I am replacing a pthread threading implementation with a boost threads implementation so I can use the code on Windows. There is a ReadWriteMutex class that has the following declaration: class ReadWriteMutex { public: ReadWriteMutex(); virtual ~ReadWriteMutex() {} // these get the lock and block until it is done successfully virtual void acquireRead() const; virtual void acquireWrite() const; // these attempt to get the lock, returning false immediately if they fail virtual bool attemptRead() const; virtual bool attemptWrite() const; // this releases both read and write locks virtual void release() const; private: class impl; boost::shared_ptr<impl> impl_; }; Note the release() method that works for a thread that holds either the read or write lock. My implementation uses boost::shared_mutex. acquireRead calls lock_shared(), acquireWrite calls lock(), attemptRead calls try_lock_shared(), attemptWrite calls try_lock, and release calls ??????? AFAICT there is no equivalent to the pthread_rwlock_unlock() call that the original version of release() called. Am I missing something? Thanks, Rush

2 1