- Boost - lists.boost.org

[python] bogus backward-compatibility code
by Ulrich Eckhardt 26 Dec '08

26 Dec '08

Hi! I'm looking at versions up to at least 1.37, and in python/detail/config.hpp, I find found some code that is currently in my way, because I'm not sure what it should do. I'm talking about the following few lines: // backwards compatibility: #ifdef BOOST_PYTHON_STATIC_LIB # define BOOST_PYTHON_STATIC_LINK # elif !defined(BOOST_PYTHON_DYNAMIC_LIB) # define BOOST_PYTHON_DYNAMIC_LIB #endif Notes here: 1. The first macro, BOOST_PYTHON_STATIC_LIB, is undocumented and probably (I'm guessing) an old spelling of BOOST_PYTHON_STATIC_LINK. It is used in some Jamfile.v2s, probably to link with or build a static library. On first view, it's odd that the build system depends on backward code. 2. On second look, you see that BOOST_PYTHON_STATIC_LINK is completely unused and similarly undocumented, in any case defining it is not necessary for Boost itself. 3. The macro BOOST_PYTHON_DYNAMIC_LIB is also of questionable use. It is used in that file to setup auto linking and symbol visibility for a dynamic library, but otherwise it is unused. Actually, compare that to config/user.hpp, which says that you should use either of BOOST_{PYTHON,ALL}_DYN_LINK to get dynamic linking. 4. Speaking about config/user.hpp, there is no documented way to specify static linking. I think some libraries use e.g. the _DLL macro on MS' compiler to default to dynamic linking and otherwise assume static linking. Boost.Python instead assumes dynamic linking when nothing is specified and the only way to get static linking is by defining an otherwise undocumented macro. Suggested resolution: 1. Remove above quoted lines. They have been there since 2002 (SVN revisions 12083, 12146, 13462), and any code relying on undocumented backward compat code for such a long time is broken anyway (yes, sadly, that includes Boost itself sadly). 2. Replace checks for BOOST_PYTHON_DYNAMIC_LIB with checks for the macros documented in config/user.hpp. 3. Document BOOST_{ALL,foo}_STATIC_LINK as guaranteed way to get statically linked libraries in config/user.hpp. 4. Maybe introduce a header config/guess_linkage.hpp which will define BOOST_ALL_STATIC_LINK or BOOST_ALL_DYNAMIC_LINK based on heuristics like e.g. _DLL under win32, unless either of these two is already defined. I think that such heuristics already are in place in some libraries, but they should actually be central. I'd start off with 1-3 and then see what breaks. Step 4 will require that checks are changed so that they look like this: if (ALL_DYN_LINK|FOO_DYN_LINK) && !FOO_STATIC_LINK // use dynamic linking else // use static linking endif instead of just like this: if (ALL_DYN_LINK|FOO_DYN_LINK) // use dynamic linking else // use static linking endif so that the detected default does not override an explicitly set linkage. Comments anyone? Uli

1 0

Re: [boost] [Boost-users] [review][constrained_value] Review of Constrained Value Library begins today
by Mika Heiskanen 25 Dec '08

25 Dec '08

Mathias Gaunard wrote: > Mika Heiskanen wrote: > >> If the value must be checked beforehand, why bother using a constrained >> type at all? > > Because it performs checking in debug mode to make sure the invariant is > indeed true. I do not believe boost should accept a library which would only work in debug mode. I believe boost is mostly about runtime libraries, not about debugging aids. --> Mika Heiskanen

7 27

[shared_ptr] A smarter smart pointer proposal for dynamic libraries
by J.D. Herron 25 Dec '08

25 Dec '08

