June 2005 - Boost - lists.boost.org

Re: [boost] Regressions in your Boost libraries as of 2005-06-28
by David Abrahams 28 Jun '05

28 Jun '05

Douglas Gregor <dgregor(a)cs.indiana.edu> writes: > |type_traits| > decay_test: vc-6_5 > extent_test: vc-6_5 > function_traits_test: vc-6_5 > is_abstract_test: vc-6_5 > is_array_test: vc-6_5 > is_const_test: vc-6_5 > is_empty_test: vc-6_5 > is_reference_test: vc-6_5 > is_union_test: vc-6_5 > is_unsigned_test: vc-6_5 > is_volatile_test: vc-6_5 > rank_test: vc-6_5 > remove_all_extents_test: vc-6_5 > remove_bounds_test: vc-6_5 > remove_const_test: vc-6_5 > remove_cv_test: vc-6_5 > remove_extent_test: vc-6_5 > remove_pointer_test: vc-6_5 > remove_reference_test: vc-6_5 > remove_volatile_test: vc-6_5 > tricky_add_pointer_test: vc-6_5 > tricky_function_type_test: vc-6_5 > tricky_is_enum_test: vc-6_5 > tricky_partial_spec_test: vc-6_5 I don't even see these in the table! http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/type_t… What up? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: [boost] Regressions in your Boost libraries as of 2005-06-28
by David Abrahams 28 Jun '05

28 Jun '05

Douglas Gregor <dgregor(a)cs.indiana.edu> writes: > |python| > extract: gcc-3.3.6-linux > list: gcc-3.3.6-linux > operators: gcc-3.3.6-linux > slice: gcc-3.3.6-linux Hi Doug, Didn't you promise these were going to disappear? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[regex] Compiler warnings
by Markus Schöpflin 28 Jun '05

28 Jun '05

Currently I get two warning when compiling regex with gcc-3.2.3 on Tru64 and I think the warnings are justified. The first one is in "basic_regex_parser.hpp" at line 1284 where it complains about a signed/unsigned mismatch. The code in question is "(i > (std::numeric_limits<charT>::max)())" where i is an int and charT=wchar_t is unsigned. Isn't there a conversion missing here? The second one is in "cpp_regex_traits.hpp" at line 970. There is a "BOOST_USE_FACET(std::numpunct<char>, ...)" which I think should read "BOOST_USE_FACET(std::numpunct<charT>, ...)". Markus

2 1

Re: [boost] Boost.config not recognize threading support enabled?
by BRIDGES Dick 28 Jun '05

