April 2006 - Boost - lists.preview.boost.org

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

11 Apr '06

David Abrahams wrote: > "Beman Dawes" <bdawes(a)acm.org> writes: > > * Boost Lexical Cast has been tentatively accepted by the LWG for TR2. > > Was there any discussion of the to_string(x) and string_to<T>(x) > alternative? That would be better than the current lexical_cast, provided that there are also basic_string and wstring vresions, i.e.: to_basic_string< CharT, CharTraits, Allocator >( x ) to_wstring(x) The string_to<T> function could have basic_string and wstring overloads, but this would be inconsistent with the rest of the C++ library. As has been mentioned, the to_string methods will not fail conversion. However, it is unclear what to do with string_to that may fail. There are two possible interfaces: 1. throw an exception on failure, like is currently done with lexical_cast 2. provide a boolean or enumeration for failure type (not-EOS, read-fail, etc.) For the second interface, it has been suggested to use something like: bool string_to<T>(x, ret) where ret is an output reference. However, this doesn't allow for the simple one-line interface that lexical_cast provides. Drawing influence from Python, I suggest that the non-throwing version look like: std::pair<T,bool> string_to<T>(x) allowing: fn( string_to<Object>(object).first ); > I only ask because I remember the issue coming up somewhere before, > and I have never seen a use for lexical_cast that didn't have a string > on one end. Yes. Java, Python and other languages have conversion to strings built in to their framework so classes can provide their own mechanism for converting to a string. In C++, the generic case is 3 lines: std::ostringstream ss; ss << object; fn( ss.str()); compared to the single line above. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

5 6

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

11 Apr '06

Hallo, the enclosed patch works around a problem with BCB 2006. I tested it against bcc 5.8.2, bcc 5.6.4, VC++ 8.0 and g++ 3.4.2 . Cheers, Nicola Musatti ******Index: iterator_range.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/range/iterator_range.hpp,v retrieving revision 1.41 diff -d -u -r1.41 iterator_range.hpp --- iterator_range.hpp 20 Feb 2006 21:15:02 -0000 1.41 +++ iterator_range.hpp 7 Apr 2006 07:55:57 -0000 @@ -262,7 +262,7 @@ if( singular ) return 0; - return std::distance( m_Begin, m_End ); + return std::distance<IteratorT>( m_Begin, m_End ); } bool empty() const

2 3

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

11 Apr '06

David Abrahams wrote: > "Peter Dimov" <pdimov(a)mmltd.net> writes: > > David Abrahams wrote: > >> Jeff Garland <jeff(a)crystalclearsoftware.com> writes: > >> > >>> Sounds good. I am worried that even with the iostream integration > >>> the proposal won't have Doug's one-line wget implementation, but > >>> we'll see. > >> > >> Fortunately, Doug wrote "one slide," not "one line." > > > > std::ifstream is( "http://www.example.com/file.zip" ); > > std::ofstream os( "file.zip" ); > > os << is.rdbuf(); > > > > No proposal required, in principle. > > Except that any code involving an identifier spelled "rdbuf" fails the > "do the obvious thing in an obvious way" test. If the standard had an output operator for an input stream, so that line would be: os << is; :) (This would be equivalent to using is.rdbuf(), hiding that away from the user who isn't familiar with stream buffers and stream implementation details.) - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

[Boost-bugs] [ boost-Bugs-1468789 ] condition::timed_wait doesnt take amount of time to wait
by SourceForge.net 11 Apr '06

11 Apr '06

Bugs item #1468789, was opened at 2006-04-11 12:22 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=1468789&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: threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mike Glassford (glassfordm) Summary: condition::timed_wait doesnt take amount of time to wait Initial Comment: The timed wait method of boost::condition class allows waiting till the time specified in the argument. It does not allow waiting up to specific duration of time. That is, one cant say following: boost::condition condVar; condVar.timed_wait( ..., seconds(10) ); On some platforms waiting till the specified time is not the best idea. An example is Windows. A timed_wait can be called to wait till time 10 seconds ahead of current time. But then system clock is rolled back by 3 hours and variable will wait through those 3 hours. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1468789&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] Report from Berlin C++ Standards Committee meeting
by Reece Dunn 11 Apr '06

