- Boost - lists.boost.org

Re: [boost] [Review] Fixed Strings review period extended
by Greer, Joe 31 Jan '06

31 Jan '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > Sent: Tuesday, January 31, 2006 10:38 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] [Review] Fixed Strings review period extended > > > std::string str(30, 0); > someoldcapi(&str[0]); > str.resize(str.find(0)); > str.find(...) > . I didn't think strings were guaranteed to be contiguous, or did that get slipped in when I wasn't looking? Joe

3 2

Re: [boost] [Release 1.34] Supported Compilers
by Martin Bonner 31 Jan '06

31 Jan '06

"AlisdairM" <alisdair.meredith(a)uk.renaultf1.com> wrote in message >> I will happily assist library maintainers hunting down and >> eradicating support for older Borland compilers, so long as the most >> recent is supported (until such time that 'most recent' is >> reasonably conforming and no longer auto-deprecated when a new >> compiler is released) > From: Gennadiy Rozental > Sorry I do not follow you logic. Why do we need to support old borland > compiler with new boost release? Lets support new one. So new > compiler users > have 1.34 boost support. Old compiler users will keep using 1.33.1. > > Gennadiy I think you misunderstood what Alisdair said. He offered to help REMOVE support for old borland compilers in new boost releases. The suggestion is that 1.34 supports the latest Borland compiler, but is not cluttered with workrounds for previous Borland compilers. This seems like a good compromise to me. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

3 2

boost equivalents for select1st and select2nd
by Michael Goldshteyn 31 Jan '06

31 Jan '06

It is often the case that one is dealing with key value pairs when using the STL containers. Sometimes, I have found the need to extract either the key or the value from these pairs as part of a call to a standard C++ algorithm. Unfortunatelly, unless one is using the SGI implementation of STL, function objects such as select1st and select2nd are not available. So, I started to look for a boost equivalent and finally found it in the bind library. Here are the mechanisms, with the std prefix omitted for brevity: Given: MyMap mymap; // A map of some key type to some value type MyVector myvector; // A vector of elements either of key type or value type, depending on requirements --- // Copy all keys from the map to the vector, which is assumed to containe elements of key type: // Implementation using select1st, when available (e.g. SGI STL extensions) transform(mymap.begin(),mymap.end(),back_inserter(myvector),select1st<MyMap::value_type>()); // Implementation using boost::bind transform(mymap.begin(),mymap.end(),back_inserter(myvector),boost::bind(&MyMap::value_type::first,_1)); // Copy all keys from the map to the vector, which, in this case, is assumed to containe elements of value type: // Implementation using select2nd, when available transform(mymap.begin(),mymap.end(),back_inserter(myvector),select2nd<MyMap::value_type>()); // Implementation using boost::bind transform(mymap.begin(),mymap.end(),back_inserter(myvector),boost::bind(&MyMap::value_type::second,_1)); --- I hope this helps anyone else that needs similar functionality and doesn't want to reinvent the wheel. Thanks, Michael Goldshteyn

2 2

Re: [boost] Proposal to add smart_ptr to the boost library
by David Maisonave 31 Jan '06

31 Jan '06

