- Boost - lists.boost.org

iterator_adaptor distance question
by Neal D. Becker 13 Apr '04

13 Apr '04

According to http://boost.org/libs/iterator/doc/iterator_facade.html#minus """ template <class Dr1, class V1, class TC1, class R1, class D1, class Dr2, class V2, class TC2, class R2, class D2> typename enable_if_interoperable<Dr1,Dr2,difference>::type operator -(iterator_facade<Dr1,V1,TC1,R1,D1> const& lhs, iterator_facade<Dr2,V2,TC2,R2,D2> const& rhs); Return Type: if is_convertible<Dr2,Dr1>::value then difference shall be iterator_traits<Dr1>::difference_type. Otherwise difference shall be iterator_traits<Dr2>::difference_type Returns: if is_convertible<Dr2,Dr1>::value then -((Dr1 const&)lhs).distance_to((Dr2 const&)rhs). Otherwise, ((Dr2 const&)rhs).distance_to((Dr1 const&)lhs). """ Is the preference for the former case over the latter intentional? This caused some surprise when I tried to re-implement my cycle_iterator_adapator (a kind of circular buffer adaptor). std::copy (b, a, ...) will do: template<typename _RandomAccessIter, typename _OutputIter> inline _OutputIter __copy(_RandomAccessIter __first, _RandomAccessIter __last, _OutputIter __result, random_access_iterator_tag) { typedef typename iterator_traits<_RandomAccessIter>::difference_type _Distance; for (_Distance __n = __last - __first; __n > 0; --__n) { *__result = *__first; ++__first; ++__result; } return __result; } As I implemented cycle_iterator_adaptor distance_to, it was expecting that given iterators [a,b], you probably want a positive distance from a to b, but the way iterator_adaptors is implemented, it wants a negative distance. Not hard to workaround, but it seemed odd that the default case was inverted, and I wondered if that was really intentional.

2 5

Serialization #18
by Alexey Nikitin 13 Apr '04

13 Apr '04

In files boost/archive/detail/iserializer.hpp and boost/archive/detail/oserializer.hpp use the instruction using namespace boost::serialization; As result in my code including <boost/archive/..._Xarchive.hpp> arised many next errors: ... zmr\fill_region.cpp(53) : error C2872: 'detail' : ambiguous symbol could be 'zmr::detail' or 'boost::serialization::detail' ... I think it is not good idea to use "using namespace ...;" in header files. Regards, Alexey.

1 0

como-win32 configuration change
by David Abrahams 13 Apr '04

13 Apr '04

I note in comeau.hpp: # if defined(_MSC_VER) && _MSC_VER <= 1300 # define BOOST_NO_STDC_NAMESPACE ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # if _MSC_VER > 100 // only set this in non-strict mode: # define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP # endif # endif The indicated line seems completely out-of-place here - it's a library thing, not a compiler thing, and it breaks builds with my compiler. I'm deleting it and checking in. Please let me know if you disagree with this move. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

Boost.Lambda question
by Arkadiy Vertleyb 13 Apr '04

13 Apr '04

Hi all, I am wonderring if there is an easy way to determine the type of a lambda functor, kind of lambda-specific typeof facility. I do realize that the primary purpose of lambda is to create temporary functors to pass to STL algorithms. On the other hand, there are contexts where functors need to be stored, such as in std::set, etc. One might want to use Lambda to generate such a functor, but without knowing its type it would be of limited use (of course one can directly specify the type of such functor, but this would be rather tedious). Has anything been done by anybody in this regard? Thanks, Arkadiy

5 6

passing temporaries to mutating algorithms
by Thorsten Ottosen 13 Apr '04

13 Apr '04

