- Boost-users - lists.boost.org

shared_ptr / auto_ptr
by Chard 23 Feb '10

23 Feb '10

We've recently been evaluating a move from boost 1.38 to 1.42 [MSVC71], and we had some code that breaks down to the following: [1] struct T {}; [2] std::auto_ptr<T> ap; [3] boost::shared_ptr<T> sp = ap; Line [3] stopped compiling because of the 'explicit' introduced (in shared_ptr.hpp) at line [L] (below). >From smart_ptr/shared_ptr.hpp: [A] template<class Y> [B] explicit shared_ptr(std::auto_ptr<Y> & r): px(r.get()), pn() [C] { [D] Y * tmp = r.get(); [E] pn = boost::detail::shared_count(r); [F] boost::detail::sp_enable_shared_from_this( this, tmp, tmp ); [G] } [H] [I]#if !defined( BOOST_NO_SFINAE ) && !defined( BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION ) [J] [K] template<class Ap> [L] explicit shared_ptr( Ap r, typename boost::detail::sp_enable_if_auto_ptr<Ap, int>::type = 0 ): px( r.get() ), pn() [M] { [N] typename Ap::element_type * tmp = r.get(); [O] pn = boost::detail::shared_count( r ); [P] boost::detail::sp_enable_shared_from_this( this, tmp, tmp ); [Q] } The fix is trivial, but what I am curious about is: - the 'explicit' appears to have been removed at version 1.35 (i.e. it was there at 1.34) and then re-introduced at 1.39. Is there some history to this? and - it looks like our code was falling into the second overload with 1.38 (the first overload was always explicit); with a fix it will now select the first overload, so for what case does the second overload now exist? --

4 3

atomic_count overflow/underflow behaviour
by Narcoleptic Electron 23 Feb '10

23 Feb '10

What is the behaviour of boost::detail::atomic_count overflow? I realize that overflow for a signed long is undefined, but it is possible that each platform-specific atomic increment operator handles overflow in some documented way, which in sum would constitute a defined behaviour for atomic_count overflow. Documenting this behaviour (along with that of underflow, which is presumably the same) in the atomic_count documentation would be extremely helpful.

1 1

[BGL] Very slow adjacency_list deallocation/reallocation for debug builds
by T MacAdam 23 Feb '10

23 Feb '10

Does anyone know a way to speed up adjacency_list deallocation for debug builds? I've done some timing tests (see code below - should build as-is in VC9) and found the adjacency_list creates quite quickly, but is terrible during deallocation (actually, it can be as bad on creation of the graph, too, if you are building up the graph incrementally using a vecS for your vertex storage that requires reallocation as the size grows). In a release build, everything is blazing fast, but it's so slow when linked against the debug CRT that I essentially cannot debug my app. And the graph doesn't have to be too big (see code below, 50K results in a deallocation time of 171 sec if I use vecS and 268 sec if I use listS, and that's on a quite good workstation; my production graphs are > 100K vertices). BTW, I'm building with Visual C++ 9 (2008). #include <time.h> #include <iostream> #include <algorithm> #include <boost/graph/adjacency_list.hpp> using namespace std; int _tmain(int argc, _TCHAR* argv[]) { const int size = 50000; //typedef boost::adjacency_list< boost::listS, boost::vecS, boost::bidirectionalS > MyGraphType; // try storing vertices in vector<> typedef boost::adjacency_list< boost::listS, boost::listS, boost::bidirectionalS > MyGraphType; // try storing vertices in list<> typedef boost::graph_traits< MyGraphType >::vertex_descriptor MyVertexDescriptor; typedef boost::graph_traits< MyGraphType >::edge_descriptor MyEdgeDescriptor; MyGraphType *myGraph = new MyGraphType(); vector<MyVertexDescriptor> vertices(size); { cout << "Adding vertices...Started:" << endl; clock_t m_clockStart = ::clock(); for( int i = 0; i < size; ++i ) vertices[i] = boost::add_vertex(*myGraph); cout << "Adding vertices...Done: " << (double)((::clock()-m_clockStart)/CLOCKS_PER_SEC) << " seconds" << endl; } { cout << "Adding edges...Started:" << endl; clock_t m_clockStart = ::clock(); for( int i = 0; i < size-1; ++i ) boost::add_edge( vertices[i+1], vertices[i], *myGraph ); cout << "Adding edges...Done: " << (double)((::clock()-m_clockStart)/CLOCKS_PER_SEC) << " seconds" << endl; } { cout << "Deallocating graph...Started:" << endl; clock_t m_clockStart = ::clock(); delete myGraph; cout << "Deallocating graph...Done: " << (double)((::clock()-m_clockStart)/CLOCKS_PER_SEC) << " seconds" << endl; } return 0; } __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/