"David Abrahams" <dave(a)boost-consulting.com> wrote in message news:<ufyn5wggo.fsf(a)boost-consulting.com>... > "David Maisonave" <dmaisonave(a)commvault.com> writes: > > > "David Abrahams" <dave(a)boost-consulting.com> wrote in message > > news:<874q3ld907.fsf(a)boost-consulting.com>... > >> "David Maisonave" <boost(a)axter.com> writes: > >> > >> > "Daniel Wallin" <dalwan01(a)student.umu.se> wrote in message > >> > news:<drkmls$kb5$1(a)sea.gmane.org>... > >> > >> >> It's in the FAQ: > >> >> > >> >> http://www.boost.org/libs/smart_ptr/shared_ptr.htm#FAQ > >> >> > >> >> Q. Why doesn't shared_ptr use a linked list implementation? > >> >> > >> >> A. A linked list implementation does not offer enough > >> >> advantages > > to > >> >> offset the added cost of an extra pointer. See timings > >> >> page. > > In > >> >> addition, it is expensive to make a linked list implementation > >> >> thread safe. > >> > > >> > > >> > You can avoid having to make the implementation thread safe by > >> > making the pointee thread safe. > >> > >> One of us here understands nothing about the problem. I don't know > >> that much about threading, but I think I have a grip on this issue at > >> least. As I understand the problem, if two neighboring shared_ptr's > >> in a reference-linked chain are destroyed at the same time, they will > >> be modifying the same pointer values simultaneously -- without a lock > >> in your case. I don't see how making the pointee threadsafe is going > >> to help one bit. > > > > > > IMHO, you don't fully understand my propose solution. Please look at > > the current smart pointer locking method: > > http://code.axter.com/smart_ptr.h By using intrusive lock logic, you > > can lock the pointee, and thereby locking all the shared_ptr > > objects. Here's the smart pointer destructor: > > inline ~smart_ptr() throw() > > { > > m_ownership_policy.destructor_lock_policy(m_type); > > CHECKING_POLICY::before_release(m_type); > > m_ownership_policy.release(m_type, m_clone_fct, > > m_ownership_policy); > > CHECKING_POLICY::after_release(m_type); > > } > > > > There's similar logic in constructor and assignment operator. This > > should work on all three main types of reference policies, to > > include reference-link. Do you understand intrusive logic? You need > > to fully understand how intrusive logic works, in order to > > understand the method. > > It sounds like you're saying that, essentially, all the shared_ptrs > that point to the same object share a single mutex, and in your case, > that mutex happens to be embedded in the pointee, which is why you > call it "an intrusive lock." Have I got that right? > > IIUC, the thread-safety problem with reference-linked implementation > isn't that so much that it's hard to achieve -- anyone can use a > shared mutex -- it's that it's hard to make a thread-safe > implementation efficient. That is to say, you pay for the cost of > locking and unlocking a mutex, and there's no way around it (**). > Locking and unlocking mutexes is way more expensive than performing > the lock-free operations used by boost::shared_ptr. That's true. But it's been my experience that the majority of development don't have objects access via multiplethreads or don't run in a multithread environment. In this environment, you're paying additional price for using boost::shared_ptr reference-count logic, but not getting any benefits from it. With a policy base smart pointer, you can pick and choose what's best for paticular requirement, instead of being stuck with a one less than optimal method. > (**) Or so I thought: > http://www.cs.chalmers.se/~dcs/ConcurrentDataStructures/phd_chap7.pdf > seems to contradict that. > > >> > This can be done by using an intrusive lock. > >> > > >> > On my test, reference-link is over 25% faster than > >> > reference-count > >> > logic for initialization. With BOOST_SP_USE_QUICK_ALLOCATOR defined, > > > >> > than reference-link is over 30% faster than reference-count logic > >> > for initialization. I get the above results using VC++ 7.1, and if I > > > >> > use the GNU 3.x compiler, than the difference is even greater in > >> > favor of reference-link logic. > >> > With the Borland compiler, the difference is about 22% > >> > >> Are you claiming that using BOOST_SP_USE_QUICK_ALLOCATOR actually > >> slows boost::shared_ptr down on all these compilers? > > > > Of course not.... > > When you define BOOST_SP_USE_QUICK_ALLOCATOR, that does not just > > increase the performance of boost objects. It increases the > > performance for all object within the translation unit that has the > > define, and that is using allocators. So even though shared_ptr gets > > an increase performance boost, the smart_ptr gets an even greater > > performance boost, which increases the performance ratio. > > Oh, I had no idea you were using the allocator for your > reference-linked smart pointers. I see no mention of that macro in > your header. Where do you use it? Please check out the test code. If you're testing code within the same translation unit, and you declare BOOST_SP_USE_QUICK_ALLOCATOR at the top of the translation unit, then it's going to effect all the code in that translation unit. I don't use BOOST_SP_USE_QUICK_ALLOCATOR in my smart_ptr, any more than boost::shared_ptr uses it in it's header. Not only would it be more difficult for me to compile the code so as to only use BOOST_SP_USE_QUICK_ALLOCATOR for boost::shared_ptr, but it also wouldn't make much sence just to give boost::shared_ptr that advantage, and not do so for the other smart pointers when trying to make a level comparison test.

4 5

Serialization and disctintion between eof and end of archive
by Maciej Sobczak 31 Jan '06

31 Jan '06

Hi, The boost.serialization library seems to use eod-of-stream in the underlying istream object to denote the end-of-archive. This equivalence might make sense with files where the stream is open for a short time and really associated with a single archive, but seems to be cumbersome when used with streams that are supposed to be long-lived (network sessions?) and used for transmission of many separate archives. The problem arises between two applications that want to use serializatioin library for data exchange "on the fly", using network sockets. Small tests have shown that it's not enough for the sender to flush its output streams (although it does result in the archive's data arriving at the destination side). For the archive to be read correctly, the sender needs to entirely close the connection. This indicates that the end-of-stream condition is used to denote end-of-archive in the serialization sense. Taking into account the interface of the serialization library (where the readers are created from streams), where the stream object is syntactically supposed to live longer than the archive, treating eof as eoa is counterintuitive. I really expect this to work for the receiver: std::istream &is = ...; // some input stream, possibly long-lived while (...) { boost::archive::text_iarchive ar(is); // ... } with similar structure on the sender-side. Any thoughts? -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/

2 5

Re: [boost] Proposal to add smart_ptr to the boost library
by David Maisonave 31 Jan '06

31 Jan '06

