- Boost - lists.preview.boost.org

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

[Boost-bugs] [ boost-Support Requests-957850 ] boost for ARM platform?
by SourceForge.net 21 May '04

21 May '04

Support Requests item #957850, was opened at 2004-05-21 00:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=957850&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost for ARM platform? Initial Comment: mailto:peter.mason@dilithiumnetworks.com is writing ... Sorry if this has been discussed already, but I've only just joined. Something I'm building under an ARM toolchain/devkit requires Boost functionality, and thus needs a porting of boost to ARM platforms. I'm not even familiar with the build tools used to build Boost, so it's a daunting task. Can someone please tell me that such a port has been done already and it's available at XXX? If not, then I'd appreciate some options and guidance. Thanks in advance. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=957850&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

enabling automatic memory leak detection with VC
by Robert Ramey 21 May '04

21 May '04

While investigating shared_ptr serialization, I've come upon the VC method used for detecting memory leaks. I had previously used it as part of MFC and found it very helpful. By including the following at the beginning of one's test program: #define _CRTDBG_MAP_ALLOC #include <stdlib.h> #include <crtdbg.h> struct leak_reporter { static leak_reporter instance; leak_reporter(){ _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); } ~leak_reporter(){ // _CrtDumpMemoryLeaks(); // replaced by the above } }; leak_reporter leak_reporter::instance; The program displays the following in the output window while running under the VC IDE: Detected memory leaks! Dumping objects -> c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {663} normal block at 0x00325480, 24 bytes long. Data: < ,W > C4 2C 57 00 00 00 00 00 FF FF FF FF 00 00 00 00 c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {393} normal block at 0x003261F0, 24 bytes long. Data: < ,W > 94 2C 57 00 00 00 00 00 FF FF FF FF 00 00 00 00 Object dump complete. The sequential number (663 and 393 in this example) can be used to trap the debugger at the original allocation when the test is run the next time. Is this not a worthy idea to be included in the test system - at least for VC? In this way we would get a report of memory leaks every time we ran a test. Robert Ramey

2 1