- Boost - lists.boost.org

intrusive_ptr question
by Joe Gottman 21 May '04

21 May '04

The intrusive_ptr contains two functions that allow comparisons between intrusive_ptr<T> and T *. template<class T> bool operator==(intrusive_ptr<T> const & a, T * b); template<class T> bool operator==(T * b, intrusive_ptr<T> const & b); and similar operator!=() functions. I'm curious why the pointer parameters are of type T* and not T const *. Joe Gottman

3 4

[Graph] Recently introduced vc6/7 bugs
by David Abrahams 21 May '04

21 May '04

Some new problems in the Graph library on vc6 and vc7 are breaking the Boost.Python library build. See http://tinyurl.com/2j4nj for details. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

RE: [boost] Re: [license]
by Glen Knowles 21 May '04

21 May '04

> > > > Would this be appropiate too: > > > > // Copyright 2004 Joe Coder. Distributed under the Boost // > Software > > License, Version 1.0, provided this > ^^^^^^^^^^^^^ > > // copyright notice appears in all copies. (See accompanying file > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > // LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) > > > > ? > > The highlighted wording is redundant; the licence itself > already requires that. Citing the FAQ once more, > My understanding was that it might be more then merely redundant, it could be interpreted as more restrictive. Possibly requiring the copyright notice to appear in compiled object code for example. Glen

4 3

Wave/flex_string with VC7.0 + dinkumware (new problem)
by Reece Dunn 21 May '04

21 May '04

I reported that VC7 uses the correct implementation of reverse_iterator, and that this can be detected via BOOST_NO_STD_ITERATOR. Although this compiles, you cannot use reverse iterators. The problem is that the iterator is of the form (const) T *, and this fails because there is not a correct implementation of iterator_traits (due to a lack of partial template specialization) that *is* detected by BOOST_NO_STD_ITERATOR_TRAITS. The solution would therefore be to - in this case - provide an iterator wrapper around a standard pointer so it has the correct Iter::value_type, etc definitions. Is there an iterator_adaptor that provides this within boost? If not, should there be one? I am looking into this and will commit the solution to my iterator_adaptor-style implementation (sandbox/boost/fixed_string/detail/basic_string_impl.hpp). NOTE: If you want to add any of my modifications to the Wave flex_string implementation, feel free, but be warned that I haven't run full tests on it yet and thus there might be bugs in it (especially the pod_xxx --> traits_type::xxx, since these functions have different parameters). Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 2

iterator_adaptor.hpp and python/detail/is_xxx.hpp
by Domenico Andreoli 21 May '04

21 May '04

hi, i'm wondering whether boost/iterator/iterator_adaptor.hpp really needs to include boost/python/detail/is_xxx.hpp or not. it seems this inclusion is not required, removing it does not any harm. i'm asking this because debian packages python headers in package libboost-python-dev and itarator headers in libboost-dev. this (maybe useless) inclusion forces libboost-dev to depend on libboost-python-dev making it useless as separate package from libboost-dev. i'd like to remove this inclusion, at least for what regards the debian packages. i'd be very glad to hear your thoughts about this story. cheers domenico -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

3 4

PING: Lambda Documentation Problem
by Stephan T. Lavavej 21 May '04

21 May '04

About two weeks ago I pointed out a fairly serious factual error in the Boost Lambda documentation, described here: http://lists.boost.org/MailArchives/boost/msg64450.php Stephan T. Lavavej http://nuwen.net

2 1

Re: [boost] Re: static sized strings
by Reece Dunn 21 May '04