3 2

Memory Leak with ASIO SSL examples on Linux in Boost 1.40
by Madhan Kanagavel 23 Feb '10

23 Feb '10

Hello, We have been running a Boost ASIO 1.40 based server successfully for a while, handling hundreds of connections without any issues. But we recently saw some unusual memory usage and started digging into it a bit. We use Asynchronous IO with SSL. We are seeing that in the server side every time a connection occurs some memory is being used up and never getting really freed after the connection goes away. We use Resident Memory value of the server to measure memory usage of the server process. This occurs only in Linux, works fine under Windows. This is easy to reproduce: simply take the server sample and run it under Linux. http://www.boost.org/doc/libs/1_37_0/doc/html/boost_asio/example/ssl/server… (The only change there being to make SSL verification to none.) For the client side, make a lot of connections: typedef boost::shared_ptr<client> client_ptr; std::vector<client_ptr> clients; for (int idx = 0; idx < 200; idx++) { client_ptr new_client(new client(io_service, ctx, iterator)); clients.push_back(new_client); } At the end of the client test program run, the server would have grown in memory by about 10 MB. If you run the client program again, by another 10 MB. We also ran valgrind on the server side, but nothing significant showed up on where the memory is going. Doing the same with non-SSL sample program works fine, no change in server memory. If you need additional information, please let me know, or if we are making some stupid mistake, any help pointing us in the right direction would be much appreciated. Thanks and Best Regards, M.

3 2

Re: [Boost-users] Memory Leak with ASIO SSL examples on Linux in Boost 1.40
by Madhan Kanagavel 23 Feb '10

23 Feb '10

"Igor R" <boost.lists(a)gmail.com> wrote in message news:cfe0a3cf1002231005h6a49dbc0y5956c9546ab49860@mail.gmail.com... >> We use Asynchronous IO with SSL. >> We are seeing that in the server side every time a connection occurs some >> memory is being used up and never getting really freed after the >> connection goes away. > ASIO SSL relies on openssl, so maybe the problem is there? Try updating > openssl. Thanks for your input, I had been using OpenSSL 0.9.8c and I updated to OpenSSL 0.9.8h and I still see the same issue. There is no change in behavior. Is there anything else I could try?

2 1

Re: [Boost-users] [serialization] Polymorphic serialization withpolymorphic archives problem...
by Bogdan 23 Feb '10

23 Feb '10

I agree, the DLL case seems to be the most useful. I double-checked and the test that comes closest to this scenario (test_dll_exported.vcproj) is using template-based definitions of the serialization functions. The test project illustrating my question is very similar to test_dll_exported.vcproj but it doesn't use any template definition. Please find it attached to this message. Just let me know if there is any other way I can help. Thank you, Bogdan > > Thank you for your reply. The serialization functions are not inline: > > their bodies are defined inside the DLL. > > > > I did the following experiments: > > > > - I skipped manually the registration exception in the debugger and > > it turns out that all the serialized classes have their serializers > > registered twice. - if in the main function I do not call > > serialize/deserialize, the program runs ok; I agree with you, the > > program doesn't do anything but it proves that the registration is > > triggered by the actual usage of the serialization functionality and > > not by any eventual inline. > > > > I am under the impression I followed all the directions in the > > documentation and yet I keep hitting that glitch. > > I thought I included demos and tests to implement this very scenario. > Look through the demos/tests and double check this. If there > is a demo/test that works and emulates your situation maybe > we're done. If not, perhaps you might want to modify the > demo/test so it fails and then send it to me. > > Robert Ramey > > > > > Thank you, > > > > Bogdan > > > > PS. > > As for the case where boost serialization links as a static inside a > > user DLL, it fails, indeed, due to the compile stripping out code. Is > > there a workaround for this you would suggest? > > The serialization library uses boost/serialization/force_include.hpp to > implement this. This might be made to work but is a compiler > dependent hack. I would prefer we get to the bottom of why > the DLL situation doesn't work as I would expect. > > Robert Ramey >

1 0

