- Boost - lists.boost.org

Re: [boost] [multi_index] Problems with chained pointers in multi index from 1.34 RC
by JOAQUIN LOPEZ MU?Z 12 Apr '06

12 Apr '06

Hello Alexei, thank you for testing the RC branch before it's out, this certainly helps ship a more robust library! ----- Mensaje original ----- De: Alexei Alexandrov <alexei.alexandrov(a)gmail.com> Fecha: Miércoles, Abril 12, 2006 6:15 pm Asunto: [boost] [multi_index] Problems with chained pointers in multi index from 1.34 RC > Hi, > > my multi_index use case: > * The container contains not objects themselves, but pointers > (shared_ptr-s). > * The objects are noncopyable - they are created by a factory > and only smart > pointers are copied between clients. > * The container has 2 indexes. Indexes are built on const_mem_fn > extractor. > One of the indexes uses a function from a base class. > > It seems that in 1.34 problem with using member function from a > base class is > supposed to be solved, but it causes a regression that you cannot > have pointers > to noncopyable objects in the container. Is this a known issue? No, it is not. Alas I'm rather computer-disabled until next week, so I can't directly try to reproduce the problem, in the meantime I'd be very greateful if you can provide more info on the following: 1. What is the compiler error you're getting? 2. The difference between 1.33.1 and 1.34 is that one of the overloads inside const_mem_fun is now restricted by means of boost::disable_if: typename disable_if< is_convertible<const ChainedPtr,const Class>,Type>::type operator()(const ChainedPtr& x)const { return operator()(*x); } Now, from what you report, seems the restriction is being too much comprehensive. Could you test what is the value of boost::is_convertible< const name_record::Ptr, const name_record >::value on your compiler? If this evaluates to true (or fails to compile), then we've got both an explanation for the problem and a serious issue with boost::is_convertible. I've googled for "is_convertible noncopyable" and found some references about problems with using is_convertible on non-copyable types, but the references are too vague and distant in the past to consider worth referring to. Again, thank you for using Boost.MultiIndex and being such an early tester of the RC branch. Looking fwd to getting your feedback wrt to the questions above. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[mulit_index]terminology/design concern
by Gennadiy Rozental 12 Apr '06

12 Apr '06

Hi, It possible that I just missing something and it was already discussed. But I find the terms used by the library misleading and/or incorrectly used. The library present different views on the same data. Each view is defined by notion of "Index". My understanding if term index is something close to the index at the end of the book. The thing is modeled here I would rather called an "Order". Even more importantly is that I feel the these concepts are kind of mixed into one in library design. I understand that we want multiple Orders for the same data. Each order define a view to the container. Each view present iterators to access this view. Different views have different iterators, which are not comparable in any way. Now for any view (for any order) I may want to have one or more Indexes. Index is something that provides direct(random) access based on some key into view. Index present iterator interface. All indexes for the same order present the same iterator which is a view iterator. Lets consider some example: an address book. We may have different orders defined: 1. City, Last name, First Name order 2. Last name, First Name order 3. Phone number order 4. Time registered order Now each order may have in addition following Indexes defined: 1. City, Last name, First Name a) City Index: jump to the first record in the particular city 2. Last name, First Name a) Last Name Index: jump to the first record with particular last name 3. Phone number order a) Area code Index: jump to the first record with particular area code 4. Time registered order a) Year Index: jump to the first record registered in particular year I see Order and Index as two independent concepts and current model seems to mixing them in one. Regards, Gennadiy

1 0

[1.34] release date?
by Nicola Musatti 12 Apr '06

12 Apr '06

Hallo, when is 1.34 expected to be released? Will the SourceForge CVS blackout influence release plans? I'm asking in order to judge for how much longer I'll be able to work on further Borland 5.8.x patches. Thank you, Nicola Musatti

4 3

[thread] monotonic xtime
by Ulrich Eckhardt 12 Apr '06

12 Apr '06

Hi! An application I'm writing has the special requirement that it be able to handle time-skews gracefully (like e.g. the daylight saving time or a user changing the system time). Using Boost 1.32 (but I think the same applies to later versions) it fails when I do things like this here: xtime xt; xtime_get( &xt, TIME_UTC); xt.sec += 2; thread::sleep(xt); My approach now was to implement TIME_MONOTONIC as already sketched in xtime.hpp, which was pretty straightforward (using timeGetTime() on win32). However, I noticed that this won't work, because things like thread::sleep() implicitly assume that the given time is from TIME_UTC and also only uses that one to compare against - obviously won't work when one is the time since system start and the other the time since 1970-01-01. Two solutions came to mind: 1. Convert TIME_MONOTONIC to TIME_UTC. This is more or less impossible to do reliably because a) timeGetTime() overflows frequently (every 49 days) and b) it requires some kind of fixed point that can be used for conversion, but that point simply does not exist due to the limitations that drove me to implementing TIME_MONOTONIC in the first place. 2. Add the clock type to the xtime structure. This means that every place that a time is determined via xtime_get(), e.g. in thread::sleep(), it uses the same clock type as the supplied object. I think this version makes the most sense, right? Unfortunately this breaks compatibility... 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. Uli

3 3

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