June 2007 - Boost - lists.boost.org

The Boost development process - an alternative proposal
by Nicola Musatti 08 Jun '07

08 Jun '07

Hallo, The proposals set forth by Beman Dawes and Gennadiy Rozental, and the ensuing discussion, contain many interesting ideas on how to improve our process and avoid the problems faced with 1.34 . However I feel that most of these require a significant effort to be put into practice and are therefore not suitable for dealing with our immediate needs. This is why I felt the need to present an alternative proposal: http://nicola.musatti.googlepages.com/boostprocessproposal Which I believe could be adopted as a starting point. I apologize for the inconvenient location and layout, but I'm in a hurry and Google Pages is currently the only web site I have access to. I plan to move this document to the new Boost wiki as soon as possible. I will be offline for the next couple of days, so please be patient if you don't see any reaction to your feedback. It is welcome indeed! Cheers, Nicola Musatti

1 0

Request for consideration for my weak_ptr class
by Alex Burton 08 Jun '07

08 Jun '07

Hello Boost developers <Class definition below> I understand there would be a collision with boost::weak_ptr, which is used for special scenarios with shared_ptr as I understand. A fair comment would be that this class actually does nothing, that a normal pointer would do and this is true. However, I find it extremely useful, and would like it considered as an addition to boost. It allows my code to be free of the * pointer notation. All pointers look the same, ie shared_ptr<Foo>, scoped_ptr<Foo>, weak_ptr<Foo> It throws an exception if it has been default constructed or set to 0, this could probably be a debug only behaviour for efficiency, but i leave it in release code. It can be used in many places a reference would be used. It includes constructors for many smart pointer types and from a reference to the class pointed to. using namespace std; struct IFoo { }; struct Foo : IFoo { }; vector<Foo> foos; BOOST_FOREACH(weak_ptr<Foo> f,foos) { //do something with f-> } vector< weak_ptr<IFoo> > weakfoos; std::copy(foos.begin(),foos.end(),back_inserter(weakfoos)); In the above code, if vector<Foo> foos was changed to vector< shared_ptr<Foo> > the code will still work perfectly with out change. I find this really useful because often small structs become polymorphic classes (requiring shared_ptr) as code evolves. The vector example is the best, but even when returning a pointer to something like this it is good: struct Bar {}; struct Foo { Bar mBar; weak_ptr<Bar> bar() const { return mBar; } }; if Bar mBar becomes scoped_ptr<Bar> mBar, the accessor still compiles. //Definition starts here namespace alex { class null_weak_ptr_exception : public std::runtime_error { public: null_weak_ptr_exception() : std::runtime_error("null_weak_ptr_exception : dereferencing null pointer") {} }; template <typename T> class weak_ptr { private: T * p; public: weak_ptr() : p(0) {} weak_ptr(weak_ptr const & x) : p(x.p) {} weak_ptr & operator=(weak_ptr const & x) { p = x.p; return *this; } weak_ptr(T * p) : p(p) {} weak_ptr(T & ref) : p(&ref) {} template<class Y> weak_ptr(const alex::weak_ptr<Y> & y) : p(y.get()) { } template<class Y> weak_ptr(const std::auto_ptr<Y> & y) : p(y.get()) { } template<class Y> weak_ptr(const boost::shared_ptr<Y> & y) : p(y.get()) { } template<class Y> weak_ptr(const boost::scoped_ptr<Y> & y) : p(y.get()) { } template<class Y> weak_ptr(const alex::aggregate_ptr<Y> & y) : p(y.get()) { } T & operator*() const { if (!p) throw null_weak_ptr_exception(); return *p; } T * operator->() const { if (!p) throw null_weak_ptr_exception(); return p; } T * get() const { return p; } }; template <typename T> bool operator == (const weak_ptr<T> & x,const weak_ptr<T> & y) { return x.get() == y.get(); } }

2 1

Concurrent async requests
by Владислав Чернышов 08 Jun '07

08 Jun '07

Hi! If I do something like this can I be sure that async requests will run concurrently? boost::asio::io_service io_service; client c(io_service, argv[1], argv[2]); client c1(io_service, argv[1], argv[2]); boost::thread tr1(boost::bind(&boost::asio::io_service::run, &io_service)); io_service.run(); tr1.join(); The client class is a class from boost.asio example. Vlad

2 3

[multi_index] use cases for iterator_to()
by "JOAQUIN LOPEZ MU?Z" 08 Jun '07

08 Jun '07

Hello, More than a year ago a request was made for Boost.MultiIndx to provide the ability to get an iterator to an element x from x alone: iterator iterator_to(const value_type& x); I can provide this functionality in constant time, and the internal implementation is trivial, but I got thinking about the potential use cases for such capability and cannot come up with something convincing. Do you see usefulness in having iterator_to()? Can you describe a potential usage scenario? At first blush, seems like this is at least as useful as the homonym functionality in Boost.Intrusive, but if you think about the obvious scenarios applying to B.I, it turns out they do not immediately translate to B.MI. Thank you! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 6

[thread] - read_write_mutex missing
by Oliver.Kowalke＠qimonda.com 08 Jun '07

08 Jun '07

Hello, I'm missing read_write_mutex in the thread library in boost 1.34. Is there any reason for that? Oliver

3 4

Re: [boost] [function] allocator template parameter question
by Emil Dotchevski 07 Jun '07

07 Jun '07

> Ah, right. I was looking at part of the code where the allocator > wasn't being passed on, but of course that part of the code didn't > need to do any allocation. Two comments:> > (1) Often, one inherits from the allocator rather than storing it > in a member. That way, if the allocator type is empty, we don't need > to use up any storage. Oh sure. What was I thinking? I'll fix this tomorrow. :) > (2) Visual C++ strikes again: we'll have to #ifdef out these > allocator versions for Microsoft's compiler prior to version 7.1, > both because of the reliance on partial specialization of class > templates and because of the use of rebind. I haven't been using older MSVC compilers ever since they released 7.0, and I don't have a 6.0 handy at the moment. If I remember correctly, member function templates don't work on 6.0 so I guess you're right, all the allocator stuff will have to be ifdef'd out. Emil Dotchevski _________________________________________________________________ Hotmail to go? Get your Hotmail, news, sports and much more! Check out the New MSN Mobile! http://mobile.msn.com