28 Jun '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On > Behalf Of John Maddock > Sent: Thursday, June 23, 2005 3:04 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Boost.config not recognize threading support enabled? > > > [Dick] My primary reservation about this approach is based upon my > > assumption that the "macro-that-identifies-linux-on-arm" would be an > > attribute of the compiler. I still can't get used to the idea that > > multi-threaded or single-threaded is compiled into the gcc > > cross-compiler itself, while little-endian and big-endian are command > > line switches. %>[ The multiplicity of targets and threading models > > might require a number of such tests that would be difficult to manage. > > Sure? _GLIBCPP_HAVE_GTHR_DEFAULT tells you whether the compiler and std lib > were compiled with threading support or not, as long as the change is > limited to linux on arm, just how many such tests would we need? [Dick] Nope, not sure at all. I overlooked "limited to linux on arm". (At any given time our "build" currently uses six instances of gcc - various PowerPC, x86 look-a-likes, DSPs, etc. - and I'll worry about those later.) Yes, your suggestion to put the test in libstdcpp3.hpp seems like it would work nicely. As a no-longer-lurking newbie, can I do something or do I sit back and wait for someone to add that test? > >> Any closer? > > > > [Dick] I'm of two minds about the following suggestion: it's either a > > kludge or introduces a certain pleasing symmetry. ;) > > > > Since BOOST_DISABLE_THREADS is used to unconditionally disable threads, > > the user-wielded imperative BOOST_ENABLE_THREADS (tested at the same > > place in suffix.hpp) would [almost] unconditionally define > > BOOST_HAS_THREADS - subject only to the existing verification that the > > threading API has been identified and is recognized. > > Or you could just spell your new macro BOOST_HAS_THREADS :-) > No changes needed then. [Dick] Once again I yelled before I was bit. I'm haven't been able to get bjam --v2 to pass BOOST_HAS_THREADS to the compiler so I ass-u-me-D it was some magic cookie that was being #undefD in preparation for use as a flag. Dumb. I'll go back to the boost.build list with this now. Thanks for the mentoring. > John. > [Dick] Regards, Dick

2 1

[dynamic_bitset]bit insertion and extraction from c.l.c++
by Jeff Flinn 28 Jun '05

28 Jun '05

The following is from c.l.c++. "Vince" <vsix(a)caramail.com> wrote in message news:42c02e57$0$27313$626a14ce@news.free.fr... > Hi, > > I would like to extract or insert some values (of different size) inside > a buffer. > I would like to have something like this : > > > BYTE Buffer[207]; > > > CBitAPI bitbuf<Buffer, sizeof(Buffer)>; > > // Extract different data > int version = bitbuf.get(0,4); // Extract 4 bits from bit 0 > int whatever = bitbuf.get(4,2); // Extract 2 bits from bit 4 > bool ack = bitbuf.get(6,1) //Extract 1 bit from bit 6 > > or even better : > > int nValue; > bitbuf.get(4,2, nValue); > > DWORD dwValue; > bitbuf.get(6,4, dwValue); > > > Unfortunately I searched everywhere (boost, google, ) and I didn't found > anything appropriate. > > dynamic_bitset for instance cannot be initialized from an array... It can according to: http://www.boost.org/libs/dynamic_bitset/dynamic_bitset.html#header-files You would use the constructor that takes two input iterators. Since this is a templated constructor, Buffer elements don't have to be 8bit bytes. boost::dynamic_bitset<> bits( &Buffer[0], &Buffer[0] + 207 ); Also see the non-member functions from_block_range,to_block_range and to_ulong that allow transfer from/to integral data types. The latter could be used to create a templated function to implement your desired behavior. // Untested and needs error checking template< typename T, class BITSET > T extract_value( BITSET aBits, size_t aBegin, size_t aSize ) { // implement size assertions here aBits.resize( aBegin + aSize ); return T((aBits<<aBegin).to_ulong()); } I'm surprised that this wasn't available for either std::bitset or boost::dynamic_bitset. Any particular reasons? Would a function with this ability be a useful addition? Certainly a more efficient implementation would be desirable. Jeff Flinn

1 0

[acc][serialization] Boost.Serialization marked as unusable
by JOAQUIN LOPEZ MU?Z 28 Jun '05

28 Jun '05

Hello, Boost.Serialization is marked as unusable for the HP aCC* family of compilers, but a test of Boost.MultiIndex involving serialization seems to work OK in FFT-aCC (http://tinyurl.com/9xsd2, test_serialization), so I understand Boost.Serialization works for this compiler after all. OK to unmark? If nobody does it first, I can do it myself in ~10 hours. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

intrusive list
by Geoff Carlton 28 Jun '05

28 Jun '05

I've just come across the intrusive list class in the sandbox. I've been searching for a class like this for quite some time, but I never thought to look through the boost sandbox area for it. I can finally ditch my own partial implementation and use this nice alternative! One issue I have seen with this class is that it destroys its nodes on list destruction. Previously implementations I have seen instead assert(empty()), leaving it up to the programmer to explicitly decide what to do. In some cases it is indeed to clear the list, but in others it may be to dethread the list and do something else entirely with the nodes. An example is in the common pattern: array<particle> myPool; ilist<particle> activeList; ilist<particle> freeList; Under this scheme the nodes were allocated in the array and then threaded onto their respective lists. As such, automatic deletion would cause a crash, and the programmer should instead just "leak" the list back into the array. Another disadvantage of the destructor calling clear() is that it prevents the node class from having a private destructor. Objects may need to be deleted via a manager class, however the destructor's clear() will cause a compile error in this situation. I find it interesting that under the "move sematics" C++0x proposal, the ilist could be given move sematics and thus fit into STL containers. Is there any ongoing interest in this class, and will it eventually make it into the boost proper? Geoff

2 2

[type_traits] any interest in integral_promotion?
by Alexander Nasonov 27 Jun '05

27 Jun '05

Class template integral_promotion<T> returns promoted type for all types listed in [conv.prom] except bit-fields. For other types it's noop. If you're interested I can try to boostify it. -- Alexander Nasonov // // integral_promotion.hpp // #include <boost/mpl/at.hpp> #include <boost/mpl/eval_if.hpp> #include <boost/mpl/identity.hpp> #include <boost/mpl/or.hpp> #include <boost/mpl/vector.hpp> #include <boost/type_traits/is_enum.hpp> #include <boost/type_traits/is_integral.hpp> #include <boost/type_traits/is_same.hpp> template<class T> struct is_short_integer : boost::mpl::or_< boost::is_same<T, char> , boost::is_same<T, signed char> , boost::is_same<T, unsigned char> , boost::is_same<T, signed short> , boost::is_same<T, unsigned short> > { }; template<int N> struct sized_type { typedef char (&type)[N]; }; sized_type<1>::type tester(int); sized_type<2>::type tester(unsigned int); sized_type<3>::type tester(long); sized_type<4>::type tester(unsigned long); template<class T> struct integral_promotion_impl { static T testee; // undefined typedef typename boost::mpl::at_c< boost::mpl::vector<int, unsigned int, long, unsigned long> , sizeof(tester(+testee)) - 1 // Unary plus ^ promotes testee. >::type type; }; template<class T> struct integral_promotion : boost::mpl::eval_if< boost::mpl::or_< is_short_integer<T> , boost::is_same<T,bool> , boost::is_enum<T> > , integral_promotion_impl<T> , boost::mpl::identity<T> > { }; // // test.cpp // // Tested on gcc 3.4.4 (cygming special) and // Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 #include "integral_promotion.hpp" #include <boost/mpl/assert.hpp> #include <boost/type_traits/is_same.hpp> enum IntEnum { IntEnum_max = 1 }; int main() { BOOST_MPL_ASSERT(( boost::is_same< integral_promotion<char>::type, int> )); BOOST_MPL_ASSERT(( boost::is_same< integral_promotion<bool>::type, int> )); BOOST_MPL_ASSERT(( boost::is_same< integral_promotion<int>::type, int> )); BOOST_MPL_ASSERT(( boost::is_same< integral_promotion<long>::type, long> )); BOOST_MPL_ASSERT(( boost::is_same< integral_promotion<IntEnum>::type, int> )); }

6 16

Boost.Filesystem i18n mini-review
by Beman Dawes 27 Jun '05

27 Jun '05

There will be a mini-review of Boost.Filesystem library's proposed i18n changes from today, Monday, June 27th, until Wednesday, July 6th. A ZIP file which can be unzipped into a regular Boost directory tree is available at http://www.esva.net/~beman/i18n/i18n.zip If you would like to read the documentation online, see http://www.esva.net/~beman/i18n/libs/filesystem/doc/index.htm If you are only interested in changes relative to the current library, see http://www.esva.net/~beman/i18n/libs/filesystem/doc/i18n.html Everything is also available from the Boost CVS on the "i18n" branch. The code has been tested a number of compilers for Windows, Linux, and Mac OS X. For old less compliant compilers, only narrow characters paths are supported. Since this is a major revision, a mini-review gives people a chance to comment well before the changes appear in an actual Boost release. The "i18n" changes won't be merged into the Boost CVS main trunk until after mini-review comments are addressed and Boost 1.33.0 ships, so they won't appear in a release until 1.34.0. Because this is a mini-review of an existing library, the primary focus of reviews should be on the new features and other changes. Comments on existing portions of the library are also of interest. Here are some questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Do you think that this major revision should be accepted by Boost? Be sure to say this explicitly so your other comments don't obscure your overall opinion. Thanks, --Beman PS: For a picture my workspace: http://www.esva.net/~beman/workspace.jpg :-)

1 0

regression test report time
by Fernando Cacciola 27 Jun '05

27 Jun '05

Hi testers, is it at all possible to localize the "time" of the reports to GMT? I'm trying to clean up the mess introduced by the replacement of the old numeric_cast with the new one, but I just can't see if a given test report is current or not (i.e, was run after I commit) TIA Fernando Cacciola SciSoft

4 6