- Boost - lists.boost.org

shared_ptr with dynamic_cast
by Yuval Ronen 23 Jun '04

23 Jun '04

Hi, I'm new to boost, so this post might seem silly to some of you, and I apologize if this is the case. I have a tiny performance suggestion: The c'tor template<class Y> shared_ptr(shared_ptr<Y> const & r, detail::dynamic_cast_tag): px(dynamic_cast<element_type *>(r.px)), pn(r.pn) { if(px == 0) // need to allocate new counter -- the cast failed { pn = detail::shared_count(); } } should be changed to: template<class Y> shared_ptr(shared_ptr<Y> const & r, detail::dynamic_cast_tag): px(dynamic_cast<element_type *>(r.px)), pn(px ? r.pn : detail::shared_count()) { } The difference is when the dynamic_cast fails and returns NULL. In such cases the existing code copies the shared_count object, including mutex locking, only to discover later that it was unnecessary (the 'if(px == 0)' statement). The suggested code saves this copy of the shared_count object, which also saves some mutex lockings. Hope I'm not talking nonsense, Yuval

2 1

min/max, reloaded
by Eric Niebler 23 Jun '04

23 Jun '04

I have ripped out the std_min/std_max functions. They were a less-than-perfect solution to the problems caused by the min/max macros defined by some platform headers. I have fixed all the places in the Boost affected by this change, and I have also updated the coding guidelines. For your references, the guidelines are reproduced here: Make sure your code compiles in the presence of the min() and max() macros. Some platform headers define min() and max() macros which cause some common C++ constructs to fail to compile. Some simple tricks can protect your code from inappropriate macro substitution: If you want to call std::min() or std::max(): If you do not require argument-dependent look-up, use (std::min)(a,b). If you do require argument-dependent look-up, you should: #include <boost/minmax.hpp> Use BOOST_USING_STD_MIN(); to bring std::min() into the current scope. Use min BOOST_PREVENT_MACRO_SUBSTITUTION (a,b); to make an argument-dependent call to min(a,b). If you want to call std::numeric_limits<int>::max(), use (std::numeric_limits<int>::max)() instead. If you want to call a min() or max() member function, instead to doing obj.min(), use (obj.min)(). If you want to declare or define a function or a member function named min or max, then you must use the BOOST_PREVENT_MACRO_SUBSTITUTION macro. Instead of writing int min() { return 0; } you should write int min BOOST_PREVENT_MACRO_SUBSTITUTION () { return 0; } This is true regardless if the function is a free (namespace scope) function, a member function or a static member function, and it applies for the function declaration as well as the function definition. Thanks. -- Eric Niebler Boost Consulting www.boost-consulting.com

3 4

Boost.Config defect macro proposal
by Joaquín Mª López Muñoz 23 Jun '04

23 Jun '04

Some months ago I proposed to include a defect macro to detect some defficiencies by several compilers regarding the ability to handle pointers to data members as template parameters. The name we came up with is BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS I include a little test case that successfully detects the bug in three out of the four compilers checked to show the problem * MSVC 6.5 (MSKB article ##249045), * MSVC 7.0 (***) * ICC 7.0/7.1 for Windows (support issue #207321), * VisualAge 6.0 for AIX (internal defect #288539.) The compiler marked with (***) does fail with the test, but only under certain compiler settings that I've not been able to isolate properly. When last discussed, it was argued that a new defect macro would only make sense if some lib needed it: now Boost.MultiIndex can take advantage of it (actually, the lib assumes the macro even if not currently supported by Boost.Config), and the problem has turned out to be more prevalent than the original MSVC-constrained case hinted at. Is it OK to add this to Boost.Config? Comment? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo *** BEGIN TEST CODE*** #include <iostream> struct pair { int x,y; pair(int x_,int y_):x(x_),y(y_){} }; template<int pair::* PtrToPairMember> struct foo { int bar(pair& p){return p.*PtrToPairMember;} }; int main() { pair p(0,1); foo<&pair::x> fx; foo<&pair::y> fy; if(fx.bar(p)!=0||fy.bar(p)!=1)std::cout<<"KO"<<std::endl; else std::cout<<"OK"<<std::endl; return 0; } ***END TEST CODE***

4 5

Generalized Iterator Ranges
by Dale Muchow 23 Jun '04

23 Jun '04

Here is a paper I wrote discussing the notion of generalizing an iterator defined range. It includes the proposal and definition of a new concept, Range. It was written as a masters research paper for graduate work I did at North Dakota State University. http://www.lycanth.com/dmuchow/GeneralizedIteratorRanges.doc.zip _________________________________________________________________ >From will you? to I do, MSN Life Events is your resource for Getting Married. http://lifeevents.msn.com/category.aspx?cid=married

2 1

[Graph] Bundled properties, take 2
by Douglas Paul Gregor 23 Jun '04

23 Jun '04

Good evening, I've just checked in version 2 of the "bundled properties" patch for the BGL, which allows one to stick various vertex/edge properties into a class to be stored within adjacency_list/adjacency_matrix. Accessing these properties is easier and more convenient. This patch completes support for bundled properties. Both of the major graph types are supported, bundled properties play nice with other property maps (get/put support added), and bundled properties work with graph adaptors. The documentation now strongly urges users to adopt bundled properties instead of property lists :) Doug

2 1

RE: [boost] Child processes
by Glen Knowles 23 Jun '04

23 Jun '04

> I don't know how java deals with this but on posix platforms > a sub-process holds some resources that have to be claimed > back by the parent process. > This includes (but is not restricted to) the result of the > process, i.e. > its return value. In case you are familiar with (posix) > threads: there you have to join a thread after it terminated. > It's conceptually the same thing here. > If you find yourself joining posix's threads only for this reason you should consider setting the detachstate attribute to PTHREAD_CREATE_DETACHED instead. Glen

1 0

RE: [boost] Re: static sized strings
by Reece Dunn 22 Jun '04

22 Jun '04

John Nagle wrote: >Reece Dunn wrote: >>John Nagle wrote: >>The problems arise in the interation with basic_string_impl and how to >>implement swap and functions that require constructing a string object. >Why do you need to construct a string object to swap? >Just swap one character at a time. There were 3 things I was cxonsidering when moving to the non-virtual implementation: [1] How do I pass the buffer and capacity to the implementation while allowing both fixed_string_base and fixed_string access to the basic_string interface? I have chosen to route the data through one of the basic_string constructors, requiring a const_cast. This is the best approach AFAICS. [2] How do I implement the swap function? The solution I arrived at is the one you suggest: to swap the data character-by-character. What you have to consider when doing this is that the strings don't exceed capacity, resulting in additional logic. [3] How do I approach the substr function and the + operators? Although it is now possible to construct a fixed_string_base object from a fixed_string object, you will run into problems when constructing from a temporary (because the fixed_string temporary will have been destroyed, invalidating the buffer). Given this, the implementation of these functions are still in fixed_string and thus not accessible to [w]char_string. I have replaced the old implementation with this one in the sandbox if you want to take a look. Also, feel free to adapt it to your version if you want. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 2

Re: [boost] Re: static sized strings
by Reece Dunn 22 Jun '04

22 Jun '04

Rob Stewart wrote: >From: "Reece Dunn" > > John Nagle wrote: > > >Reece Dunn wrote: > > >>John Nagle wrote: > > >>The problems arise in the interation with basic_string_impl and how to > > >>implement swap and functions that require constructing a string >object. > > >Why do you need to construct a string object to swap? > > >Just swap one character at a time. > > > > [2] How do I implement the swap function? The solution I arrived at is >the > > one you suggest: to swap the data character-by-character. What you have >to > >Unfortunately, that makes swap() O(N), but it does allow it to be >nothrow. Unfortunately. To swap the impl members would make it O(1), but would lead to unpredictable behaviour since the two strings swap pointers to their fixed_string buffers. The approach I use is the best I could find. > > consider when doing this is that the strings don't exceed capacity, > > resulting in additional logic. > >That should fail, shouldn't it? Yes, that would mean a swap() >that throws, but the strings aren't really swapped if you only >swap some characters. The same is true though of all the other functions (e.g. assign): what happens if the string doesn't fit? >I'm not sure which is worse: a swap() that throws or only >partially swapping. The former violates exception safety >guarantee assumptions made by other code, but the latter means >that swap() may not really swap, which violates semantics. I have gone for a clip to capacity design for all the fixed_string functions. Thus: fixed_string< 5 > str; str.assign( "Hello there!" ); // str == "Hello" Any error handling policy that is implemented has it's own advantages and disadvantages. Another problem with using exceptions is adapting C code: there may not be any try-catch blocks in the code, resulting in unhandled exceptions. The clip strategy is not ideal either, but I believe it is the best approach considering the code it is abstracting: you will usually have a buffer large enough for the application you are using it for (filenames/paths, command line strings, URLs, etc.) One possibility is making the error handling a policy class so it can be adapted to suit the users needs with the current behaviour as default. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

RE: [boost] [test] [minmax] failure on gcc 2.95
by Rozental, Gennadiy 21 Jun '04

21 Jun '04

> As shown in http://tinyurl.com/3xdyq, > Boost.Test fails to build on gcc 2.95 with stlport. The error > message is: > > /boost/head-regression/boost/boost/minmax.hpp: In function > `const size_t & boost::std_min<size_t>(const size_t &, const > size_t &)': > > /boost/head-regression/boost/libs/test/build/../src/test_tools > .cpp:375: instantiated from here > /boost/head-regression/boost/boost/minmax.hpp:26: `min' > undeclared (first use this function) > > Is it possible that authors of either Boost.Test or > boost/minmax.hpp take care of this error? I'd prefer it to be addressed on minmax.hpp level. After all it's the header responsible for min and max. Gennadiy.

3 3

Typo in boost/graph/properties.hpp
by Janusz Piwowarski 20 Jun '04

20 Jun '04

Hello, I'm attaching patch, as in subject. Also, there isn't undefined variable x in boost/graph/graph_test.hpp (test_readable_vertex_property_graph and test_vertex_property_graph templates). I have no idea what it is. Regards, Janusz

2 1