I have a suggestion for the shared pointer implementation to overcome a severe limitation it has currently regarding dynamically unloaded libraries. I posted a little while back regarding this problem which is illustrated with the following example from a Microsoft Windows environment. I have a simple factory interface like so: class Factory { public: virtual shared_ptr<int> GetIntSharedPtr() = 0; virtual int * GetIntRawPtr() = 0; }; I implement a factory DLL to provide one of these factories that has an exported function GetFactory() like so: /// implementation of the Factory interface class TestFactory : public Factory { public: virtual shared_ptr<int> GetIntSharedPtr() { return shared_ptr<int>( new int(5) ); } virtual int * GetIntRawPtr() { return new int(0); } }; /// Library instance of the factory implementation TestFactory g_Factory; /// Exported function to return the factory for this library _declspec(dllexport) extern "C" Factory & GetFactory() { return g_Factory; } This is compiled into a library named "TestFactory.dll". Now I create a simple command line application that does the following: /// Typedefinition for for the GetFactory exported function typedef Factory & (_cdecl * GetFactory)(); int main() { // dynamically load the TestFactory library HMODULE hFactoryDll = ::LoadLibrary( "TestFactory.dll" ); // get the GetFactory() interface from the loaded library GetFactory pfnGetFactory = ::GetProcAddress( hFactoryDll, "GetFactory" ); // Acquire the factory object Factory & factory = pfnGetFactory(); // Call the factory interfaces to get dynamically allocated integers int * pRawInt = factory.GetIntRawPtr(); shared_ptr<int> spInt = factory.GetIntSharedPtr(); // everything is fine so far, now unload the factory library ::FreeLibrary( hFactoryDll ); // deallocating the raw pointer recieved from the factory works just fine delete pRawInt; // THIS WORKS! // However due to the reasons outlined below, releasing the shared_ptr causes // an access violation spInt.reset() // THIS CRASHES! } The basic problem is that the shared_ptr implementation uses virtual functions in the sp_counted_base class that gets generated in the factory dll since it is a template instantiation and once that factory dll is unloaded the virtual function tables for all shared_ptrs it generated are now garbage. In my opinion the virtual function implementation in the template is an unnecessary design flaw that creates this limitation. I also think the reference counter just simply does too much. I would propose an alternative design that eliminated the use of virtual functions in template generated base classes and let the outer smart pointer class handle the deallocation chores and make the reference counter just a simple reference counter. This could eliminate the limitation illustrated in this simple and very common use case. Ignoring a bunch of stuff right now like custom deallocators, weak references, some basic members like assignment, etc., here is a simple reference counted smart pointer that is able to handle this library unloading example without a problem just as you could do with a raw pointer: /// reference counter THAT ONLY REFERENCE COUNTS AND HAS NO VTABLE class SimpleRefCounter { public: /// Constructor initializes reference count to 0 SimpleRefCounter( long count = 0 ) : m_Count(count) {} /// Increments the reference count and returns it long Increment() { return ::InterlockedIncrement( &m_Count ); } /// Decrements the reference count and returns it long Decrement() { return ::InterlockedDecrement( &m_Count ); } /// Returns the current reference count long Count() const { return m_Count; } private: long m_Count; }; /// Simple smart pointer template that handles the deallocation chores and therefor /// can be used safely across dynamic dll boundaries template < typename _type > class SmarterPtr { public: /// Default constructor creates a null pointer SmarterPtr() : m_pValue( NULL ), m_pRefCounter( NULL ) {} /// Constructor taking an allocated value to manage SmarterPtr( _type * p_pValue ) : m_pValue( p_pValue ) { m_pRefCounter = new SimpleRefCounter( 1 ); } /// Copy constructor SmarterPtr( const SmarterPtr & p_Original ) : m_pValue( p_Original.m_pValue ), m_pRefCounter( p_Original.m_pRefCounter ) { m_pRefCounter->Increment(); } /// Destructor releases ~SmarterPtr() { reset(); } /// Resets the managed pointer to the passed in one releasing the /// currently managed pointer and deallocating if necessary void reset( _type * pNewValue = NULL ) { if ( pNewValue != m_pValue ) { if ( m_pValue && 0 == m_pRefCounter->Decrement() ) { // need to deallocate current value delete m_pValue; delete m_pRefCounter; // ignore weak ref for now m_pValue = NULL; m_pRefCounter = NULL; } if ( pNewValue ) { m_pRefCounter = new SimpleRefCounter( 1 ); m_pValue = pNewValue; } } } private: _type * m_pValue; SimpleRefCounter * m_pRefCounter; }; Again the key is no VTABLE and deallocation handled by the exposed templates. Why shouldn't shared_ptr move to an equivalent model so it can be used across dynamic dll boundaries safely? J.D.

5 8

Is program_options unmaintained?
by Peter Simons 24 Dec '08

24 Dec '08

Hi, a couple of weeks ago, I reported a bug in the program_options library to the author, Vladimir Prus, but received no response. Then I tried reporting the problem on the boost-users mailing list, but didn't receive a response either. Since then, I've seen at least one other poster on the boost-users list wondering about this library, but did not receive a no response either. Does anyone still maintain the program_options library? More generally speaking, what is the procedure if it turns out that a Boost library *is* unmaintained? Take care, Peter

2 4

[test] Floating point comparison update
by Gennadiy Rozental 24 Dec '08

24 Dec '08

Hi, I've checked in 2 changes to the floating point comparison tools. 1. BOOST_CHECK_CLOSE now can compare values of different types: BOOST_CHECK_CLOSE( 2, 2.1, 6 ); // compare and and double BOOST_CHECK_CLOSE( 2.1, 2, 6 ); // compare double and int BOOST_CHECK_CLOSE( 2.1, 2.f, 6 ); // compare double and float 2. Floating point comparison tools now report difference if any: BOOST_CHECK_CLOSE( 2, 2.1, 3 ) will lead to: difference{4.7619%} between 2{2} and 2.1{2.1} exceeds 3% BOOST_CHECK_CLOSE_FRACTION( 2, 2.1, 0.04 ) will lead to: difference{0.047619} between 2{2} and 2.1{2.1} exceeds 0.04 Any comments appreciated, Gennadiy

