April 2006 - Boost - lists.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