Dear All, I think I have found a safe way to bind a temporary to a const reference and cast away the constness. This means that a temporary can be passed (relatively) safely to an algorithm with a prototype like void foo( T& t ) { // do something with t, but don't store the reference. } for example, we might want to call foo() like vector<int> make_vec(); foo( make_vec() ); but we cannot. Using a little macro, we can say foo( BOOST_LVALUE( make_vec() ) ); assuming these prototypes const vector<int> make_cvec(); const vector<int>& make_crvec(); these uses will fail at ct foo( BOOST_LVALUE( make_cvec() ) ); foo( BOOST_LVALUE( make_crvec() ) ); Comments are welcome. br Thorsten begin 666 lvalue_cast.cpp M#0HC:6YC;'5D92 \:6]S=')E86T^#0HC:6YC;'5D92 \=F5C=&]R/@T*(VEN M8VQU9&4@/&%L9V]R:71H;3X-"@T*=7-I;F<@;F%M97-P86-E('-T9#L-"G5S M:6YG(&YA;65S<&%C92!B;V]S=#L-"@T*+R\@;75S="!N;W0@8F4@<F5J96-T M960-"G9E8W1O<CQI;G0^('9E8R@I#0I[#0H@(" @=F5C=&]R/&EN=#X@=B@@ M,3 L(#$P("D[#0H@(" @<F5T=7)N('8[#0I]#0H-"B\O(&UU<W0@8F4@<F5J M96-T960-"F-O;G-T('9E8W1O<CQI;G0^(&-V96,H*0T*>PT*(" @('9E8W1O M<CQI;G0^('8H(#$P+" Q," I.PT*(" @(')E='5R;B!V.PT*?0T*#0HO+R!M M=7-T(&)E(')E:F5C=&5D#0IC;VYS="!V96-T;W(\:6YT/B8@8W)V96,H*0T* M>PT*(" @('-T871I8R!V96-T;W(\:6YT/B!V*" Q,"P@,3 @*3L-"B @("!R M971U<FX@=CL-"GT-"@T*=&5M<&QA=&4\(&-L87-S(%0@/@T*5"8@;'9A;'5E M7V-A<W0H(&-O;G-T(%0F(')V86QU92 I#0I[#0H@(" @<F5T=7)N(&-O;G-T M7V-A<W0\5"8^*"!R=F%L=64@*3L-"GT-"@T*=&5M<&QA=&4\(&-L87-S(%0@ M/@T*=F]I9"!I<U]L=F%L=65?8V%S=%]S869E*"!4("D@#0I[#0H@(" O+PT* M(" @+R\@5V%R;FEN9SH@4F5A9&UE(0T*(" @+R\@:68@>6]U(&=E="!A;B!E M<G)O<B!H97)E+"!I="!M96%N<R!Y;W4G<F4@=')Y:6YG('1O(&-A<W0@87=A M>2!C;VYS="UN97-S(&9R;VT@80T*(" @+R\@8V]N<W0@;V)J96-T+B!9;W4@ M<VEM<&QY(&-A;FYO="!U<V4@0D]/4U1?3%9!3%5%7T-!4U0H*2!S869E;'D@ M=VET:"!T:&4@<')O=FED960G#0H@(" O+R!A<F=U;65N= T*(" @+R\-"GT- M"@T*=&5M<&QA=&4\(&-L87-S(%0@/@T*=F]I9"!I<U]L=F%L=65?8V%S=%]S M869E*"!4)B I#0I[#0H@(" O+PT*(" @+R\@5V%R;FEN9SH@4F5A9&UE(0T* M(" @+R\@:68@>6]U(&=E="!A;B!E<G)O<B!H97)E+"!I="!M96%N<R!Y;W4G M<F4@=')Y:6YG('1O(&-A<W0@87=A>2!C;VYS="UN97-S(&9R;VT@80T*(" @ M+R\@8V]N<W0@;V)J96-T+B!9;W4@<VEM<&QY(&-A;FYO="!U<V4@0D]/4U1? M3%9!3%5%7T-!4U0H*2!S869E;'D@=VET:"!T:&4@<')O=FED960G#0H@(" O M+R!A<F=U;65N= T*(" @+R\@(" @#0I]#0H-"B-D969I;F4@0D]/4U1?3%9! M3%5%*"!E>'!R("D@7 T**&ES7VQV86QU95]C87-T7W-A9F4H(&5X<'(@*2P@ M;'9A;'5E7V-A<W0H(&5X<'(@*2D@#0H-"@T*=&5M<&QA=&4\(&-L87-S($,@ M/@T*=F]I9"!S;W)T*"!#)B!C("D-"GL-"B @("!S;W)T*"!C+F)E9VEN*"DL M(&,N96YD*"D@*3L-"B @("!C;W5T(#P\(")S;W)T960B.PT*?0T*#0II;G0@ M;6%I;B@@:6YT+"!C:&%R*BH@*0T*>PT*(" @('-O<G0H($)/3U-47TQ604Q5 M12@@=F5C*"D@*2 I.PT*(" @("\O(&-T+65R<F]R.@T*(" @("\O<V]R="@@ M0D]/4U1?3%9!3%5%*"!C=F5C*"D@*2 I.PT*(" @("\O<V]R="@@0D]/4U1? H3%9!3%5%*"!C<G9E8R@I("D@*3L-"B @("!R971U<FX@,#L-"GT-"@`` ` end

5 12

Ok to commit?
by Gennaro Prota 13 Apr '04

13 Apr '04

Sort of administrative question :) I'm going to commit an improved version of dynamic_bitset, in the next days. The version, which is in the sandbox, has finally had Jeremy's approval. My question is: to implement find_first and find_next, two new functions I have added, I use a simple lowest_bit<T> template, which in turn requires integer_log2<T>; so there are two new header files: a) http://tinyurl.com/36zsj b) http://tinyurl.com/2lb26 I think they provide two useful facilities in themselves. Would it be ok to commit them in the boost/ folder? Or should they belong to boost/detail/? Or maybe boost/pending/? -- Genny.

