- Boost-users - lists.preview.boost.org

boost and memory allocations (signals and others)
by Frank Maddin 16 Dec '04

16 Dec '04

We've been thinking about using certain boost functionality on a project. We were trying to keep the number of allocations down. An engineer did some testing on signals and their usage of memory and found that there was a surprising number of allocation related things were happening. Even sending a signal did allocation ops. If developers want to reduce allocation overhead, do they use memory pools or some other solution? Is there a pattern of large numbers of small allocations across the lib? For things like the boost's smart pointers also? Below is a description of the test. Thanks, -fm ------------ Memory Usage I ran a simple test to see how much memory is being used struct Hello { void operator (int year) { printf("Year = %d\n",year); } }; void Test () { Hello hello; boost::signal< void(int) > sig; sig.connect( hello ); sig( 1968 ); } Note: I used _CrtSetAllocHook to monitor the memory usage... Results: sizeof( sig ) = 24 bytes but the default constructor does a surprising amount of dynamic allocation (for an empty list) calls malloc or free 51 times allocates 277 bytes in 13 blocks (not including heap overhead) so the actual size is more like 24 + 277 + 13*8 = 405 byes a call to connect does 26 alloc-operations... resulting in 133 bytes in 8 blocks a call to send a signal does 78 alloc-operations... resulting in 0 bytes in 0 blocks ... My tests were debug builds... but I looked at the calls and the library just calls new a lot... there seems to be a pattern of having empty wrapper classes where the constructor dynamically allocates the actual implementation...

3 2

Tuple access on Solaris
by darren.gilbert＠ubs.com 16 Dec '04

16 Dec '04

Hello, I was using the boost tuples library (from boost 1.31) to create a cache key. However, the Solaris compiler (SUNWspro v6.2.p1) complained when I tried to access the last element in the tuple. My class looked something like this: typedef enum result_type_id { ... } ResultTypeID; class ParamStateKey; class Cache { typedef boost::tuple<ParamStateKey, ResultTypeID, int, int, int> key_type; // cache implementation ... // some helper functions defined to hide the boost::tuple interface static ParamStateKey &GetState(key_type &k) { return boost::tuples::get<0>(k); } static ResultTypeID &GetGreek(key_type &k) { return boost::tuples::get<1>(k); } static int &GetProduct(key_type &k) { return boost::tuples::get<2>(k); } static int &GetSubpage(key_type &k) { return boost::tuples::get<3>(k); } static int &GetBucket(key_type &k) { return boost::tuples::get<4>(k); } static key_type MakeKey(const ParamStateKey &psk, ResultTypeID r, int p1, int p2, int bkt) { return boost::tuples::make_tuple(psk, r, p1, p2, bkt); } }; The solaris compiler complained whenever I tried to call Cache::GetBucket() with the following error: "../../../../incl/3rd/boost/tuple/detail/tuple_basic.hpp", line 105: Error: Could not find a match for boost::tuples::detail::get_class<0>::get<boost::tuples::detail::get_class<0>::RET, boost::tuples::detail::get_class<0>::HT, boost::tuples::detail::get_class<0>::TT>(boost::tuples::cons<int, boost::tuples::null_type>). "../../../../incl/3rd/boost/tuple/detail/tuple_basic.hpp", line 105: Where: While instantiating "static boost::tuples::detail::get_class<1>::get<int&, int, boost::tuples::cons<int, boost::tuples::null_type>>(boost::tuples::cons<int, boost::tuples::cons<int, boost::tuples::null_type>>&)". "../../../../incl/3rd/boost/tuple/detail/tuple_basic.hpp", line 105: Where: Instantiated from non-template code. Firstly, I have no way of deciphering that error message. Through trial and error, I found that removing the GetBucket() calls solved the problem. However, I needed these calls. I reasoned that since the other helper functions worked, it was a problem accessing the last element of the tuple. So I created a dummy entry in the tuple and redefined my typedef: typedef boost::tuple<ParamStateKey, ResultTypeID, int, int, int, int> key_type; This work-around is fine, so this is not an urgent problem. But it seems like this should not be necessary. ________________________________________ Darren Gilbert Associate Director UBS - Equities Quantitative Strategies Phone: +1 (312) 525-5766 Stein's law: "When a trend cannot continue it will stop." -- Herb Stein, Chairman of the Council of Economic Advisors under Nixon Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.

1 0

a simple question from a green hand
by Gump Xu 16 Dec '04

16 Dec '04

Hi, there. I am a new user of Boost lib. I have a simple question about installation. I've download and unpacked boost-1.32.0 to my Linux box. When I followed the instruction in "Get Started" to install Boost, I found there was no such a "bjam" binary file in my ~/boost_1_32_0 directory. Can anybody help me out? Thank you.

3 2

scoped_ptr has no release function
by gast128 16 Dec '04

16 Dec '04

Dear all, Probably there will be a good rationale for this, but the scoped_ptr has no release fct. No we have to use the auto_ptr, with all its drawbacks. Does anyone know the reason for this? Wkr, me

5 5

BGL + VC7: no bundled properties because of BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
by Dan Dimerman 16 Dec '04

16 Dec '04

Hello, Failing to do it by myself, I ask for the group's help to fully understand why I can't use BGL's bundled properties with MS VC7. I traced the impediment to the fact that in the configuration header "visualc.hpp" the constant BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION is #defined. This, further on (properties.hpp), causes the BOOST_GRAPH_NO_BUNDLED_PROPERTIES to be #defined. My question is, what is in this context understood by "template partial specialization" ? I ask, because I'm almost sure I've used this feature in VC7 before, hence my confusion. Many thanks in advance... Dan

2 1

[BGL] Obtaining corresponding vertex_descriptors
by J Swan 16 Dec '04

16 Dec '04

Suppose we have two BGL graphs g1 and g2, of type Graph1 and Graph2 respectively, such that g2 is a copy of g1. Given a vertex_descriptor v1 belonging to g1, can one generically obtain the corresponding vertex descriptor for g2: a) if Graph1 and Graph2 are actually the same type b) if Graph1 and Graph2 are different types? Regards, Jerry.

