- Boost - lists.boost.org

distance operation (24.3.4)
by Zara 16 Mar '06

16 Mar '06

[This message has been crossposted to boost developers list, it has been done on purpose, as it affects both communities] [Sorry if it comes up twice on Boost] I have detected that the standard declares "distance" template at 24.3.4, as taking two "InputIterator" as parameters. IMHO, the parameters shoudl be "const InputIterator" as they should not be changed by that function. In fact, the version I have seen of STLPORT does implement it like that ("const InputIterator") violating the standard, while DINKUMWARE respects the standard defintion. This has given me some problems when trying to use BOOST libraries with BDS 2006 (which comes with Dinkumware library). The function "size" in boost::iterator_range is declared "const", so that when it calls "std::distance", it will do so with "const IteratorT" parameters. With STLPORT, there will be no problem, as the undelying iterato_traits do not change. But in the case of DINKUMWARE, the underlying iterator_traits change. This is specially evident when IteratorT is [const] char *, which is a valid random access iterator. "size" will call "std::distance" with "[const] char * const" parameters, which are non-valid random iterators. I feel that DINKUMWARE is right in following the standard, but STLPORT is right in following common sense. I suggest making both points of view meet: a standard with common sense, that declares "distance" as operating over "const InputIterator". Best regards, Zara

5 12

Re: [boost] distance operation (24.3.4)
by Martin Bonner 16 Mar '06

16 Mar '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: 16 March 2006 10:24 To: boost(a)lists.boost.org Subject: Re: [boost] distance operation (24.3.4) >> const char * is not a random access iterator because it is not an >> output iterator, therfore not a forward iterator, therefore not a >> bidirectional iterator and therefore not a random access iterator - >> 24.1 >> >> The iterator categories are defined in 24.1, iterator traits is >> simply an aid to deducing that category for a given iterator. As it >> happens, you have found a defect in the standard, that >> itetarator_traits< const T * > reports the wrong category. Of >> course my preferred fix would be to find a better category >> definition so that 24.3.1.2 was correct <g> > > Hold your horses here: surely const char* most certainly *is* a random > access iterator, albeit an immutable one. I don't see anything in > 24.1 that > requires OutputIterator semantics for anything except, well output > iterators :-) > > Waiting to be shot down in flames yours, John. Section 24.1, paragraph 3 says: "Forward iterators satisfy all the requirements of the ... output iterators" On the other hand, paragraph 4 says "A forward ... iterator can ... be ... constant". "Constant iterators do not satisfy the requirements for output iterators". I think there is a clear defect in the standard here. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

1 0

[mpl] multiset_test failure
by Vladimir Prus 16 Mar '06

16 Mar '06

Hello! The multiset_test of Boost.MPL fails on every platform being tested. Example error is: http://tinyurl.com/gdx38 Can somebody look into this? Thanks, Volodya

2 1

[PING] [concept_check] stl_concept_covering
by Vladimir Prus 16 Mar '06

16 Mar '06

Hi, the above-mentioned test fails on all platforms. I did report this two weeks ago, but nothing has changed. Maybe, if nobody has the time to look into it and fix it, we should just remove it, at least from Jamfile? This yellow-everywhere test makes it harder to examine the test matrix for really interesting failures. Thanks in advance, Volodya

1 0

[bitfield] Draft 3 available
by Emile Cormier 16 Mar '06

16 Mar '06

http://boost-consulting.com/vault/index.php?direction=0&order=&directory=bi… Changes: - Added an "initializer type" template parameter to facilitate the use of specialized port types - Added static get / set which does the same as operator T / operator=, respectively, without the need to instantiate a Bitfield. - Turned my previous "Port" example into an actual working mechanism to access memory-mapped I/O ports. I don't intend to include Port in any formal Boost proposals. I just want a concrete working example that demonstates how Bitfield could make use of the proposed <iohw.h> port types in the "Technical Report on C++ Performance". I haven't yet had the chance to analyze the performance of my code compared to hand-written bit manipulations. That will be my next focus. So far, I haven't received any feedback on my bitfield proposal. Please let me know if I'm on the right path, if there's a better way of doing this, or if this is a hopeless cause. :) If it's the latter, I can always post this stuff on The Code Project for those who may want to use it or come up with a better solution. In the end, what I want is a standard(-ish) way of implementing portable bitfields in C++. The lack of interest may be due to what I think is a relatively low number of programmers who deal in "bit twiddling" and, at the same time, make use of Boost. I assume that most bit twiddling for hardware I/O is still done in C. -- Emile Cormier emilecormier(a)mailcan.com

