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

RE: [Boost-users] boost::shared_ptr performance
by Tom Matelich 21 Nov '03

21 Nov '03

> -----Original Message----- > From: Matthew Wilson [mailto:stlsoft@hotmail.com] > Sent: Friday, November 14, 2003 4:23 PM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] boost::shared_ptr performance > > > [I posted this in boost.devel, but got no response. > Presumably that was the > wrong group. :)] > I'm going to respond, but I don't have much to say. I would think that with all the work you put into making this comparison that you could probably determine why smart_ptr is slower than yours. To me this comparison is interesting but not without comparing your code with smart_ptr. Given the lack of code, I have to assume you're waiting for someone to say something like, "WOW!!! I gotta get me some of that!" boost::smart_ptr is already a well used class, so if you're looking to contribute, either post your code so we can maybe see how it is better, or see what it is that is missing from your code to make it faster. Benchmarks are useless without more information. Please make your code available so we can improve boost. If that is not your goal, come out and say so. Tom Matelich Boost Lover ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and/or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

3 3

RE: [Boost-users] lexical_cast causes level 4 warnings w/ VC7.1
by Sam Partington 20 Nov '03

20 Nov '03

Bruce Johnston <mailto:c_kernel@hotmail.com> wrote: > I'm working on a project with strict requirements for the > build settings, > including mandatory warning level 4 and "treat warnings as errors". I > discovered that lexical_cast causes warnings C4127, C4511, > and C4512 when > compiling with warning level 4 using VC7.1. Try the following > code for a > quick repro: 4511 and 4512 are useless warnings. They are telling you that the copy constructor and assignment operator are inaccessible. Even though you're not trying to call them. Take the following code class noncopyable { private: noncopyable(const noncopyable&); noncopyable& operator=(const noncopyable&); }; class a_resource : noncopyable { // ... }; // ... { a_resource res; } Clearly a_resource is not meant to be copied, the developer has gone to lengths to make that clear. Indeed it never is copied, or assigned, yet the warnings will still be issued. C4127 is also awkward. As it gives warnings for some common idioms. It refers to conditional expressions being constant. So : do { XXX } while(0); Gives the warning, which is a common implementation of an ASSERT() macro, and likewise // in an header : const bool debug = false; // in code : if (debug) { } does also. None of these technigues indicate a possible error in code. Ideally all three of these warnings would be disabled in config.hpp. > As an aside, what warning level is typically used by > developers working on > Boost? On VC6 we build on warning level 3, 4 is just too noisy with the built in headers. On VC7.1 we use level 4, but with C4127, C4511, C4512 switched off. HTH Sam ****************** This e-mail has been sent from Imagination Technologies Limited. PowerVR, Metagence, Ensigma and PURE Digital are divisions of Imagination Technologies Limited. The information contained in this e-mail, including any attachment, is confidential and may be legally privileged. It is intended solely for the addressee(s) and access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying or distribution or use of the information contained in this e-mail, is prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender by return e-mail and then delete it from your system. Internet communications cannot be guaranteed to be secure, error or virus-free. The sender does not accept liability for any errors or omissions which arise as a result. Any views expressed in this message are those of the author, except where the author specifies and, with authority, states them to be the views of Imagination Technologies Ltd.

2 1

Re: [Boost-users] Re: filesystem::directory_iterator::operator++() never returns <--never mind
by Beman Dawes 20 Nov '03

20 Nov '03

At 07:02 PM 11/19/2003, John.Wismar(a)alldata.com wrote: > >OK, I found it. > >Upon yet another search of the archive, I found it: I was using the >single-threaded version of the library in a multi-threaded app. > >Sorry for the bandwidth! Actually, it is helpful. It gives us more incentive to work on reliability enhancements. Thanks, --Beman

1 0

RE: [Boost-users] Re: boost::shared_ptr performance
by Tom Matelich 20 Nov '03

20 Nov '03

> -----Original Message----- > From: Matthew Wilson [mailto:stlsoft@hotmail.com] > Sent: Wednesday, November 19, 2003 11:27 AM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] Re: boost::shared_ptr performance > > > > > > > > [I posted this in boost.devel, but got no response. > > > Presumably that was the > > > wrong group. :)] > > > > > > > I'm going to respond, but I don't have much to say. I > would think that > with all the work you put into making this comparison that you could > probably determine why smart_ptr is slower than yours. To me this > comparison is interesting but not without comparing your code with > smart_ptr. Given the lack of code, I have to assume you're > waiting for > someone to say something like, "WOW!!! I gotta get me some of that!" > > No, I was seeking information, as I said. > > "There are environment settings for which boost::shared_ptr will > perform much better. If that's so, can someone help me out > with suggestions > of what defines to make?" > > It turns out that there are. > > If I was wanting to make a splash, I'd got for a dip down at > the beach. :) Sorry for any appearance of hostility. I'll check out the devel thread. ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and/or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