1 0

[signals] could last_value<void>::result_type be set to void instead of to last_value<void>::unusable?
by Stjepan Rajko 07 Jun '07

07 Jun '07

Hello, For the default signal combiner last_value, last_value<void>::result_type is currently set to last_value<void>::unusable. On compilers which support void returns, it seems like it would be more beneficial to set it to void instead. I.e., template<> struct last_value<void> { #ifdef BOOST_NO_VOID_RETURNS struct unusable {}; public: typedef unusable result_type; #else public: typedef void result_type; #endif // BOOST_NO_VOID_RETURNS ... I have submitted trac ticket #1043 to this effect with the trivial patch attached, in case this change would be OK. Thanks, Stjepan

1 0

Whats happend Web UI for Soc 2006
by Shams 07 Jun '07

07 Jun '07

Hi, https://www.boost-consulting.com:8443/svn/main/boost/soc/2006/tree/trunk/ I can only see plain old text. Thanks Shams --

2 1

Re: [boost] [function] allocator template parameter question
by Emil Dotchevski 07 Jun '07

07 Jun '07

> On Jun 4, 2007, at 10:57 PM, Emil Dotchevski wrote:> > One important advantage of using boost::function is that it acts > > like a> > function pointer, reducing physical coupling between compilation > > units. This> > is very much like shared_ptr.> >> > A nice feature of shared_ptr is that it has a single template > > parameter, T,> > even though diferent instances of shared_ptr<T> can use different> > allocators.> >> > When using boost::function, one can also provide an allocator, but > > unlike> > shared_ptr, the allocator is a default parameter of the > > boost::function> > class template.> > > Is there a reason why this is necessary? Can't boost::function use > > similar> > technique to the one employed by shared_ptr to avoid the need for this> > second template parameter?> > You know, I never even thought about adding it. I didn't know about > the shared_ptr technique when I put the allocator into > boost::function, and after the C++ committee removed the allocator I > didn't think about it any more. Perhaps if the allocator it's moved to the constructor, the committee would accept it? :) > <snip>> I don't know when I would have time to implement this, although I > would certainly consider adding this functionality to Boost's > "function". Might you be interested in implementing it? OK, I'll give it a shot, and I'll let you know how it goes. Emil Dotchevski _________________________________________________________________ Live Earth is coming. Learn more about the hottest summer event - only on MSN. http://liveearth.msn.com?source=msntaglineliveearthwlm

2 6

[xpressive] "quantifier not expected" exception when using non-capturing group
by Jean-Francois Bastien 07 Jun '07

07 Jun '07

Here is a simplification of my expression: sregex expression = sregex::compile( /* 1 */ "^(" /* 2 */ "c[^\r\n]*(?:\r?\n|\r)" /* 3 */ "(?:" /* 4 */ "(?!c)" /* 5 */ "[^\r\n]*(?:\r?\n|\r)" /* 6 */ ")*" /* 7 */ ")" ); Basically: match lines starting with a "c" and the line that follow, until another line starting with a "c" is found. This gives a "quantifier not expected" exception. Changing line 3 to a normal group solves the problem. Changing lines 2 and 5's groups to normal groups also solves the problem. This expression seems to work fine in PowerGREP. JF

3 4