4 5

Serialization #16-18
by Alexey Nikitin 13 Apr '04

13 Apr '04

In file boost/archive/add_facet.hpp from line 23: // does STLport uses native STL for locales? #if (defined _STLPORT_VERSION) && !(defined _STLP_USE_NO_IOSTREAMS) // and this native STL lib is old Dinkumware (has not defined _CPPLIB_VER) # if (defined _YVALS) && !(defined __IBMCPP__) # define BOOST_ARCHIVE_OLD_DINKUMWARE_BENEATH_STLPORT # endif #endif IMHO, this incorrect because in new dinkumware library defined _YVALS and not defined __IBMCPP__. Result of that is error when compile with VC7.1 and STLPort with iostreams. Removing negation before "(defined __IBMCPP__)" is eliminate this problem. Regards, Alexey.

2 1

RE: [boost] regex lib: regex_grep w/ match_posix broken?
by Benzinger, Ralph 13 Apr '04

13 Apr '04

> > Actually, now that I look at the code, should it simply be > > > > < if(((m_match_flags & match_not_null) == 0) && (m_presult->length() == 0)) > > --- > > > if(((m_match_flags & match_not_null) == 0) && (m_result.length() == 0)) > > > > just below the original patch? That _seems_ to work. > > I've no time now, but I'll look into it, thanks, > > John. Thanks. BTW, meanwhile I noticed that it's not as simple as that. Above change helps with consecutive matches, but breaks empty matches, i.e. grepping "a*" over "---" gets stuck in an infinite loop. Ralph

2 3

RTL enhancements
by Arkadiy Vertleyb 13 Apr '04

13 Apr '04

