April 2004 - Boost - lists.boost.org

Serialization. Pointer to constant object.
by Alexey Nikitin 13 Apr '04

13 Apr '04

#include <boost/archive/text_oarchive.hpp> #include <boost/serialization/serialization.hpp> using namespace boost::archive; using namespace boost::serialization; class A { friend class boost::serialization::access; template<class Archive> void serialize(Archive& ar, const unsigned int file_version) {} }; void f1(A const& a, text_oarchive& oa) { oa << a; } void f2(A* a, text_oarchive& oa) { oa << a; } void f3(A const* a, text_oarchive& oa) { oa << a; } Why compiled function f1 and f2 but not f3 ? Regards, Alexey.

1 0

Assignment library: review
by Gennadiy Rozental 13 Apr '04

13 Apr '04

Hi, This is formal review for the assignment library. Library present partial solution for frequent problem of collection initialization. In spite of several implementation issues I incline to accept this submission subject to resolution of Design Issue 1. Design --------------------------------------------- 1. Global operator+= and operator<< I believe defining global operator+= and operator<< is unacceptable (and it is global, cause to be used they require to be brought into space by using statement). I propose to remove it and introduce instead operator+= and implementation in headers dedicated to specific stl containers like this: template <class T, class Alloc> inline insert_assigner<std::list<T,Alloc> > operator+=( std::list<T,Alloc>& c, const typename std::list<T,Alloc>::value_type& v ) { return insert_assigner<std::list<T,Alloc> >( c, v ); } and operator << in appropriate extension headers. 2. Forwarding problem This library is affected by forwarding problem. I do not know how important it is, but may be we should use by-value scheme used by boost::bind? 3. Library doesn't allow to create const collections. Well, I am not sure whether or not it's doable but currently it's not supported Implementation --------------------------------------------- 1. insert_assigner( C& c, const value_type& v ) as well as fixed_size_assigner( const iterator& begin, const iterator& end, const value_type& v ) are unnecessary 2. Should we use Boost::pp to implement insert_assigner, fixed_size_assigner e.t.c. and have configurable limit? 3. Obviously code needs to be refactored into smaller pieces. One header per stl container. Also by default it shouldn't include boost related extensions 4. ~fixed_size_assigner This method may throw an exception. Does it always safe to rely on uncaught_exception call? Could we move this somehow out of destructor? 5. No function template ordering handling Why not use usual trick with extra long parameter? 6. Why not use tuple_insert_assigner for matrix assignment? Wouldn't be safer? 7. Promised support for MSVC 6.0 doesn't seems to work Code --------------------------------------------- 1. Why insert_assigner needs to include <boost/call_traits.hpp> 2. What is make.hpp,template.hpp? 3. I would name insert as append, cause it actually does not support inside the collection and this is after all is assignment library 4. Code comments needs to be removed Tests --------------------------------------------- 1. Tests doesn't seem to perform runtime correctness checks in most cases or rely on assert for checks. It would be preferable to use more graceful error checks. Good job, Gennadiy.

6 20

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