- Boost - lists.boost.org

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

Re: Re:Re: [boost] Re: Seriialzation library draft # 18 uploaded to filesection
by JOAQUIN LOPEZ MU?Z 12 Apr '04

12 Apr '04

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Lunes, Abril 12, 2004 9:13 pm Asunto: Re:Re: [boost] Re: Seriialzation library draft # 18 uploaded to filesection > Joaqumn M Lspez Muqoz wrote: > > > push_back() can also throw from the allocator if it runs out of > memory,> so you really need some proper clenaup regardless of the > guarantees> made by copying ops. Dave's suggestion of using RAII > is probably the > > most elegant way to deal with the situation: in my experience, > however,> this sort of scope guards perform worse than a > try{}catch(...){}. Your > > mileage may vary. > > Anything wrong with the following? > [code rewritten using new stack_construct facility] It looks fine to me. Also, please ignore my previous statement about the relative merits of try{}catch(...){} wrt to RAII. The performance gain of the former shows only, it seems to me, when using scope guards. In your case, in which destruction *always* takes place, I doubt anything can beat what you've just written. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re:Re: [boost] Re: Seriialzation library draft # 18 uploaded to filesection
by Robert Ramey 12 Apr '04

12 Apr '04

Joaqumn M Lspez Muqoz wrote: > push_back() can also throw from the allocator if it runs out of memory, > so you really need some proper clenaup regardless of the guarantees > made by copying ops. Dave's suggestion of using RAII is probably the > most elegant way to deal with the situation: in my experience, however, > this sort of scope guards perform worse than a try{}catch(...){}. Your > mileage may vary. Anything wrong with the following? // reserve space on stack for an object of type T without actually // construction such an object template< typename T > struct stack_allocate { T * address() { return static_cast<T*>(storage_.address()); } T & reference() { return * address(); } private: aligned_storage< sizeof(T), alignment_of<T>::value > storage_; }; // construct element on the stack template<class Archive, class T> struct stack_construct : public stack_allocate<T> { stack_construct(Archive & ar){ load_construct_data(ar, address(), 0U); } ~stack_construct(){ address()->~T(); // undo load_construct_data above } }; // sequential container input template<class Archive, class Container> struct archive_input_seq { // archive_input_seq(){} inline void operator()(Archive &ar, Container &s) { typedef BOOST_DEDUCED_TYPENAME Container::value_type type; stack_construct<Archive, type> t(ar); ar >> make_nvp("item", t.reference()); s.push_back(t.reference()); } };

1 0