1 0

lexical_cast causes level 4 warnings w/ VC7.1
by Bruce Johnston 20 Nov '03

20 Nov '03

I'm working on a project with strict requirements for the build settings, including mandatory warning level 4 and "treat warnings as errors". I discovered that lexical_cast causes warnings C4127, C4511, and C4512 when compiling with warning level 4 using VC7.1. Try the following code for a quick repro: #include <string> #include <iostream> #include "boost/lexical_cast.hpp" int main() { std::string helloFactor = boost::lexical_cast<std::string>( 7 ) ; std::cout << "Hello # " << helloFactor << std::endl ; return 0 ; } Builds fine at warning level 3, fails with /W4 and /WX. As an aside, what warning level is typically used by developers working on Boost? -Bruce Johnston Simba Technologies

1 0

Re: filesystem::directory_iterator::operator++() never returns <--never mind
by John.Wismar＠alldata.com 20 Nov '03

20 Nov '03

OK, I found it. Upon yet another search of the archive, I found it: I was using the single-threaded version of the library in a multi-threaded app. Sorry for the bandwidth! --------------------- John Wismar john.wismar(a)alldata.com In a previous state of enlightnment, I wrote: I'm using the fielsystem library's directory_iterator class to collect information about the files in a directory. I'm using VC7.0, and Boost 1.30.2. My logic looks something like this: ---------------------------------------------------------------------- class DirInfo { public: DirInfo(fs::path aPath) : myPath(aPath){} void scan(); void addFile(fs::path); private: fs::path myPath; } void DirInfo::scan () { fs::directory_iterator itEnd; for (fs::directory_iterator it(myPath); it != itEnd; ++it) { TRACE("File: %s\n", it->string().c_str()); if (!fs::is_directory(*it)) { addFile(*it); } } } DirInfo di(fs::path("C:\\temp\\", fs::native); di.scan(); ---------------------------------------------------------- This successfully goes through all of the files (and subdirectories) in the given directory, but after the last item, the next call to fs::directory_iterator::operator ++() never returns. If anyone has any suggestions or ideas, I would love to hear them!! Thanks! The call stack at the point where execution seems to lock up looks like this: ntdll.dll!NtDelayExecution() + 0xc kernel32.dll!_Sleep@4() + 0xb MyApp.exe.exe!boost::detail::lightweight_mutex::scoped_lock::scoped_lock(boost::detail::lightweight_mutex & m={...}) Line 96 + 0xa C++ MyApp.exe.exe!boost::detail::sp_counted_base::release() Line 132 + 0xf C++ MyApp.exe.exe!boost::detail::shared_count::~shared_count() Line 380 C++ MyApp.exe.exe!boost::shared_ptr<boost::filesystem::directory_iterator::dir_itr_imp>:: ~shared_ptr<boost::filesystem::directory_iterator::dir_itr_imp>() + 0x2e C++ MyApp.exe.exe!boost::shared_ptr<boost::filesystem::directory_iterator::dir_itr_imp>::reset () Line 217 C++ MyApp.exe.exe!boost::filesystem::directory_iterator::m_inc() Line 256 C++ > MyApp.exe.exe!boost::filesystem::directory_iterator::operator++() Line 88 + 0x2b C++ MyApp.exe.exe!DirInfo::scan() Line 63 + 0x1a C++ --------------------- John Wismar john.wismar(a)alldata.com

1 0

filesystem::directory_iterator::operator++() never returns
by John.Wismar＠alldata.com 19 Nov '03

19 Nov '03