21 May '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > > > Currently, this implementation is missing iterator support (and thus all > > basic_string functionality that relies on begin(), end(), etc). This is > > because I am wondering how to map them from the basic_string adaptor to >the > > implementation (knowing that you cannot have const and non-const virtual > > functions). > >Since when can you not have const and non-const virtual >functions? Let me rephrase: class char_string { virtual iterator begin() = 0; virtual const_iterator begin() = 0; // oops! begin already in vtable!! }; > > I have two possible solutions: > > [1] name the const versions cXXX (cbegin(), crend(), etc.) -- the >problem > > with this is that you have 8 virtual functions! I was meaning to modify the above to: class char_string { virtual iterator begin() = 0; virtual const_iterator cbegin() = 0; // ok - cXXX variant }; >You'd have those same eight variations with const and non-const >virtual functions. That's the problem -- too many virtual functions. > > [2] direct to non-const versions and convert to const iterators: > > inline const_iterator begin() const > > { > > return( const_iterator( const_cast< basic_string_impl & >( *this > > ).begin())); > > } > > but I am debating whether this is standards compliant and if it is a >good > > design decision. > >If the object is really const, then this results in undefined >behavior. I have disregarded this idea. > > If there are alternate solutions, I'd like to hear them. > >Use const and non-const virtual functions. ;-) > > > Another possibility would be to construct the iterators from offsets: > > > > inline iterator begin() > > { > > return( get_impl().iter_offset( 0 )); > > } > > inline reverse_iterator rbegin() > > { > > return( reverse_iterator( get_impl().iter_offset( size() - 1 ))); > > } > > > > That way you would only need two functions (iter_offset and > > const_iter_offset). > >But how would the iterator know whether to give const or >non-const access to the elements? iter_offset = non-const access (e.g. begin()) const_iter_offset = const access (e.g. rend() const) class char_string { virtual iterator iter_offset( difference_type ) = 0; virtual const_iterator const_iter_offset( difference_type ) = 0; }; template< class Derived, ... > class basic_string_impl > { public: inline iterator begin(){ return( get_impl().iter_offset( 0 )); } inline const_iterator begin() const{ return( get_impl().const_iter_offset( 0 )); } }; NOTE: it is not necessary for Derived to be implemented with virtual functions, but each function name is unique so if they are virtual there isn't a problem. I have tested this on VC6, VC7, VC71 and BCB and it works :). Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1

Who's in charge of the Mac OS regression machine?
by Joaquín Mª López Muñoz 21 May '04

21 May '04

There are some problems with the output of some tests of mine that do not longer exist. Please contact me for further elaboration (joaquin at tid.es) Thanx in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

condition::notify_[whatever] overhead
by Vadim Senchukov 21 May '04

21 May '04

On Win32 platform both notify_one and notify_all do a lot of work with kernel objects whether there are any threads waiting on condition or no. Can't we eliminate such overhead using pretty simple counter of waitng threads like in code below? Or I've overlooked smth and code has subtle problems? boost::mutex mtx; boost::condition cond; int waiting = 0; ... //waiting in some place boost::mutex::scoped_lock lk( mtx ); ++waiting; while (!pred) cond.wait( lk ); --waiting; //notification in another place boost::mutex::scoped_lock lk( mtx ); if ( waiting ) cond.notify_one();

1 0

RE:RE: [boost] seiralization of shared_ptr
by Robert Ramey 21 May '04

21 May '04

>> template<class Archive, class T> >> inline void load( >> Archive & ar, >> shared_ptr<T> & t, >> const unsigned int /* file_version */ >> ){ >> // object tracking guarantees that pointers are not replicated >> // on loading. >> T * t_new; >> ar >> boost::serialization::make_nvp("px", t_new); >> // if its not the first time, it should be equal to the current pointer >> assert(0 == t.use_count() || t.get() == t_new); >> // assign new pointer or bump reference count as appropriate >> // ???? - what goes here? >> } >> >> Can anybody tell me "what goes here?" >> >> Robert Ramey >I don't see problem where you see it. I ses problem in different place. >How is it possible that t.use_count() != 0? My understanding that before >loading all data is empty and you never actually load the same variable >twice. >struct A { > shared_ptr<user_type> member; > load(...) { > ar >> member; > } >}; >A a1, a2 At this point a1.member.use_count == 0, >ar >> a1; >ar >> a2; ... >Now the real problem lies IMO in a fact that you need to keep map raw ptr - >corresponding shared_ptr. IOW when you got raw ptr and you need to create >shared ptr for it you need to figure out somehow whether you already did >it. If yes you need to make a copy to that shared_ptr. If not create new >and register it. That's the problem. There's no way I can see to create a copy of an existing shared pointer given only the copy to the shared underlying pointer. The current implementation uses object tracking to load the replicated pointer to the shared_count. At that point the loaded shared pointer is connected to any other shared_ptrs that correspond to the underlying shared object. This does not require maintenance of any other ptr/shared_ptr maps which would only replicate the what the serialization library does anyway through object tracking. However, the current method does require either privileged access to shared_ptr and shared_count or some sort of expansion of the interface. I believe this answers the original question you posed:"Why does serialization of shared_ptr require access to shared_count?" Robert Ramey

3 2