- Boost - lists.boost.org

[iterator] Idea for "range_from_ref_iterator"
by Ion Gaztañaga 11 Apr '06

11 Apr '06

Hi to all, Trying to simplify containers' code in Boost.Interprocess, I've seen that an iterator that simulates a range of values from a single value is useful to implement functions taking a value and a count in containers: template<class T, class A> class vector { //... void insert (iterator position, size_type n, const T& x); void assign (size_type n, const T& x); }; My intention was to reuse the code for "insert" and "assign" taking iterators to avoid nearly duplicating the code (which is quite complex in vector, deque and basic_string). This way, I've created an iterator called "range_from_ref_iterator" that can be used to implement the "insert" function taking a value and a count like this: void insert (iterator position, size_type n, const T& x) { this->insert(position ,range_from_ref_iterator<const T>(x, n) ,range_from_ref_iterator<const T>()); } This iterator is a random access traversal iterator, that I only would use as read iterator but I'm not sure if it would fill write iterator requirements. The code to implement the iterator: template <class T, class Difference = std::ptrdiff_t> class range_from_ref_iterator : public boost::iterator_facade < range_from_ref_iterator<T> , T , boost::random_access_traversal_tag , T & , Difference> { typedef boost::iterator_facade < range_from_ref_iterator<T> , T , boost::random_access_traversal_tag> super_t; typedef range_from_ref_iterator<T> this_type; //Give access to private core functions friend class boost::iterator_core_access; public: explicit range_from_ref_iterator(T &ref, Difference range_size) : m_ptr(&ref), m_num(range_size){} //This constructor creates a "end" iterator range_from_ref_iterator() : m_ptr(0), m_num(0){} private: T * m_ptr; Difference m_num; void increment() { --m_num; } void decrement() { ++m_num; } bool equal(const this_type &other) const { return m_num == other.m_num; } T & dereference() const { return *m_ptr; } void advance(Difference n) { m_num -= n; } Difference distance_to(const this_type &other)const { return m_num - other.m_num; } }; Do you think this iterator is a good addition to boost iterator library? Obviously it can be more refined. It could take the external value by reference or store a copy depending on the type. But I think it can be useful. I'm open to write the documentation following Boost.Iterator style if this iterator is considered useful (I'm open also to let others do the hard work, of course). Comments? Regards, Ion

3 10

Re: [boost] Report from Berlin C++ Standards Committee meeting
by Reece Dunn 11 Apr '06

11 Apr '06

Maxim Yegorushkin wrote: > On 4/11/06, Reece Dunn <msclrhd(a)hotmail.com> wrote: > > [] > > > The string_to<T> function could have basic_string and wstring overloads, but this would be inconsistent with the rest of the C++ library. > > I don't like the idea of the user having to convert whichever string > he happens to use to std::basic_string just to do the conversion. The overloaded version would look something like: T string_to<T>( const std::string & ) T string_to<T>( const std::wstring & ) T string_to<T>( const std::basic_string< CharT, CharTraits, Allocator > & ) whereas, to be more consistent with the rest of the standard library, you would have something like: T string_to<T>( const std::string & ) T wstring_to<T>( const std::wstring & ) T basic_string_to<T>( const std::basic_string< CharT, CharTraits, Allocator > & ) If the string is not a std::basic_string, then you can have a C-style string overload to not have the conversion: T string_to<T>( const char * ) T wstring_to<T>( const wchar_t * ) this shouldn't be a problem. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

3 2

[archive] Patch for BCB2006
by Nicola Musatti 11 Apr '06

11 Apr '06

Hallo, this is the same as a patch already applied to boost/detail/utf8_codecvt_facet.hpp and as one I just submitted for boost/iostreams/detail/config/codecvt.hpp . Cheers, Nicola Musatti ******Index: codecvt_null.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/archive/codecvt_null.hpp,v retrieving revision 1.13 diff -d -u -r1.13 codecvt_null.hpp --- codecvt_null.hpp 12 Dec 2005 15:22:02 -0000 1.13 +++ codecvt_null.hpp 8 Apr 2006 15:04:18 -0000 @@ -26,7 +26,7 @@ using ::mbstate_t; #elif defined(__QNXNTO__) using std::mbstate_t; - #elif defined(BOOST_DINKUMWARE_STDLIB) + #elif defined(BOOST_DINKUMWARE_STDLIB) && ! defined(__BORLANDC__) using ::mbstate_t; #elif defined(__SGI_STL_PORT) #elif defined(BOOST_NO_STDC_NAMESPACE)

2 3

[intrusive_ptr] Interface consistence with shared_ptr and the lack of reset
by Bertrand Augereau 11 Apr '06

11 Apr '06

Hello, shared_ptr supports reset(), but intrusive_ptr doesn't, which makes porting from one to the other harder than necessary. Is it possible to add it? Thanks, Bertrand [PS : Sorry if I already posted this as a reply to a unrelated thread]

1 0

[Boost-bugs] [ boost-Bugs-1468124 ] VC8 can't find windows.h even though environment is correct!
by SourceForge.net 11 Apr '06

11 Apr '06

Bugs item #1468124, was opened at 2006-04-10 20:14 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=1468124&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: filesystem Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lucas Thode (bsdfan3) Assigned to: Beman Dawes (beman_dawes) Summary: VC8 can't find windows.h even though environment is correct! Initial Comment: VC++ 2k5 Express, Platform SDK for Windows 2k3, "bjam --without-python "-sTOOLS=vc-8_0" --prefix="C:\Program Files\Boost\" install" used to install exception.cpp compilation fails repeatedly due to an inability to find windows.h vsvars.bat is attached ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1468124&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] [thread] monotonic xtime
by Matt Doyle 10 Apr '06

10 Apr '06

> -----Original Message----- > [mailto:boost-bounces@lists.boost.org]On Behalf Of Olaf van der Spek > On 4/10/06, Matt Doyle <mdoyle(a)a-m-c.com> wrote: > > I'd like to second that request, needing to use the win32 > Sleep just kills the portability. My workaround for yielding is - > > > > #if defined _MSC_VER || WIN32 > > # include <windows.h> // for Sleep > > # define MILLI_SECOND_SLEEP(value) (Sleep(value)) > > #else > > # include <unistd.h> // for usleep > > # define MILLI_SECOND_SLEEP(value) (usleep(value * 1000)) > > #endif > > > > but that's just a hack, it really should be in the library. > > Isn't yielding itself a hack? > Shouldn't thread coordination be used instead? If you're waiting for another thread to do something I'd agree. What I run into all the time though is that I want to poll a device every so often so I want to surrender my thread for x amount of time. Scanned by McAfee GroupShield {X3BTB534}

1 0

Using serialization for replication
by prez＠neuromancy.net 10 Apr '06

10 Apr '06

Hey, I want to use serialization for some kind of active replication, however the biggest barrier to this is the fact that serialization does not allow me to put the same object into the stream twice. To be more precise, I want to be able to serialize both to a network and to disk, and I very much like the elegance of the serialization approach (plus the fact it can re-create pointer references, arrays, and such). So my questions are: a) How difficult would it be to be able to allow an object to be serialized twice, where the second copy would more or less do an operator= (instead of creating a new object) on the first copy on deserialization. b) How difficult would it be to have more or less an 'appending' serialization stream - ie. I deserialize what I have previously stored on disk, and then continue to append to the serialization stream (which appends to the file from then on), making my serialization more or less unbounded. c) Is there currently an unbounded serialization stream? I mean, obviously the XML stream will not be 'complete' until you close the serialization stream and it can append any close tags it needs to, however if I wanted to continually write to a stream throughout the time my program is running, and if it crashes, be able to use that to get back to the state I was in, is it possible? I realize that in some respects this is kind of hammering a square peg into a round hole, since serialization seems to have been designed for 'one-short rights', but serialization and replication type functionality is very similar in nature. -- PreZ :) Death is life's way of telling you you've been fired. -- R. Geis