Re: [Boost-users] fusion result_of::at<Seq, N>::type doesn't return the type I expect
by Hicham Mouline 23 Feb '10

23 Feb '10

-----Original Message----- From: "Hicham Mouline" [hicham(a)mouline.org] Date: 23/02/2010 02:53 PM To: boost-users(a)lists.boost.org Subject: Re: fusion result_of::at<Seq, N>::type doesn't return the type I expect std::cout<< boost::is_same< t0, double >::value <<std::endl; I am certain I am missing something obvious, rds, ----------------- I needed to compare t0 with double& and not double, rds,

2 1

(Serialization) Serialization for enable_shared_from_this
by Clarke, Carus V 23 Feb '10

23 Feb '10

Alexander Gutenev wrote a message concerning this problem on Dec. 14, and I have a similar problem, also with Boost 1.41 and 1.42. After spending some time looking at this, the problem seems to be caused by creating the shared_ptr as a shared_ptr to void. This causes the shared_ptr constructor that does not support enabled_shared_from_this to be called. I think that this is because the constructor is called from a place (shared_ptr_helper.cpp) where the class derived from enable_shared_from_this is not complete. I was able to work around the problem by moving the construction of the shared_ptr back to the shared_ptr_helper::reset function template. It would really help if this problem could be fixed. It is likely that Alexander and I aren't the only ones that rely on this capability. Thank you, Carus V. (Bud) Clarke carus.v.clarke(a)boeing.com

2 1

Re: [Boost-users] [serialization] Polymorphic serialization with polymorphic archives problem...
by Bogdan 23 Feb '10

23 Feb '10

> Bogdan wrote: > > > 3. serialization files in a separate dll. Both the main executable and > > my dll link with the dll version of the serialization library: > > > > main.exe > > my_serialization.dll > > boost_serialization.dll > > > > my_serialization.dll > > boost_serialization.dll > > > > Builds OK but FAILS at runtime , at run time I get a C++ exception > > BEFORE main() in basic_serializer_map.cpp around the line 48: > > > > 'archive_exception::multiple_code_instantiation with the message "code > > instantiated in more than one module - polymorphic_base"' > > This would indicate that the serialization for polymorphic_base is included in BOTH the > mainline and the DLL. Check that the serialization function is NOT an inline definition. > the polymorphic_base.cpp should only be needed when compiling the DLL. > > option 1 > > include serialization definition for polymorphic_base in my_serialization.dll > > option 2 > > include serialization definition for polymorphic_base in it's own dll. > > > > 4. serialization files in a separate dll. Both the main executable and > > my dll link with the static version of the serialization library: > > > > main.exe > > my_serialization.dll > > boost_serialization.lib > > > > my_serialization.dll > > boost_serialization.lib > > > > Builds OK but FAILS at runtime while trying to serialize with the > > following exception thrown in oserializer.hpp(line 424):struct > > polymorphic::save(): > > > > 'unregistered void cast class polymorphic_derived1<-polymorphic_base > > in function 'int __cdecl main(int,char *[])'' > > This is probably failing due to the compiler stripping out code not explicitly referred to. > Since it's not referrred to, the linking doesn't include it from the library. ==================================================== Hello Robert, Thank you for your reply. The serialization functions are not inline: their bodies are defined inside the DLL. I did the following experiments: - I skipped manually the registration exception in the debugger and it turns out that all the serialized classes have their serializers registered twice. - if in the main function I do not call serialize/deserialize, the program runs ok; I agree with you, the program doesn't do anything but it proves that the registration is triggered by the actual usage of the serialization functionality and not by any eventual inline. I am under the impression I followed all the directions in the documentation and yet I keep hitting that glitch. Thank you, Bogdan PS. As for the case where boost serialization links as a static inside a user DLL, it fails, indeed, due to the compile stripping out code. Is there a workaround for this you would suggest?

2 1

flyweight: lazy initialization
by Johannes Brunen 23 Feb '10

23 Feb '10

Hello, Is it possible to initialize a flyweight lazy or better on user request? I have the problem that I have a custom allocator that is not ready to run before main. Currently, the flyweight initialization is performed on init of the fleiweight_core static_initilaizer member. This scheme does outrule the usage of the flyweight utility in my application. Any help would be appreciated. Best, Johannes ____________ Virus checked by G DATA AntiVirusKit Version: AVF 19.736 from 21.02.2010 Virus news: www.antiviruslab.com

2 1