2 3

[bitfield] Appropriate type for rhs shift operand?
by Emile Cormier 16 Mar '06

16 Mar '06

Consider the following snippet: template <uint8_t F, uint8_t L, class T, class R=T&, class I=T&> class Bitfield { BOOST_STATIC_ASSERT( F < 8*sizeof(T) ); BOOST_STATIC_ASSERT( L < 8*sizeof(T) ); BOOST_STATIC_ASSERT( F <= L ); enum { FIRST = F, //!< Position of the first bit LAST = L, //!< Position of the last bit WIDTH = LAST - FIRST + 1, //!< Width in bits of the Bitfield VAL_MASK = (1 << WIDTH) - 1, //!< Mask applied against assigned values FIELD_MASK = VAL_MASK << FIRST //!< Mask of the field's bit positions }; }; What would be the most appropriate type for the F and L template parameters? I had arbitrarily picked uint8_t because I felt that it would big enough for a right-hand-side shift operand (at least until they come up with processors supporting 512-bit registers). But since I static-check the range of these compile-time constants, I don't see the point in constraining them to uint8_t. Is integral promotion performed on the right-hand-side operand of a shift operator? I'm thinking I should use (unsigned int) instead of (unsigned char), in case Bitfield is later extended to support bit manipulations in multi-word data. P.S. I just spotted a problem that I forgot to fix in the latest draft I just uploaded. The problem is with: VAL_MASK = (1 << WIDTH) - 1 With the arm-elf-gcc compiler, I get an error when WIDTH is 32. That line needs to be replaced with: VAL_MASK = ((1 << (WIDTH-1)) << 1) - 1 When WIDTH is 32, (1 << 31) << 1 == 0, so after the subtraction we get VAL_MASK == -1, which is 0xffffffff when interpreted as unsigned. We still get the desired result even though the second shift resulted in an "overflow". -- Emile Cormier emilecormier(a)mailcan.com

1 0

[serialization] Deserialization from XML archives
by Tarek 15 Mar '06

15 Mar '06

Hello, I would like to know how does Boost verify the coherence of the data when deserializing from an XML archive. Any information you can give me will be much appreciated. Thanks ___________________________________________________________________________ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com

1 0

boost shmem issues
by Ryan, Paul L. 15 Mar '06

15 Mar '06

1. named_mutex.hpp has some serious issues on the pthread side including: mp_mut is declared of type sem_t and is expected to be of type pthread_mutex_t The timed_lock function operates a sem_timedwait with a pthread_mutex_t. 2. shared_read_write_mutex.hpp has a possible issue with its exceptions: The exception used is a lock_error which is defined in boost::thread (and not included in shared_read_write_mutex.hpp) vs. using the boost::shmem::lock_exception as is used in all other boost::shmem sync primitives. Paul Ryan and Shumin Wu SAIC

2 1

Re: [boost] [Release 1.34] Supported Compilers
by brangdon＠cix.compulink.co.uk 15 Mar '06

15 Mar '06

In-Reply-To: <drn6le$4d0$1(a)sea.gmane.org> rh_gmane(a)mac.com (Russell Hind) wrote (abridged): > Can't people still working with this just use 1.33.x version of boost? I completely agree. People who won't upgrade VC++ 6 shouldn't expect to upgrade boost. I see no need for "depreciated" here. (I'm speaking as a user who had to stick with VC++ 6 for a long time.) -- Dave Harris, Nottingham, UK.

2 1

[random] uniform_int isn't uniform
by David Benbennick 15 Mar '06

15 Mar '06

Class uniform_int from <boost/random/uniform_int.hpp> is supposed to provide a uniform random integer distribution on a range [min, max]. (See [1].) It doesn't do that. I've attached a demonstration program, random.cc. The program asks uniform_int for integers in the range [0, 780903144], then sorts those integers into 20 equal buckets. If the random integers were uniformly distributed, the buckets would all get about the same number of elements. Instead, the last 5 buckets only get 2/3 as many numbers. To put it another way, in this specific case, uniform_int significantly under-represents the top 1/4 of its range. I've attached a patch to uniform_int.hpp that fixes the problem. References: [1] http://boost.org/libs/random/random-distributions.html#uniform_int

1 0