May 2006 - Boost - lists.boost.org

SOC Project List Now Online
by Jeff Garland 27 May '06

27 May '06

The list of projects is now online at: http://code.google.com/soc/boost/about.html Not really much detail there, but hopefully more coming soon... Jeff

9 11

Re: [boost] Problem with range?
by Martin Bonner 27 May '06

27 May '06

Thomas Witt Sent: > Neal Becker wrote: >> >> With STL we can do: >> int x; >> std::copy (&x, &x+1, output); > > Really? Did you mean to say int x[1]; ? > Surely not. That would be: int x[1]; std::copy( x, x+1, output ); What Neal wrote is perfectly legal. See 5.7 para 4 in the standard: "For the purposes of these operators [+ and -], a pointer to a nonarray object behaves the same as a pointer to the first element of an array of length one with the type of the object as its element type." -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

2 1

Re: [boost] Infinite precision integer draft
by Martin Bonner 26 May '06

26 May '06

From: Maarten Kronenburg > To my knowledge (Aside: I think you mean by that "I am not aware of any evidence to contradict the suggestion that ...". If that is what you mean, "As far as I know ..." would be more idiomatic. Particularly as there is an English idiom "To my *certain* knowledge" which means "I know with absolute certainty that ...". N.B. Your English is already a whole heap better than my Dutch!) > the base type int does not > have a +0 and a -0. > So therefore I see no reason to specify this. C++ can be implemented on a sign and magnitude machine (I believe there are still some around). On such a machine an int can be either +0 and -0. (However I'm pretty sure the standard requires that those two values compare equal) > Derivation is a part of C++, so in my opinion > users must be able to derive from class integer > to make an integer with special properties. I think that would be a mistake. > How would you explain to a user that whatever > he/she does with integer, derivation is not an option, > because the destructor does not happen to be virtual. > This is what it boils down to in the end. They should use containment. > Once again I argue that an unsigned integer is an integer, > and a modular integer is an integer. > An unsigned int is actually a modular int with modulus 2^32. Actually the modulus is not specified. It cannot be smaller than 2^32, but it could be larger. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

2 1

[pqs]Review dates confirmed
by Andy Little 26 May '06

26 May '06

Hi All, the proposed Boost.PQS (Physical Quantities System) library facilitates modelling physical quantities in C++ programs. The Formal Review dates for the review of PQS have now been confirmed... The PQS Formal Review will run from Wednesday 31st of May to Friday 9th of June. pqs_3_1_0 is the Official Boost Review version of PQS. (Please note that pqs_3_1_0 has a bug in one header. This can be either patched according to the latest release notes, "relnotes.txt" available from http://tinyurl.com/7m5l8 or alternatively simply download pqs_3_1_1, which is basically equivalent to pqs_3_1_0, except the bug has been fixed there. Suggestion: Composing a review of the PQS library could be a great way to relax! regards Andy Little

1 0

integral_promotion.hpp problem
by David Abrahams 26 May '06

26 May '06

The macro BOOST_TT_AUX_BOOL_TRAIT_DEF1 is only designed to be used inside namespace boost, but here it is used inside boost::type_traits::detail, causing Borland to complain that there is no definition for the symbol `template_arity' (in that scope). -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 9

[range] workaround metafunction<const Array> under VC7.1
by Shunsuke Sogame 26 May '06

26 May '06

Hi, If you add const-qualification to array type *by hand* when using metafunctions, VC7.1 seems to fail to order partial specialized templates. (VC8 has no problem.) For trivial example, int arr[10]; boost::begin(arr); fails under 1.34.0. He can't find partial specialization for array. I don't know what happens, but the workaround is known. That is, under VC7.1, please prefer the form typename range_metafunction<typename boost::add_const<T>::type>::type to typename range_metafunction<const T>::type everywhere T can be an array type. -- Shunsuke Sogame

1 0

[multi_index] Another weird problem with MI on MSVC 7.1
by Alexei Alexandrov 26 May '06

26 May '06

Hi, I have a problem compiling the code snippet below with MSVC 7.1 (Intel Compiler 9.0 and GCC compile it just fine). The problem trigger is keyword "virtual" in class base inheritance - if you remove it it will compile OK. The error message is very weird: boost\type_traits\is_function.hpp(65) : error C2371: 'boost::detail::t' : redefinition; different basic types boost\type_traits\is_function.hpp(65) : see declaration of 'boost::detail::t' boost\type_traits\is_function.hpp(82) : see reference to class template instantiation '<Unknown>' being compiled boost\tuple\detail\tuple_basic.hpp(310) : see reference to class template instantiation '<Unknown>' being compiled boost\tuple\detail\tuple_basic.hpp(418) : see reference to class template instantiation '<Unknown>' being compiled boost\multi_index\detail\def_ctor_tuple_cons.hpp(33) : see reference to class template instantiation '<Unknown>' being compiled boost\multi_index_container.hpp(140) : see reference to class template instantiation '<Unknown>' being compiled Also, it is critical for reproducing to have 2 independent inheritance chains - if I remove name_record_set2 class and variable it also compiles just fine. Here is the code itself: #include <boost/multi_index_container.hpp> #include <boost/multi_index/mem_fun.hpp> #include <boost/multi_index/ordered_index.hpp> using namespace boost::multi_index; class base {}; class base_record : virtual public base { public: base_record() : id_(0) {} int get_id() const { return id_; } private: int id_; }; class name_record : public base_record {}; class name_record2 : public base_record {}; typedef multi_index_container< name_record, indexed_by< ordered_unique< BOOST_MULTI_INDEX_CONST_MEM_FUN(base_record, int, get_id) > > > name_record_set; typedef multi_index_container< name_record2, indexed_by< ordered_unique< BOOST_MULTI_INDEX_CONST_MEM_FUN(base_record, int, get_id) > > > name_record_set2; int main() { name_record_set ns; name_record_set2 ns2; ns.insert(name_record()); ns2.insert(name_record2()); return 0; } P.S. I use boost from RC_1_34 tag. -- Alexei Alexandrov

3 3

Re: [boost] Infinite precision integer draft
by Martin Bonner 26 May '06

26 May '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Maarten Kronenburg Sent: 26 May 2006 13:09 To: boost(a)lists.boost.org Subject: Re: [boost] Infinite precision integer draft > const integer get_sub( const integer &, const integer & ) const; > By the way here no size_type is used, because > size_type suffices for the range of bytes, > but not for the range of bits, which is a factor > 8 larger. Is that worth worrying about? Even on 32-bit operating systems, a 4 gigabit integer is pretty big. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

3 2

[format] bug and proposed patch
by Joaquín Mª López Muñoz 26 May '06

26 May '06

Edson Tadeu reports on the following post http://lists.boost.org/boost-users/2006/05/19723.php about this bug in Boost.Format: line 138 of boost/format/format_implementation.hpp if( bound_.size()==0 || !bound_[ items_[i].argN_ ] ) can try to invalidly evaluate bound_[...] on vector bound_ with a negative index, which happens when items_[i].argN_ is one of the special values enum arg_values { argN_no_posit = -1, // non-positional directive. will set argN later argN_tabulation = -2, // tabulation directive. (no argument read) argN_ignored = -3 // ignored directive. (no argument read) }; as defined in boost/format/internals.hpp. The attached patches to boost/format/format_implementation.hpp and libs/format/test/format_test3.cpp avoid the invalid negative indexing and add a testcase for the problem, respectively. Any objections to my commiting? If there's no comment I'll be doing it tomorrow. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 138c138 < if( bound_.size()==0 || !bound_[ items_[i].argN_ ] ) --- > if( bound_.size()==0 || items_[i].argN_<0 || !bound_[ items_[i].argN_ ] ) 95c95,102 < --- > > // testcase for bug reported at > // http://lists.boost.org/boost-users/2006/05/19723.php > format f("%40t%1%"); > int x = 0; > f.bind_arg(1, x); > f.clear(); >

1 1

[array] optional constructors in Boost.Array
by Vincent Bherer-Roy 26 May '06

26 May '06

I know that this subject has been discuss a lot in the past. However a quick search in the mailing list archive did not show any solution like the one I propose. If my post is a duplicate, please forgive :-) The problem is that, like many other, I don't use boost::array because it doesn't have any constructor. First, be aware that I want to start a flame war ;-) I understand well the rationale for the aggregate initialization support. I also understand that we want a lightweight wrapper around C arrays. I agree there is a consensus around this and I don't want to break it. However, I have a simple (I think) solution that should give us the best of both worlds. Basically, the idea is to have a third parameter to the template, it is set to false by default in order to provide the same default behaviour. So we have: template<class T, std::size_t N, bool C = false> class array { /* current implementation */ }; template<class T, std::size_t N> class array<T, N, true> : public array<T,N,false> { /* adds constructors only */ }; array<int, 3> a1 = { 1, 2, 3 }; array<int, 3, false> a2 = { 1, 2, 3 }; array<int, 3, true> a3; array<int, 3, true> a4( 1 ); // assign 1 to all three values array<int, 3, true> a5( 1, 2, 3 ); array<int, 3, true> a6( 1, 2 ); // raises a static assert because we try to put only two values in an array of 3 array<int, 3, true> a7( 1, 2, 3, 4 ); // also raises a static assert because we try to put four values in an array of 3 I only see one main drawback with this technique, we'll have some problems with compilers lacking partial specialization support. So the idea is in your hands. I hope it will have some echoes. I attached the modified array.hpp file. It compiles for me on Visual Studio .Net 2003 and 2005 with boost 1.33.1. However I didn't make full test coverage. Thanks Vincent Bherer-Roy

5 13