3 2

Re: [boost] [uuid] Interface
by Vladimir Batov 24 Dec '08

24 Dec '08

It seems I did it again. :--( Just noticed that I misread the following excerpt of Scott's email. Apologies and corrections further below. >> Take, for example, a map<string, uuid>. No default constructor means >> that you can't use operator[], First, my preference is to *have* the default constructor -- we disagree on its behavior as I'd like the default constructor to *be part* of the constructors family (constructing a valid object) and you insist on the default constructor being an exception. The latter is not how the language interprets the default constructor. Therefore, me not happy. IMHO that deviation of the meaning from the letter of the language is unacceptible. Second, even if I cannot use operator[], so what? std::fstream has no default constructor. std::list has no operator[], std::vector has no push_front(). That did not stop anyone from using those classes. What the lack of those "features" achieved instead is that it most likely saved a few people from shooting themselves in a foot. Best, V.

3 4

[asio] overlapped_ptr issue
by Sergei Politov 23 Dec '08

23 Dec '08

Hi, I sent the following letter to asio mail list some time ago: ======================================= I have found the following problem with overlapped_ptr. There is complete method in win_iocp_overlapped_ptr: void complete(const boost::system::error_code& ec, std::size_t bytes_transferred) { if (ptr_) { ptr_->io_service_.post_completion(ptr_, 0, 0); ptr_ = 0; } } As you can see, post_completion does not uses arguments of complete. So it notifies handler with invalid values. ======================================= But I did not receive response from Chris. Where should I submit a ticket? Best Regards, Sergei

2 1

Asio AcceptEx failing with error 121 on Windows with multiple network connections
by Stuart A. Malone 23 Dec '08

23 Dec '08

Hi folks, I'm working with the Boost Asio library from Boost 1.37 on Mac and Windows, and have encountered a problem that only occurs on Windows, and only when the computer has multiple network connections (such as both wired ethernet and WiFi). I started with the "HTTP Server" example code for a simple single- threaded server. I'm running the server on address 0.0.0.0 with port number 0 so that it listens on all network interfaces and allows the OS to select the port number. The server works fine on a Mac with multiple network connections. And on Windows, the default (wired ethernet) connection works fine, too. But if I try to connect to the Windows server over the non-default (WiFi) connection, there is about a 20 second pause and the server exits with error 121, "The semaphore timeout period has expired." I've done some poking around under the debugger, and it appears that the origin of this error is the AcceptEx call in the async_accept<> function in win_iocp_socket_service.hpp, line 2129. While this call does not fail directly since it is an asynchronous call, the error code eventually turns up in the accept_operation::do_completion_impl function in win_iocp_socket_service.hpp, line 1908. I don't really know enough about either Boost Asio or Windows networking to figure out much more on my own. Does anyone have an insight into the source of this problem, or suggestions on how I might go about tracking it down further? Best wishes, --Stuart A. Malone Llamagraphics, Inc. Makers of Life Balance personal coaching software http://www.llamagraphics.com/

1 0

[type_traits] patch for gccxml
by Neal Becker 23 Dec '08

23 Dec '08

Please apply this patch to support current gccxml. The issue is that gccxml will claim to be gcc4.3, but it is really based on gcc4.2, and doesn't support the additional intrinsics (__is_enum, in particular). diff -r 13bbd7c5c6d0 boost/type_traits/intrinsics.hpp --- a/boost/type_traits/intrinsics.hpp Mon Dec 01 07:41:09 2008 -0500 +++ b/boost/type_traits/intrinsics.hpp Tue Dec 23 09:15:32 2008 -0500 @@ -126,7 +126,7 @@ # define BOOST_HAS_TYPE_TRAITS_INTRINSICS #endif -#if defined(__GNUC__) && ((__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 3))) +#if defined(__GNUC__) && ((__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 3) && !defined(__GCCXML__))) # include <boost/type_traits/is_same.hpp> # include <boost/type_traits/is_reference.hpp> # include <boost/type_traits/is_volatile.hpp>

2 1

Tests are a mess
by Gennaro Prota 23 Dec '08

23 Dec '08

Few questions: * BGD-Ubuntu is among tested platforms for release, but not for trunk. How is a poor fellow supposed to test on trunk first? * Same as above for BGD-Windows, with the fellow getting poorer and poorer * Are RW_WinXP_VC and RW_WinXP_VCrtl the same? * Can anyone please have a look at the trunk failures for HP-UX_ia64_aCC? For a bunch of libraries I've looked at it gives an Unsatisfied symbol "boost::exception_detail::refcount_ptr<..." What's that? Compiler bug, misconfiguration, phase of the moon? Sorry, but if this is the status quo I'm just going to merge to branches/release and be done with it. -- Genny

11 44