3 8

[1.34] Branch for release
by Thomas Witt 10 Apr '06

10 Apr '06

Hi, unless there are major issues I'd like to branch for release by the end of this week. Please let me know of any outstanding issues that should be resolved prior to branching. Thomas -- Thomas Witt witt(a)acm.org

6 6

Re: [boost] MultiArray warning under /Za
by Sohail Somani 10 Apr '06

10 Apr '06

Ronald, Thanks for changing it. Just to clarify, this is why its happening: typedef int T; int f(int T); <-- using T as a parameter when its previously declared as a type is a no-no under strict conformance(?) I hope that helps. > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Ronald Garcia > Sent: Monday, April 10, 2006 11:16 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] MultiArray warning under /Za > > Hi Sohail, > > Thanks for the information. I have checked in your suggested > patch. > Let me know if that gives you any trouble. > > Cheers, > ron > > On Apr 10, 2006, at 1:41 PM, Sohail Somani wrote: > > > It would have been VC++ 7.1 with boost 1.33.1 > > > >> -----Original Message----- > >> From: boost-bounces(a)lists.boost.org > >> [mailto:boost-bounces@lists.boost.org] On Behalf Of Ronald Garcia > >> Sent: Monday, April 10, 2006 9:29 AM > >> To: boost(a)lists.boost.org > >> Subject: Re: [boost] MultiArray warning under /Za > >> > >> Hi Sohail, > >> > >> Hmm, this warning sounds strange to me. I'm not absolutely > >> sure, but > >> it looks like an incorrect warning on the part of your > >> compiler. What > >> version of Visual C++ are you using? > >> > >> cheers, > >> ron > >> > >> > >> On Apr 5, 2006, at 2:41 PM, Sohail Somani wrote: > >> > >>> Boost 1.33.1 > >>> > >>> In multi_array.hpp: > >>> > >>> struct populate_index_ranges { > >>> multi_array_types::index_range > >>> operator()(multi_array_types::index base, > >>> multi_array_types::size_type extent) { > >>> return multi_array_types::index_range(base,base+extent); > >>> > >>> The parameter name extent seems to be typedef'ed previously. This > >>> results in: > >>> > >>> external\boost\include\boost\multi_array.hpp(46) : warning C4224: > >>> nonstandard extension used : formal parameter 'extent' was > >> previously > >>> defined as a type > >>> > >>> I've changed it in my tree to be extent_. > >>> > >>> Sohail > >>> _______________________________________________ > >>> Unsubscribe & other changes: http://lists.boost.org/mailman/ > >>> listinfo.cgi/boost > >> > >> _______________________________________________ > >> Unsubscribe & other changes: > >> http://lists.boost.org/mailman/listinfo.cgi/boost > >> > > _______________________________________________ > > Unsubscribe & other changes: http://lists.boost.org/mailman/ > > listinfo.cgi/boost > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] MultiArray warning under /Za
by Sohail Somani 10 Apr '06

10 Apr '06

It would have been VC++ 7.1 with boost 1.33.1 > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Ronald Garcia > Sent: Monday, April 10, 2006 9:29 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] MultiArray warning under /Za > > Hi Sohail, > > Hmm, this warning sounds strange to me. I'm not absolutely > sure, but > it looks like an incorrect warning on the part of your > compiler. What > version of Visual C++ are you using? > > cheers, > ron > > > On Apr 5, 2006, at 2:41 PM, Sohail Somani wrote: > > > Boost 1.33.1 > > > > In multi_array.hpp: > > > > struct populate_index_ranges { > > multi_array_types::index_range > > operator()(multi_array_types::index base, > > multi_array_types::size_type extent) { > > return multi_array_types::index_range(base,base+extent); > > > > The parameter name extent seems to be typedef'ed previously. This > > results in: > > > > external\boost\include\boost\multi_array.hpp(46) : warning C4224: > > nonstandard extension used : formal parameter 'extent' was > previously > > defined as a type > > > > I've changed it in my tree to be extent_. > > > > Sohail > > _______________________________________________ > > Unsubscribe & other changes: http://lists.boost.org/mailman/ > > listinfo.cgi/boost > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1