April 2006 - Boost - lists.boost.org

[review] promotion traits - result
by Tobias Schwinger 13 Apr '06

13 Apr '06

Dear Boost community, Alexander Nasonov's Promotion Traits have been accepted conditionally into Boost with 4/4 positive votes. The conditions are - an example must be added to the documentation (plus accompanying source code for the example folder), - the reference should be clarified (cv-qualification, bit fields) - further conditions might arise from the merger with the extended library (TypeTraits) and are subject to synchronization with the library maintainer (John Maddock). Thanks to Alexander for the submission and to our reviewers for their work! Regards, Tobias (Review Manager)

3 2

[config] borland.hpp updated
by Nicola Musatti 13 Apr '06

13 Apr '06

Hallo, I just committed a small change to boost/config/compiler/borland.hpp . This should enable proper regression testing for the latest compiler, 5.8.2 beta. Cheers, Nicola Musatti

1 0

[preprocessor] computed include possible?
by Roland Schwarz 12 Apr '06

12 Apr '06

I am wondering if it would be possible to write a computed include macro that is sufficiently compiler independent? E.e. given a macro #define BOOST_PLATFORM_INCLUDE(hdr) ... definition missing ... which should be usable as: #include BOOST_PLATFORM(foo.h) The effect being win32/foo.h included on one linux/foo.h included on another platform. I have yet figured out a way that can achieve something close, but gcc does not allow to use a parameterized macro. I would be interested if someone has some experience with this. Roland

6 13

intrusive pointer, rationale for preferring shared_ptr instead.
by Ulrich Eckhardt 12 Apr '06

12 Apr '06

http://boost.org/libs/smart_ptr/intrusive_ptr.html says: "As a general rule, if it isn't obvious whether intrusive_ptr better fits your needs than shared_ptr, try a shared_ptr-based design first." I wonder why? Embedding the refcounter into the object seems to me much more natural and performant than adding another free-store allocation which shared_ptr requires. Another related thing is why is there no complementary class to add a refcounter to an object? Something like template<typename ObjectType> struct refcount { refcount(): refs(0) {} ~refcount(){} private: refcount( refcount const&); refcount& operator=(refcount const&); friend void intrusive_ptr_add_ref( ObjectType* o) { static_cast<refcount<ObjectType>*>(o)->add_ref(); } void add_ref() { inc(refs); } friend void intrusive_ptr_release( ObjectType* o) { static_cast<refcount<ObjectType>*>(o)->release(); } void release() { dec(refs); if(!refs) delete static_cast<ObjectType*>(this); } some-integer-type refs; }; (I think that I can't legally inject functions into the surrounding namespace via these friend functions, but maybe there's a workaround and this is just a sketch. ) Uli

5 6

Re: [boost] [multi_index]terminology/design concern
by JOAQUIN LOPEZ MU?Z 12 Apr '06

12 Apr '06

Hello Gennadiy, ----- Mensaje original ----- De: Gennadiy Rozental <gennadiy.rozental(a)thomson.com> Fecha: Miércoles, Abril 12, 2006 7:09 pm Asunto: [boost] [mulit_index]terminology/design concern > 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. >From your description above, seems to me what you understand as an "order" is verily what the index concept (as used in Boost.MultiIndex) tries to model. Basically, an index is an access interface to a set of objects jointly owned by several other indices --in contrast with regular STL containers who own their elements in an exclusive fashion. The problem with the words "view", "order", "index", etc. is that they are badly overloaded. David Abrahams recently objected to the current use of "index" since, for him, this word is customarily used to refer to the distance between an element and the beginning of the container it belongs in (as for instance the argument of std::vector::operator[]). I would have happily used "view" instead of "index" but refrained myself because the term "view" was already used by some view libraries (e.g. Maciej Sobczak's view library at http://www.msobczak.com/prog/publications.html or Gary Powell and Martin Weiser's VTL at http://www.zib.de/weiser/vtl/) with a somewhat different meaning: these views are detached from the elements they're constructed from (so that further changes to the elements may not be reflected back to the view) and may list only some of the elements (filtering views.) At the end I decided on "index" to avoid semantic clashing with preexisting definitions of "view" and because the concept is more or less related to indices as used in relational databases --in fact, the definition of a multi_index_container is kind of reminiscent of the way one declares indices for a relational DB table. "Order" would be a good candidate, except that it's generally tied to fixed-order containers (sets, maps), and Boost.MultiIndex also includes sequence-like constructs. > 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. I'm afraid I'm not quite getting what you mean by "index" in this context. Certainly, the kind of operations you describe can be performed in Boost.MultiIndex by means of so-called "compatible keys" as described in http://tinyurl.com/rouet, so that, for instance, given an ordered index sorted by (last name, first name) one can jump to the records beginning with some given last name. Is this what you're referring to? If so, the only thing I can say is I never thought of these operations as directly related to an index concept. If you could elaborate on your discussion maybe I'll be seeing your point more clearly. Thanks for discussing your concerns, I hope at least I've shed some light on them. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[test] Warnings in test_tools.ipp on CW
by Stefan Slapeta 12 Apr '06

12 Apr '06

In CW tests, I get a lot of warnings like this one: ### mwcc Compiler: # In: ..\boost\test\impl\test_tools.ipp # From: ..\libs\numeric\conversion\test\traits_test.cpp # -------------------------------------------------------- # 161: /* toler_descr = */ va_arg( args, char const* ); # Warning: ^ # expression has no side effect # (included from: # C:\br\boost\boost\test\included\test_exec_monitor.hpp:26 # C:\br\boost\libs\numeric\conversion\test\test_helpers.cpp:19 # C:\br\boost\libs\numeric\conversion\test\traits_test.cpp:29) ...because of these lines: /* toler_descr = */ va_arg( args, char const* ); Maybe this expression could be changed to something else? Thanks, Stefan

2 1

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