I'm using the fielsystem library's directory_iterator class to collect information about the files in a directory. I'm using VC7.0, and Boost 1.30.2. My logic looks something like this: ---------------------------------------------------------------------- class DirInfo { public: DirInfo(fs::path aPath) : myPath(aPath){} void scan(); void addFile(fs::path); private: fs::path myPath; } void DirInfo::scan () { fs::directory_iterator itEnd; for (fs::directory_iterator it(myPath); it != itEnd; ++it) { TRACE("File: %s\n", it->string().c_str()); if (!fs::is_directory(*it)) { addFile(*it); } } } DirInfo di(fs::path("C:\\temp\\", fs::native); di.scan(); ---------------------------------------------------------- This successfully goes through all of the files (and subdirectories) in the given directory, but after the last item, the next call to fs::directory_iterator::operator ++() never returns. If anyone has any suggestions or ideas, I would love to hear them!! Thanks! The call stack at the point where execution seems to lock up looks like this: ntdll.dll!NtDelayExecution() + 0xc kernel32.dll!_Sleep@4() + 0xb MyApp.exe.exe!boost::detail::lightweight_mutex::scoped_lock::scoped_lock(boost::detail::lightweight_mutex & m={...}) Line 96 + 0xa C++ MyApp.exe.exe!boost::detail::sp_counted_base::release() Line 132 + 0xf C++ MyApp.exe.exe!boost::detail::shared_count::~shared_count() Line 380 C++ MyApp.exe.exe!boost::shared_ptr<boost::filesystem::directory_iterator::dir_itr_imp>:: ~shared_ptr<boost::filesystem::directory_iterator::dir_itr_imp>() + 0x2e C++ MyApp.exe.exe!boost::shared_ptr<boost::filesystem::directory_iterator::dir_itr_imp>::reset () Line 217 C++ MyApp.exe.exe!boost::filesystem::directory_iterator::m_inc() Line 256 C++ > MyApp.exe.exe!boost::filesystem::directory_iterator::operator++() Line 88 + 0x2b C++ MyApp.exe.exe!DirInfo::scan() Line 63 + 0x1a C++ --------------------- John Wismar john.wismar(a)alldata.com

1 0

regex static lib for x86 emulator
by Reuti＠sdc.canon.co.in 19 Nov '03

19 Nov '03

I can build static library for ARM processor. But when building for X86 emulator I am getting following error. LINK : fatal error LNK1104: cannot open file 'boost_regex_vc6_sss.lib' Please help. Thanks in advance. Reuti

1 0

gregorian: explicit date::date(date_int_type) ?
by Michael Haubenwallner 19 Nov '03

19 Nov '03

Hi, I'm preparing my company's step from C to C++, and when i use boost::date_time::*, there's a great danger to make mistakes like this with boost-1.30.2: #include <time.h> #include <iostream> #include <boost/date_time/posix_time/posix_time.hpp> using namespace boost::posix_time; using namespace boost::gregorian; int main() { time_t now = time(0); try { ptime time(now); // mistake cerr << to_simple_string(time) << endl; } catch (exception const& e) { cerr << "error: " << e.what() << endl; } } The problem is that the time_t in this case is treated as a day-count from which a gregorian::date() is implicitly constructed. When digging through the gregorian::date, i see that the constructors of date_time::date() from date_int_type and date_rep_type protected. So, wouldn't it be better to make the gregorian::date() constructors from date_int_type and date_rep_type explicit, to get a compile-time error with this sample rather than the out-of-range-exception "Year is out of valid range: 1400..10000" ? And another reason to make this constructor explicit might be that date_rep_type is the internal representation of date(), so when constructing date() with a day_count, you have to know the epoch, and then constructing date() should be done explicitly... What do you think about this ? Thanks, Michael Haubenwallner -- Michael Haubenwallner SALOMON Automation GmbH Forschung & Entwicklung A-8114 Friesach bei Graz T +43 3127 200 308 F +43 3127 200 22 mailto:michael.haubenwallner@salomon.at http://www.salomon.at

2 3

Invert Matrix
by JEFFREY CULLINA 18 Nov '03

18 Nov '03