Hi all, I just uploaded an enhanced version of RTL (the relational template library). First addition is a simple indexed set-based table implementation (I am using the old name, and our code is based on the reviewed version of the library. Once Joaquin comes up with the post-review version, we'll modify and upload our code). So far this implementation does not fully utilize all the indexed set capabilities that RTL can benefit from, but we will continue working on this subject. To use the indexed set implementation BY DEFAULT one can define the BOOST_RTL_USE_SET macro. Or the implementation type can be supplied explicitly, as a 4th parameter to the table_info class template, like: #define BOOST_RTL_USE_SET table<table_info< mpl::vector<id, name>, mpl::vector<id> > > t1; // indexed set based table table<table_info< mpl::vector<id, name>, mpl::vector<id>, mpl::vector<mpl::vector<id> >, sorted_strategy> > t2; // sorted vector based table The other additions are mainly based on our discussions with Pavel Vozenilek, and include: Fully redesigned/reimplemented join. ------------------------------------ We decided to get rid of our generic join, and replaced it with a simpler, range join, operator which can be used to join each outer tuple with a range in the inner relation, something like this: equal_join<mpl::vector<c1> >(t1, t2); range_join(t1, t2, lower_bound<mpl::vector<c1> >(), end()); Lambda enabled for the selection operator. ------------------------------------------- Something like this can be specified: selection(t, _1[c1()]==5 && _1[c2()] >=20);// SELECT * FROM t1 WHERE c1=5 AND c2>=20 A couple of things were renamed: BOOST_RTL_COLUMN(name, type); became BOOST_RTL_DEFINE_COLUMN(type, name); // looks more like C++ and rel::tuple became rel::row to avoid collisions with the Boost.Tuple library, that showed up once we started using the indexed set :( (now I am even more against the idea of putting stuff under the boost namespace) The other enhancements to the library and to the documentation to follow. These will include better assertions, serialization, performance estimates, etc. Here is the link: http://groups.yahoo.com/group/boost/files/tables.zip As always, any feedback is most welcome. Best regards, Arkadiy

1 0

Re: [boost] Re: Re: [indexed_set] revised naming proposal
by JOAQUIN LOPEZ MU?Z 12 Apr '04

12 Apr '04

Hi Rob, ----- Mensaje original ----- De: Rob Stewart <stewart(a)sig.com> Fecha: Lunes, Abril 12, 2004 8:58 pm Asunto: Re: [boost] Re: Re: [indexed_set] revised naming proposal > > > Why not just "index::list?" > > > > "list" seems too terse to me. It could lead the reader > > to think it is some sort of container (which is not). Take into > > account the namespace can be populated in the future > > with other containers derived from the main one. > > I suppose in a given use case, a "using boost::index" (or "using > boost::multi_index") may be in force, so it would boil down to > just "list." > > However, neither "index_list" nor "list" really says the right > thing. How about turning it around: list_index? I don't get how list_index is more meaningful than index_list. I mean, index_list is a list (a typelist, actually) of indices (index specifiers, actually). Would you care to ellaborate? (thanx!) [...] > I agree with Thorsten's proposal. "multi_index_container" is > much clearer. I'm recording your opinion (and Thorsten's) My intention is to reach a final decision during this week. > > > from my part here. There's still the pending issue of whether > > to move into boost::container. > > I think the argument that "a" container library has to be the > first one is valid, but was there sufficient consensus that such > a namespace was warranted? If there is consensus, your library > is a perfect candidate. If there isn't, it would be painful to > put your library in the "container" namespace only to rip it out > later. If you don't do it and folks agree it is worthwhile, then > yours would be just one more library to move into the namespace > at that time. > Well, it's all about not wasting effort. Hopefully, some other boosters (and the authors of container libraries in Boost) will jump in and express themselves for a tie-break. Jeff thinks more or less how you do about not going down that road if no one else will follow. On a more philosophical level, I don't quite like the idea of 1st level namespaces per se. IMHO, these are the most plausible justifications for this kind of namespaces: 1. Help avoid pollution of boost namespace. 2. Group libraries semantically affine. 3. Group libraries that will be likely used in cooperation in many programs. As for 1, I don't see any danger of namespace pollution in Boost since libraries are accepted one by one and these things are carefully checked before. As for 3, I don't really think that a program using an indexed_set will get a greater chance of using also multi_array, for instance (on the contraty, I guess the probability will be actually less.) 2 is an aesthetical issue. I don't see any practical benefit from having this kind of grouping. One does not discover new libraries by way of exploring the "sourrounding" namespaces, so to say. If anything, the categorized lib index in Boost serves this purpose well. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1