- Boost - lists.preview.boost.org

[serialization] utf8 test glitch
by Vladimir Prus 14 Apr '04

14 Apr '04

Robert, to make utf8 test pass, I had to apply the attached patch. Seems like there was a typo which manifected itself only on 4-bit wchar_t -- one of the trailing bytes did not have the high bit set, so the facet returned an error. - Volodya

1 0

Re:[boost] Serialization #18
by Robert Ramey 14 Apr '04

14 Apr '04

Alexey Nikitin wrote: >I think it is not good idea to use "using namespace ...;" in header files. I agree - I'll fix it. Robert Ramey

1 0

circular_buffer question
by Neal D. Becker 14 Apr '04

14 Apr '04

I'm looking at circular_buffer. It appears to me that operator[] uses "add", and that "add" only allows a positive value of offset? It is not difficult to allow arbitrary values, and this is very useful. if "position" is the current "m_first" and "allocated" is the allocated buffer size, the index could be calculated: int index (int offset) const { int x = (offset + position) % int(allocated); if (x >= 0) return x; else return x + allocated; }

4 6

Boost Regex Understanding Captures topic
by Edward Diener 13 Apr '04

13 Apr '04

While the documentation for this topic is excellent, the one thing missing, I believe, is that the term "Captures" is never defined. I believe a brief single line at the very top of the topic defining the term would be judicious.

3 3

mirroring boost cvs ?
by Toon Knapen 13 Apr '04

13 Apr '04

We would like to mirror the boost cvs for internal users (in our company). We could of course run a script every night that performs a 'cvs checkout' followed by a 'cvs import'. But this way for instance, the versions of all files in our mirror do not correspond to the version of all files on the official boost trunk. There are also tools out there to do this but this requires that specific daemons are run on the server side (i.e. by sourceforge). Any ideas ? Thanks, toon

2 1

[Patch] iterator/iterator_facade.hpp collides with macros on i386-pc-solaris2.8
by Brad Spencer 13 Apr '04

13 Apr '04

In iterator/iterator_facade.hpp, there are a lot of template arguments that have names like "R1" and "D2". Unfortunately, these "all caps" tokens are fodder for collisions with macros. On i386-pc-solaris2.8, for some reason, "R1" is defined to be "9" (it's some kind of register identification macro) and so instead of: template < . . . , class R1, . . . > we get template < . . . , class 9, . . . > which, of course, doesn't work :) I've attached a patch against 1.31.0 (the trunk for this file) to fix this one file by adding "_type" to the end of all such all-caps names. I have not tested it very well. Perhaps there should be a policy to avoid names that are likely to collide with system macros? Just using mixed case (or lower case) is probably enough. Thanks for the great software! -- ------------------------------------------------------------------ Brad Spencer - spencer(a)infointeractive.com - "It's quite nice..." Systems Architect | InfoInterActive Corp. | A Canadian AOL Company

2 3

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