"Sam Partington" <sam.partington(a)gmail.com> wrote in message news:<546fdb840601310328m7480d265u49afde5a1fd85cfa(a)mail.gmail.com>... > class A > { > public: > A() > : l(m, false) > { > } > > void lock() { l.lock(); } > void unlock() { l.unlock(); } > > private: > mutable boost::mutex m > boost::scoped_lock l; > }; > > void intrusive_ptr_lock(A * p) { p->lock(); }; > void intrusive_ptr_unlock(A * p) { p->unlock(); } > > ... > > smart_ptr<A, copy_on_write_policy<intrusive_lock_policy> > ptr(new A); > > Thats quite a lot of work, though some of the problem with that is > probably down to the way boost::mutexes are handled. I'm still considering adding a lock policy that will only work with reference-count and deep_copy, and that will not require intrusive logic. That would make the usage more generic, but not as efficient as instrusive lock. > std::auto_ptr > std::tr1::scoped_ptr > std::tr1::shared_ptr > boost::cow_ptr ? > boost::copy_ptr ? > > Should be sufficient for most needs? and everyone one of them is a > hell of a lot easier to type than : > > boost::smart_ptr<A, > boost::copy_on_write_policy<boost::intrusive_lock_policy> > > One thing I really like about the current proposed boost::policy_ptr, is that you can do a typedef on the policy. Example: typedef boost::smart_ptr<boost::ref_linked> MySharedPtrRefLnk; MySharedPtrRefLnk::to<Shape> pShape; So if you don't like all that typing, you can just do a typedef for the type you expect to use in your project. My propose smart_ptr doesn't have such an elegant method as the proposed policy_ptr, but it does have the following: typedef smart_ptr_type<copy_on_write_policy<intrusive_lock_policy> > MyCowSyncSmartPtr; MyCowSyncSmartPtr::to<Shape>::type pShape; I plan to take a look at the policy_ptr, to see how they're going about avoiding the ::type part.

1 0

[static_assert] unused test file
by Vladimir Prus 31 Jan '06

31 Jan '06

Hi! The libs/static_assert/test directory has file static_assert_test_fail_9.cpp that's not used in Jamfile. Should this file be removed, or should Jamfile be modified? - Volodya

2 1

Re: [boost] Proposal to add smart_ptr to the boost library
by David Maisonave 31 Jan '06

31 Jan '06

"Peter Dimov" <pdimov(a)mmltd.net> wrote in message news:<010a01c6265b$27cd4040$6507a8c0@pdimov2>... > David Maisonave wrote: > > > Since the current smart_ptr (policy_ptr) class at boost vault is on > > hold, I like to propose adding the following smart_ptr class to the > > boost library: > > > > http://code.axter.com/smart_ptr.h > > smart_ptr& operator=(const smart_ptr& Src) > { > if (m_type != m_type) > { > Src.lock(); > m_ownership_policy.assign(m_type, m_clone_fct, Src.m_type, > Src.m_clone_fct, Src.m_ownership_policy, m_ownership_policy); > Src.unlock(); > } > return *this; > } > > You need a unit test. ;-) Yep. You're absolutely correct. This is also why I wasn't able to duplicate the cycle refernece leak, similar to boost::shared_ptr. I seem to have thrown this bug in, when I was adding lock() logic. I've added a unit test for this specific logic. I still have plenty more to go. Thanks

1 0

Re: [boost] Why does shared_ptr have a public reset() method
by David Maisonave 31 Jan '06

31 Jan '06

"Peter Dimov" <pdimov(a)mmltd.net> wrote in message news:<00f101c62659$d1264990$6507a8c0@pdimov2>... > David Maisonave wrote: > > It's not used internally, so there is no need to make it private. > reset() is > a simple shorthand for swapping your shared_ptr with a temporary > default-constructed one, then destroying the temp. You can also achieve the > same effect by assignment. > > p = shared_ptr<T>(); // same as p.reset() Reading the weak_ptr introduction gave me a misunderstanding of what reset does. I thought reset just release the pointer without deleteing it if it was the last referenced. If it does delete it when it's the last reference, than it does make sense to have it public. > Don't tell me that your smart pointer doesn't support assignment. :-) It not only supports assignment, but it also has the ability to assign to a different policy type. > There is no single canonical use for weak_ptr. It's a versatile tool > that > can be used in every situation that matches the above description. Some > people use for it to break shared_ptr cycles. I just ran a test on this, and it seems that boost::shared_ptr does result in leaving memory leak in cycle logic. However, when I tested my proposed smart_ptr, it does not have this problem. It's able to correctly destroy the objects even in cycles. The proposed boost::policy_ptr also has the same cycle problem like boost::shared_ptr. I don't understand why they're not able to resolve this in the destructor call. Either I'm missing something in my smart_ptr, or there's some extra wacky logic in the boost::shared_ptr that's blocking deletion in cycles. (Which I don't get)

2 1

[Boost-bugs] [ boost-Bugs-1420498 ] Bundled graph properties
by SourceForge.net 31 Jan '06

31 Jan '06

Bugs item #1420498, was opened at 2006-01-31 08:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1420498&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: Bundled graph properties Initial Comment: Bundled properties are supported for vertex and edge properties but not graph properties. Fix it! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1420498&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0