2 1

How to make an iterator with a stride... and more
by Eli Pulsifer 16 Dec '04

16 Dec '04

Hello, I have a situation which is probably quite common and already addressed by boost. So rather than write it my self, maybe someone can point me to the answer. I've got a geometry class that needs to expose iterators for the underling vertex components. Example: Class Vertex { positions_iterator PositionsBegin(); positions_iterator PositionsEnd(); normals_iterator NormalsBegin(); normals _iterator NormalsEnd(); ... } The first problem is depending on the format of the underling vertices, the stride between the data elements will change. Is there some easy way to implement this? I think writing my own using the boost::iterator_adapter is probably the way to go. Second problem is more involved. The texture data not only has a stride but a variable number of elements. Some vertices have 2 texture coordinates, some 3, some even more. Id love to define this iterator like this: stride_iterator< pair<float_iterator, float_iterator> > tex_coord_iterator; then create the iterator: stride_tupel_iterator< pair<float_iterator, float_iterator> >( pFirstTexCoord, texCoordStride, texCoordCount ); then use it: stride_tupel_iterator< pair<float_iterator, float_iterator> > it; for( it = vertex.PositionBegin() ; it != vertex.PositionEnd() ; ++it) { pair<float_iterator, float_iterator> coords; float_iterator iCoord; for(iCoord = coords.first ; iCoord != coords.last ; ++iCoord) { } } This will probably also require me to create my own highly special iterator class or is there a better way.

4 3

newbie build question
by Frank Brown 16 Dec '04

16 Dec '04