I have devoleped code to derive a simple matrix expression: [K]*[D]=[R] wher D is an unknown vector. I am looking for code to do two things: 1. Invert [K] to get the expression [D]=inv([K])*[R] 2. Solve the equation in 1 It looks like the UBLAS toolkit provides a function _t_sv to solve the equation, but I do not see anything to help me invert the matrix. Is there code available to help me invert a matrix? While I am at it, I may as well ask if _t_sv is the best function to use to solve the system. Thanks, Jeff

1 0

Smart pointers and STL allocators
by Mark A. Gibbs 18 Nov '03

18 Nov '03

I have a couple of questions about combining smart pointers and STL allocators. First of all, am I right in assuming that I can use the shared_* templates right out of the box, as long as I define a custom deleter that uses the allocator's deallocate function? But if that's so, how exactly is it done? Part of my confusion comes from the fact that the STL allocator documentation I've come across isn't exactly clear on the semantics of allocators (I don't have a copy of the standard). For instance, I'm not 100% sure whether or not I have to call construct() after allocate() and destroy() before deallocate(). This is what I have so far: class allocator_helper { public: allocator_helper(allocator_type& a) : a_(a) {} void operator()(void const* p) const { a_.deallocate(static_cast<allocator_type::pointer>(p)); } private: allocator_type& a_; }; foo* bar = static_cast<foo*>(get_allocator().allocate(1)); shared_ptr<foo> p_foo(bar, allocator_helper(get_allocator())); foo* baz = static_cast<foo*>(get_allocator().allocate(10)); shared_array<foo> p_foo(baz, allocator_helper(get_allocator())); Now, for scoped_* I would probably have to rewrite them to use the allocator, right? Or is there a way to use allocators with the existing scoped_* templates? Mark

2 3

regex problems
by Paul Scruby 18 Nov '03

18 Nov '03

The boost::regex class is crashing when I construct it with some regular expressions. For example: "(value|default)[^}]*\{" will crash and "value|default" does not. Is this a bug, or am I doing something wrong? I am running gcc2.96 and boost1.30.2. I have attached an example src including Makefile. Thanks in advance, Paul

3 3

Newbie question, linking problems
by Mrk 17 Nov '03

17 Nov '03

Hello, I'm trying to get regexp to work under vc6, STL 4.5.3 and boost 1.30.2 but sadly I'm running into some problems. Did anyone ever had this problem with the following methods ? error LNK2001: unresolved external symbol "public: static void __cdecl boost::w32_regex_traits<char>::transform_primary( ... error LNK2001: unresolved external symbol "public: static void __cdecl boost::w32_regex_traits<char>::transform( ... Thanks, Mrk

1 0

Re: [Boost-users] [BGL] Problem with color maps for undirected_dfs_visit
by Jeremy Siek 17 Nov '03

17 Nov '03

Hi Tarjei, On Friday, November 14, 2003, at 05:33 AM, Tarjei Knapstad wrote: > On Thu, 2003-11-13 at 17:09, Jeremy Siek wrote: >> Hi Tarjei, >> >> You need to initialize the edge index property map (only the vertex >> index >> map is automatically initialized, and then only for VertexList=vecS). >> > > Hmm, ok, but I still don't quite understand. I thought that > initializing > the std::vector holding the colors was sufficient...? To my > understanding an iterator_property_map is just a property map which > iterates through some other container (that can provide a > RandomAccessIterator) actually holding the properties? Yes, your edge color map is initialized just fine, but you also need to initialize the edge index map. Here's the reason why: your edge color map uses the edge index map to go from an edge descriptor to an integer offset, which is then used to access into the color vector. Currently, your edge index map is initialized to random garbage, so you are going out-of-bounds when accessing the edge color vector. See the example file exterior_properties.cpp, BTW, you don't need to declare an edge_color property for the adjacency_list because you are using an external edge color map. > > Obviously there's some connection I don't quite get here... I also > don't > quite understand the EColorValue uv_color = get(edge_color, *ei); call > in undir_dfv_impl. It asks for the edge_color at the edge_descriptor > *ei, but from where? > > Anyway, I don't really even need an edge_index property here (or do > I?), > it was more or less to try to get this working. Yes, you need it for the reason given above. BTW, if you switch to using an internal edge color property, then you won't need the edge index property, or the edge color vector. Cheers, Jeremy

2 1

GRAPHVIZ_DIRECTED macro definition?
by Soumitra Chatterjee 17 Nov '03

17 Nov '03

Hi, In the file .../libs/graph/src/graphviz_parser.y we have the following: #ifndef GRAPHVIZ_DIRECTED #error Need to define the GRAPHVIZ_DIRECTED macro to either 0 or 1 #endif I couldn't locate the definition for the above macro in my boost installation. Do we need to define it explicitly, or am I missing some file(s)? Thanks, Soumitra

2 1

Error 112: Missing directory LEDA
by Soumitra Chatterjee 17 Nov '03

17 Nov '03

Hi, I have downloaded boost-1.30.2, and while trying to compile/test it, I am getting the error(s): Error 112: "/TESTC++/Boost-1.30.2/boost/graph/leda_graph.hpp", line 33 # Include file <LEDA/graph.h> not found. #include <LEDA/graph.h> ^^^^^^^^^^^^^^ [...snip...] The directory 'LEDA' seems to be missing from the downloaded package. Have I missed something during the install process, or is there something else to be done after unpacking the installation package? I am using JAM for the build. Thanks, Soumitra

3 2

Re: Intoductory Boost Presentation
by Jorg Brown 16 Nov '03

16 Nov '03

Matt - The corrected code is indeed much better. May I suggest using std::vector instead of vector? The typedef of FooPtr is fine, it turns out; it's the typedef of struct Foo that was the problem. I had declared Foo within main as well, and that blocks the use of boost::shared_ptr on it. As long as Foo is declared at global scope, all is well. As for the correct output, my compiler gives me 3, then 2, then 1. I talked it over with a friend, and I guess the order of the 2 vs 1 is undefined, and depends on your STL's implementation of std::vector. As for the crazy aunt in the basement, the comment was meant for an internal list that only 20-30 people are on, not meant for general consumption, and probably merits an extra thread by itself. Put simply, using boost can generate a surprising amount of code and overhead. This is true of STL as well. There are even some good books describing STL; I happen to like Plauger/Stepanov/Lee/Musser, as well as Jasoutis. But nowhere do I see any reference as to what the downsides are - and nowhere do I see any concise explanation of why an enormous amount of code (660 bytes in an optimized, no-symbols build) is generated when I say something as simple as void Testbed(void) { boost::function<void> SimpleFPtr(&Testbed); } When you say "I was trying to generate interest in these libraries and thus didn't want to focus too much on the negatives", I can understand your point of view, but what I see in real life is that people start using boost::function everywhere they used to use plain old function pointers, with nary a clue that their code size just exploded with no benefit. But like I said, it's worth a whole other thread. Thanks for fixing the code and responding so quickly! jorg -----Original Message----- From: "Matt S Trentini" <matt_s_trentini(a)hotmail.com> Reply-To: Boost Users mailing list <boost-users(a)lists.boost.org> Date: Tue, 11 Nov 2003 23:19:12 +1100 To: boost-users(a)lists.boost.org Subject: [Boost-users] Re: Intoductory Boost Presentation Heya Jon, Ah, the smart_ptr example, I knew that would come back to bite me! ;) I changed this example at the last minute in an effort to simplify but, as your co-worker correctly points out, there are many errors in it. The correct code is below though the graphic requires change (yes, I could have change the list.push_front() to a push_back but I like to see the variety!). int main() { typedef boost::shared_ptr<Foo> FooPtr; vector<FooPtr> foo_vector; list<FooPtr> foo_list; FooPtr foo_ptr( new Foo(1) ); foo_vector.push_back( foo_ptr ); foo_list .push_back( foo_ptr ); foo_vector.push_back ( FooPtr( new Foo(2) ) ); foo_list .push_front( FooPtr( new Foo(3) ) ); } You'll notice that I left the typedef in there. I can't find anything in the standard (or with google) about it being illegal in main, nor does my compiler emit any warnings. Can anyone shed some light on this? And I've got to disagree with your friend about the correct ordering - the expected output is 3, 1, 2 (Remember that foo_ptr gets deleted first). I'll endeavour to fix this example up and upload the changes over the next couple of days. As for these comments: > > The rest of the pages have the classic boost downfall: they > > don't discuss any of the pitfalls, performance problems, or > > code bloat issues, which frankly, seem like the "crazy aunt > > in the basement" of boost. I'll defend myself on two fronts. First, it's an introductory presentation - I was trying to generate interest in these libraries and thus didn't want to focus too much on the negatives. Secondly, I _did_ cover some of those points - like all good presentations not everything is contained in the bullet points. Thanks for the feedback though, it's helping to make this presentation better! Cheers, Matt PS If there are any other problems that you or your co-worker have found please don't hesitate to report them! _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ------ End of Forwarded Message

3 2

Intoductory Boost Presentation
by Matthew S Trentini 16 Nov '03

16 Nov '03

Heya Everyone, I recently gave a presentation to my work colleagues on the wonders of the Boost library. Many weren't aware of what it was or what it could do so it just contains an overview and some coverage on nine of the libraries (with short code examples). It went for nearly an hour and was pretty well received, so I thought that maybe someone else out there could use the material. Please feel free to download (it's in a variety of formats) from here: http://www.alphalink.com.au/~mattyt/BoostPresentation1/boost.html Cheers, Matt PS If you want to modify/publish/whatever that's fine... _________________________________________________________________ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp

7 10

Re: [Boost-users] Building Regex++ lib on Pocket PC using EmbeddedVC++4.0
by Reuti＠sdc.canon.co.in 16 Nov '03

16 Nov '03

Thanx. With latest version I could build but I could not create import library corressponding to dll created. Is there some macro for this? ===== Reuti "John Maddock" <john(a)johnmaddock.co.uk> To: "Boost Users mailing list" <boost-users(a)lists.boost.org> Sent by: cc: boost-users-bounces@list Subject: Re: [Boost-users] Building Regex++ lib on Pocket PC s.boost.org using EmbeddedVC++4.0 11/13/2003 05:32 PM Please respond to Boost Users mailing list > Has anyone tried building regex++ lib for PPC using EVC++? I've never tried with that compiler - I think it's even worse than VC6 for conformance? > I can build it using VC++6.0 using the .mak files supplied with it.But I am > getting errors and warnings. > Error is regarding the use of typename keyword in lib source and warning is > about C++ Exceptions unwinding capability. Defining BOOST_NO_EXCEPTIONS should fix that - in fact it should get automatically set for vc with no eh support, so there could be a config bug there. > I replaced C++ try, catch by Win32 __try , __except but don't know what to > do with template error? What is there error: you may be able to just remove the typename keyword to fix the problem? John. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

Preprocessor Metaprogramming Problem
by Mitch 16 Nov '03

16 Nov '03

I'm trying to figure out the longest sequence in a sequence. Here's the MACRO I tried. #define OP(size, state, elem) BOOST_PP_MAX(state, BOOST_PP_SEQ_SIZE(elem)) #define MACRO(seq) BOOST_PP_SEQ_FOLD_LEFT(OP, 0, seq) If I process ((a)(b))((c)) I get 2 back as expected. However, the extra parenthesis seems awkward. I'd like to process ((a)(b))(c) instead, but can't. The '(c)' gets coverted to plain 'c' as the elem parameter to OP and that's not a valid sequence. Any ideas? Mitch

1 0

boost::shared_ptr performance
by Matthew Wilson 15 Nov '03

15 Nov '03

[I posted this in boost.devel, but got no response. Presumably that was the wrong group. :)] Hi Boosters I'm just doing some research on reference-counting, and contrasting self-counting types with externally counted types, the latter effected with the rather excellent shared pointer technique. [As a side question, is it true that Nicolai Josuttis was the inventor of the technique?] Naturally, one of the shared pointer's I've used is boost::shared_ptr. The measurements have demonstrated some surprising performance characteristics for shared_ptr in particular, and I want to solicit the opinion of the expert's here before I make any bold claims, as some results are just too surprising for me to trust them. There are five types tested. 1. A self-counting type, using an ancient Synesis (my company) template ref-counting bolt-in class 2. A self-counting type, using a custom-written (for this test) template ref-counting bolt-in class 3. Externally counting, using boost::shared_ptr 4. Externally counting, using a custom-written (for this test) shared pointer type 5. Externally counting, using a custom-written (for this test) shared pointer type, which has a custom allocator for the shared count members There were three scenarios investigated, and the same algorithms were applied to the above five types A: Saving refs vector<smart-ptr> ptrs; loop (100,000 times) { smart-ptr sp1(new Thing); sp1 = sp1; smart-ptr p2; p2 = p1; smart-ptr p3(p1); smart-ptr p4(p3); smart-ptr p5(p4); smart-ptr p6(p5); process_Thing(p6.get()); // A function to do something (actually it just returns the result of a call on Thing) to prevent elision by optimisation ptrs.push_back(p5); } The whole is executed within a single thread, and the program is tested in both single and multithreaded forms. B: Discarding refs This is identical to A ("Saving refs") except that saving them to the vector of ptrs is omitted. Again, this is done in one thread, and single and multi-threaded forms tested C: Multi-threaded sharing 20 smart-pointers are created, containing 20 Thing instances, in the main thread. Then 20 threads, using the following thread-proc, are created, and executed. Two times are recorded for each scenario: the total time, and the sum of the individual thread-times (obtained by the WinSTL threadtimes_counter, based on the Win32 API function GetThreadTimes()) std::vector<ptr_type> ptrs(ITERATIONS / 10); for(size_t i = 0; i < 10; ++i) { for(size_t j = 0; j < ITERATIONS / 10; ++j) { ptrs.push_back(things[i % things.size()]); } } ITERATIONS is 100,000. things is the shared shared_ptr array The purpose of this one is to really exercise the sharing between threads. Results (all results are expressed in terms of the most costly pointer) ============================================= [Note, all were compiled with Intel 7.0 with very aggressive speed optimisations (-O2 -Ox -QaxMKW /Qvc7 -EHsc), and executed in a single session on an otherwise quiescent 512MB 2GHz XP box.] A (single-threaded) -------------------- 1. Synesis self-counter: 65% 2. Custom self-counter: 58% 3. boost::shared_ptr: 100% 4. custom SharedPtr: 53% 5. custom SharedPtr + rc pool): 48% I was not surprised that the crusty old Synesis type was slower than the custom self-counter. As expected, the custom shared-ptr with rc pool was the fastest. I was a little surprised that the Boost shared_ptr was up to twice as slow. However, they're all within 100% of each other, so it's no big result I guess. A (multi-threaded) -------------------- 1. Synesis self-counter: 90% 2. Custom self-counter: 46% 3. boost::shared_ptr: 100% 4. custom SharedPtr: 28% 5. custom SharedPtr + rc pool): 27% This was surprising. I expected the use of thread-safe operations (atomic increments, etc.) to flatten out the curve, but the reverse has happened. Interestingly, the two real-world types (Synesis::RefCounter and boost::shared_ptr) fair less well. Again, not what I expected. B (single-threaded) -------------------- 1. Synesis self-counter: 65% 2. Custom self-counter: 55% 3. boost::shared_ptr: 100% 4. custom SharedPtr: 59% 5. custom SharedPtr + rc pool): 53% This scenario has a lot more reference-increments, and a lot less deallocation of the reference-counted instance. Nonetheless, the results are virtually identical, in relative terms (the actual times taken are about 50% across the board). B (multi-threaded) -------------------- 1. Synesis self-counter: 71% 2. Custom self-counter: 41% 3. boost::shared_ptr: 100% 4. custom SharedPtr: 32% 5. custom SharedPtr + rc pool): 31% Pretty much the same as with B (single-threaded). The results are the same, in relative terms Up to this point, the results are mildly interesting, but nothing earth shattering. C - (Times are total time, and thread times, respectively) 1. Synesis self-counter: 2.9% 39% 2. Custom self-counter: 2.7% 35% 3. boost::shared_ptr: 100% 100% 4. custom SharedPtr: 1.0% 13% 5. custom SharedPtr + rc pool): 1.2% 15% This scenario tells quite a different tail indeed. One thing to note is that because of the degree of reference-sharing between the ptr-storing vectors in the 20 threads, the ref-count-pool becomes a pessimisation as a result of the number of actual smart pointer instances being created exceeding the arbitrary 1024 cached ref-counts available. It's likely that this number would not be exceeded in real-world scenarios, so the pool is probably still worth having. Naturally, the very big question is: what's happening to boost::shared_ptr? In thread times, it performs 2-3 times worse than in single threaded scenarios (irrespective of whether they are built for single or multiple threads). However, in total time, it performs extremely poorly, up to 100 times slower than some of the others! Clearly, there is some serious contention involved. There are three possibilities I have thought of: (i) It performs very poorly in multi-threaded sharing scenarios. If this is the case, can any people more expert in Boost than me proffer an explanation as to precisely the problem, and is any such person motivated to try and address the issue? (ii) The particular sharing scenario is well away from any real-world scenario in which boost::shared_ptr is likely to be used. If this is the case, why do four different implementations, representing two very different reference-counting strategies, all maintain a consistent relative performance? What are the scenarios for which boost::shared_ptr is optimised? (iii) There are environment settings for which boost::shared_ptr will perform much better. If that's so, can someone help me out with suggestions of what defines to make? Why are these settings not the default. I'd be very interested in your thoughts. Many thanks in advance. -- Matthew Wilson STLSoft moderator (http://www.stlsoft.org) Contributing editor, C/C++ Users Journal (www.synesis.com.au/articles.html#columns) "You can tell a Yorkshireman, but you can't tell him much!" -- Uncle Michael ---------------------------------------------------------------------------- --- _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Property map deletion
by David Ohlemacher 14 Nov '03

14 Nov '03

Hi all. Partway through my app's execution, I find that I no longer need the values in a custom property map (edge). The map potentially may be quite large. What is the best way to empty it? Thanks, -d

3 7

Boost and Windows CE - does it?
by Steve Folly 14 Nov '03

14 Nov '03

Hi, I know the real answer is probably to just 'try it', but I thought I'd ask to see if anyone else has tried this. We have an application framework which makes extensive use of boost, particularly shared pointers. Currently, we can build Win32 and Mac Carbon applications. Has anyone successfully built applications utilising boost for Windows CE? In particular, we've just started looking at the eMbedded Visual C++ 4.0 compiler and the Pocket PC 2003 SDK. -- Regards, Steve.

1 0

Re: 'long long' problem on VC++7.1
by Nick Savoiu 14 Nov '03

14 Nov '03

And here's what's missing.... I'm using the /Za switch (Disable Language Extensions). But I'm a bit puzzled. I would have thought that /Za (a more standard compliant mode) would not fail. Nick "Nick Savoiu" <savoiu(a)ics.uci.edu> wrote in message news:... > That would be a solution but 'long long' appears in quite a few places. So, > I think there's something else that I'm missing... > > Nick > > "Jeff Garland" <jeff(a)crystalclearsoftware.com> wrote in message > news:20031111022332.M81509@crystalclearsoftware.com... > > On Mon, 10 Nov 2003 14:14:04 -0800, Nick Savoiu wrote > > > I'm trying to compile some boost code on VC+7.1 but I get: > > > > > > e:\users\savoiu\Projects\boost-1.30.2\boost\concept_check.hpp(183) : > > > error C2632: 'long' followed by 'long' is illegal > > > > > > Do I need any #defines when using Boost with VC++7.1 or should it > > > work right out of the box? > > > > I believe this is an error in the concept_check code. Try changing the > 'long > > long' to boost::int64_t. > > > > Jeff > >

2 5

Compiler error with STLport-4.6
by Peter Westerstrom 14 Nov '03

14 Nov '03

Hello, I get this internal compiler error below when compiling boost-regex (from cvs today 11 nov 2003) using STLport-4.6. The error do not show up when using STLport-4.5.3 though. Any ideas? Problem in STLport-4.6 or boost, that's the question? cl -Ic:\EON\builds\head\Development\ExternalLibraries\include\stlport /nologo /MT /W3 /GX /O2 /GB /GF /Gy /Ic:\EON\builds\head\Development\ExternalLibraries\include\stlport /I..\..\..\ /D_MT /DWIN32 /DNDEBUG /D_MBCS /D_LIB /c -DBOOST_REGEX_STATIC_LINK -D_STLP_USE_STATIC_LIB -D_RTLDLL -Y- -Fo./vc6-stlport/libboost_regex-vc6-mt-sp-1_31/ -Fdvc6-stlport/libboost_regex-vc6-mt-sp-1_31.pdb ../src/c_regex_traits.cpp Command line warning D4002 : ignoring unknown option '-Y-' c_regex_traits.cpp ..\..\..\boost/detail/allocator.hpp(67) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 1794) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. Peter Westerstrom peterw(a)eonreality.se

3 4