11 Apr '06

David Abrahams wrote: > "Reece Dunn" <msclrhd(a)hotmail.com> writes: > > Maxim Yegorushkin wrote: > >> On 4/11/06, Reece Dunn <msclrhd(a)hotmail.com> wrote: > >> > >> 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. > > > > 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 > & ) > > I'm not sure consistency is a virtue in this case. You are right! You just need the generic templatized version that takes a basic_string, as well as overloads for C-style narrow and wide strings. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 1

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

11 Apr '06

David Abrahams wrote: > "Reece Dunn" <msclrhd(a)hotmail.com> writes: > > > Drawing influence from Python, I suggest that the non-throwing version look like: > > > > std::pair<T,bool> string_to<T>(x) > > > > allowing: > > > > fn( string_to<Object>(object).first ); > > How does that draw influence from Python? I was refering to multiple-valued returns. For example: def string_to( object ): return object, was_there_an_error obj, err = string_to( ... ) > That interface doesn't allow for types that can't be default > constructed. > > optional<T> string_to<T>(x) > > seems more likely. That does look better. So in that case, an error would be indicated by the optional<T> return containing null. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

[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

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

10 Apr '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Ulrich Eckhardt snip> > On a related note, why doesn't the threading lib offer any > means to yield for > a certain time? In more than nine out of ten cases, this is > the way I do > things, waiting for a certain point in time - like > Boost.Thread does - is > rather the exception than the rule. 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. Matt Scanned by McAfee GroupShield {X3BTB534}

2 1

[FYI] RCF 0.2
by Jarl Lindrud 10 Apr '06

10 Apr '06

Hi all, I just thought I would announce that I've released v. 0.2 of RCF, a portable C++ IPC framework. It makes extensive use of boost, including Boost.Threads, Boost. Serialization, and the recently accepted asio library, so maybe people on this list will find it of interest :) http://www.codeproject.com/threads/Rcf_Ipc_For_Cpp.asp /Jarl.

7 14

[review assessment] Property tree library
by Thorsten Ottosen 10 Apr '06

10 Apr '06

Dear all, I have studied Marcin Kalicinski's Property tree library and its documentation. (For those who are interested, you may look at the library in the boost sandbox under the property_tree folders.) For a few weeks, Marcin has enhanced and simplified the interface. I now find the library fit for a review. Rewiew Wizzards, please arrange for a slot in the review queue. best regards Thorsten

1 0

boost::noninheritable class (was Re: Sealed C++ class)
by Vladislav Lazarenko 10 Apr '06

10 Apr '06

Hello, dear community. I have uploaded the code to the vault - "Generic Programming/noninheritable.zip" (http://boost-consulting.com/vault/index.php?action=downloadfile&filename=no…) The library, some documentation, examples and MSVC project files are present. It would be great if you will include this small library to official boost distribution. If no, let interested people download and use it anyway. Unfortunately, I can test it only with MSVC 7.1 now. So any help is welcome. Please review. Thank you very much for time taken to read this message and probably the code. Regards, Vladislav Lazarenko.

1 0

MultiArray warning under /Za
by Sohail Somani 10 Apr '06

10 Apr '06

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

2 1

asio review results -- asio accepted
by Jeff Garland 10 Apr '06

10 Apr '06

All - I'm pleased to announce that asio has been accepted into Boost. As usual with a Boost review, the asio review generated plenty of discussion, issues, and controversy. Comments ranged from high praise, including success stories of projects in production, to serious design concerns and issues. On balance, in my judgment, asio provides a generally solid library that is ready for inclusion into the Boost library -- providing key functionality in an area that developers have a strong need. Of course, like anything else, asio is not perfect -- a number of key issues were uncovered during the review. In terms of required changes I'm only going to cite a few: - Fixes to dynamic memory allocation issues - Interface changes to support ipv4 and ipv6 seamlessly at runtime - Improvements to support strongly typed socket interfaces Chris has communicated a couple possible solutions to the memory allocation issue and I'll ask that the interface and other changes for this issue continue to be discussed on the Boost list so consensus can be achieved on the best resolution. Other key improvements that should be explored as future enhancements include: - Possible removal of some of the c-style interfaces - Exploration of higher level iostream integrations - Performance improvements - Improved documentation (wouldn't be Boost w/o this one) Chris has a much longer list of changes garnered from the review and is well on his way to addressing many of them. Note that there were several threads and discussions about performance, which is particularly critical for the domain covered by asio. One of the performance issues is the dynamic memory allocation issue cited above. In general, the reviewers have extremely high expectations here. However, after reviewing the discussion and library it's my belief that many developers will find asio performance sufficient to build significant projects with only the memory allocation changes. I expect Chris will be able to address some of the other performance issues cited by reviewers in asio over time. Once again I'll apologize to the Boost community for the delay in the review results. The delay was entirely due to my own personal scheduling issues and should not reflect on asio in any way. Thanks again to all the reviewers for their effort and especially to Chris for his tremendous effort in bringing asio to Boost! Jeff

6 10

[asio] iostreams support?
by Christopher Kohlhoff 10 Apr '06

10 Apr '06

Hello all, One request that came out of the asio review was that some sort of iostreams support, similar to the existing iostreams example included with asio, should become part of the library's public interface. I'd like to start some discussion on what form iostreams support should take in asio. Here are my ideas so far, which only really cover the highest level. The goals of iostreams support are to: - Support simple use cases. (Does this include servers?) - Abstract away complexities like io_service (aka demuxer), host resolution, etc. In asio's CVS post-review I have changed the socket types to be "strongly typed", e.g.: ip::tcp::socket ip::udp::socket ipv4::tcp::socket etc.. Following this pattern, for protocols that are stream based (like tcp) I plan to include typedefs for iostream objects, e.g.: ip::tcp::iostream For a client-side connection, this could be used as follows: ip::tcp::iostream s("somehost.com", "http"); This would automatically resolve the host and service names, and take care of managing IPv4 or IPv6 protocol independence for you (i.e. it will try all endpoints returned by resolving the host/service until it gets one that works). What lies between this high level interface and the current asio interface? Exactly how much of it is exposed as part of the public interface? I know Jeff Garland has some ideas about integration with streambufs, so I'll let him expand on them. Others please do feel free to jump in. The internals of iostreams is not an area I am familiar with. Cheers, Chris

1 0

Re: [boost] Sealed C++ class.
by Martin Bonner 10 Apr '06

10 Apr '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Sebastian Redl Sent: 07 April 2006 16:14 To: boost(a)lists.boost.org Subject: Re: [boost] Sealed C++ class. > Vladislav Lazarenko wrote: > >> template <typename T> >> class sealed : virtual private sealed_::sealed_impl<sealed, T> >> >> > Interesting idea. Any particular reason why this inheritance is > virtual? > sealed_impl being a template should be rare to duplicate as a base, > and > having no data members or virtual functions, it should be irrelevant > even if it was duplicated. On the other hand, you introduce the > troubles > that come with virtual inheritance. > > Sebastian Redl If I write class Broken : public UniquePerson {}; Then the constructor of Broken has to invoke the constructor of sealed_impl. However the constructor is private, so it can't. The result is a compilation error. The problem is the code: template <typename T1, typename T2> class sealed_impl { friend typename T1; friend typename T2; ... 7.1.5.3 p2 says "[Note: this implies that, within a class template with a template type-parameter T, the declaration friend class T; is ill-formed.]" In other words, you can't do that :-( -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

9 13

[regex] regex_replace_example and the doc
by Shunsuke Sogame 10 Apr '06

10 Apr '06

Hi, I now recall this attractive example's mistake. <libs/regex/example/snippets/regex_replace_example.cpp> line89-90 maybe should be: extern const char* pre_expression = "(<)|(>)|(&)|\\r"; extern const char* pre_format = "(?1<)(?2>)(?3&)"; Thus, <libs/regex/doc/regex_replace.html> highlighted by this cpp is weird. :-) -- Regards, Shunsuke Sogame

3 2