sorry if this has been asked before, it's very elementary but i can't find references in the archives or faq so here goes: i just installed boost libraries and built them via bjam. they seemed to build successfully. i'm using the vc7.1 compiler. when i try to compile (cl) a .cpp file containing the following include #include <boost/regex.hpp> i get the following: testBoost.cpp(8) : fatal error C1083: Cannot open include file: 'boost/regex.hpp': No such file or directory if i replace the include with the actual file spec like this: #include "C:\Boost\include\boost-1_32\boost\regex.hpp" i get the following compiler error: testboost.cpp C:\Boost\include\boost-1_32\boost\regex.hpp(28) : fatal error C1083: Cannot open include file: 'boost/regex/config.hpp': No such file or directory apparently the compiler (cl) isn't translating <boost>. since one boost header refers to others i need to fix this basic problem. i tried substituting the bjam.exe in place of cl to compile, then i get a different error: Unable to load Boost.Build: could not find "boost-build.jam" --------------------------------------------------------------- Attempted search from D:\c\whereis up to the root so i'm sorry to bother y'all with such a simple problem, all i need to know is how to compile (the 'hello world' scenario). thanks for your attention. -frank brown (stupid jerk) http://www.inwa.net/~frog

2 1

[BGL][variant] variant as internal edge property - nastiness w/MS7.1 + 1.31.0
by Christopher D. Russell 15 Dec '04

15 Dec '04

This isn't a question but rather a quick report for my future reference - I need to circle back and try to characterize this problem more fully when I'm not on deadline and can run some additional tests with Boost 1.32.0. Environment: - MS 7.1 compiler w/their STL distribution - Boost 1.31.0 (my client doesn't want to update to 1.32.0 until after this release) Summary: boost::variant registered as an internal edge property map member on a BGL graph causes the resultant graph to be inaccessible due to what appears to be incorrect initialization of both the internal vertex and edge property maps. I SUSPECT THAT THE ROOT CAUSE OF THIS CAN BE TRACKED BACK TO A MS 7.1 COMPILER BUG due to the fact that attempts to compile my test code results in either of (a) an C1001 Internal Compiler Error (b) a error-free compile and a completely screwed runtime. Details: The boost::variant in question is bounded by several unique specializations of a fully-specialized class. As follows: // pseudocode class A; class B; class C; template <typename tail_T, typename head_T> class edge_exeuctor {}; template <> class edge_executor<A, B>; template <> class edge_exeuctor<A,C>; tempalte <> class edge_exeuctor<B,C>; template <> class edge_executor<B,A>; tempalte <> class edge_executor<C,A>; template <> class edge_executor<C,B>; typedef boost::variant< edge_executor<A,B>, edge_executor<A,C>, edge_executor<B,C>, edge_executor<B,A>, edge_executor<C,A>, edge_executor<C,B> > variant_edge_t; The graph in question is declared as: enum vertex_foo_property_t { vertex_foo_property = 801 }; enum edge_foo_property_t {edge_foo_property = 802 }; BOOST_INSTALL_PROPERTY(vertex, foo_property); BOOST_INSTALL_PROPERTY(edge, foo_property); typedef property<vertex_foo_property, int, boost::property<vertex_color_t, default_color_type> > vertex_properties_t; typedef property<edge_foo_property, variant_edge_t> edge_properties_t; typedef adjacency_list<listS, listS, bidirectionalS, vertex_properties_t, edge_properties_t> graph_t; typedef graph_traits<graph_t>::edges_size_type edges_size_t; Failure: // THE TEST CODE WILL NOT ALWAYS COMPILE W/MS 7.1 // HALF THE TIME IT BOMBS W/C1001 INTERNAL COMPILER ERROR // when it does compile, no errors are reported by the following runtime behavior is observed graph_t g; edges_size_t edge_count = num_edges(g); // <- protection fault // stepping into num_edges in a debug build reveals that both vertex and edge property maps point to uninitialized memory (0xcdcdcdcd) // removing variant_edge_t from edge_properties_t and replacing with an int works as expected... ---- - Chris

2 2

[BGL] Boost Graph Library Users
by Christopher D. Russell 15 Dec '04

15 Dec '04

Doug G. or whoever is maintaining the online BGL docs over at Indiana, would you please add a link to the Hyperworx Platform Project on the "Boost Graph Library Users" page (http://www.boost.org/libs/graph/doc/users.html) Hyperworx Platform Project: http://hyperworx.org (notes on Hyperworx BGL usage: http://hyperworx.org/acc1c40a-592e-4f43-aa70-2237d5e39134.html) - Thanks and regards Chris

2 2