- Boost - lists.boost.org

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

Fw: Re: [regex]using boost::regex with STLport 5.0 on VS.net
by Wang Weiwei 31 Jan '06

31 Jan '06

Hello, I think there would better be a way to prevent other people - as stupid as me :) - from making the same low-level mistake. The posible solution may be a check of the STLport macros in building with STLport toolsets. Thanks again. Max > > > sorry, the error msg is: > > > > > > BoostTest.obj : error LNK2019: missing symbol "void __cdecl > > > boost::re_detail::raise_runtime_error(class _STL::runtime_error > > > const &)" > > Errors like this usually arise either because: > > 1) You haven't defined __STL_DEBUG when building a debug build (the prebuilt > lib's do this so you have to in order to link to them). However if this is > the case you should have got a #error from the autolinking code telling you > of the problem. YES, I have defined the __STL_DEBUG macro for the debug build. > 2) You're build of Boost did not in fact get built against STLport. Try > taking a peek at the symbols defined in the libraries to see if they're > using _STL or _STLD names (from STLport) or std:: names (from VC++). Also > try building with bjam and the -d2 option so you can see the command lines > generated and verify that all the paths are in fact correct. GREAT! That really helps. Using a text editor, I cannot find _STL or _STLD names in a should-be STLport linked lib, but I can find "std"! Everything gets ok after I adding 2 lines into the build batch file: SET INCLUDE="D:\STLport_50\stlport";%INCLUDE% SET LIB="D:\STLport_50\lib";%LIB% Thank you so much! > > John. > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Patch for slist-related regression errors
by Janusz Piwowarski 31 Jan '06

31 Jan '06

Hi Mingw (gcc >= 3.1.0) has slist in ext subdirectory. I used a workaround I found in boost/config/stdlib/libstdcpp3.hpp . Regards, Janusz

2 1