March 2011 - Boost - lists.preview.boost.org

[concept_check] Warning suppression
by Steven Watanabe 16 Mar '11

16 Mar '11

AMDG The attached patch avoids some gcc warnings when the mutable iterator concepts are instantiated with a pointer type. (Operation on 'i' may be undefined) Okay to commit? In Christ, Steven Watanabe

1 0

RE [Boost-announce] [Review] Boost.Type Traits Extension by Frederic Bron
by vijayan 15 Mar '11

15 Mar '11

> What is your evaluation of the design? Overall it is fine. However, I have two suggestions you may want to consider: a. For the assignment operators (for example +=) the name proposed is of the form has_operator_<op>_equal (for example has_operator_plus_equal). Wouldn't has_operator_<op>_assign (for example has_operator_plus_assign) be more intuitive? b. From the documentation: There is an issue if the operator exists only for type A and B is convertible to A. In this case, the compiler will report an ambiguous overload. Couldn't this be mitigated by changing the default for the result type from void to the type as in <functional>? For example: has_operator_unary_minus < class RHS, class RET=RHS > has_operator_minus_assign < class LHS, class RHS=LHS, class RET=LHS > This would take care of most of the normal use cases. > What is your evaluation of the implementation? Good that it is a 'header only' extension. > What is your evaluation of the documentation? Has all that is required. One can start using the library after a few minutes of looking at the documentation. > What is your evaluation of the potential usefulness of the library? Very useful, on those (AFAIK somewhat rare) occasions when it is required. > Did you try to use the library? With what compiler? Did you have any problems? Briefly used it with g++ 4.5.0 on both FreeBSD and Linux. Tested only a few Operator Type Traits, and had no problems whatsoever. > How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A quick reading. > Are you knowledgeable about the problem domain? Not really. I'm just a journeyman programmer who has found the Type Traits library useful in the past. > Do you think the library should be accepted as a Boost library? YES.

4 7

Complier bug taking the address of an instantiated member function template ?
by Edward Diener 15 Mar '11

15 Mar '11

Apologies as this is off-topic, as it refers to C++ and not Boost, but I have run into this working with my TTI library in the sandbox and hopefully some Boost developer has run into this and can tell me whether all compilers are broken or I am doing something completely wrong in my use of C++ syntax: The code: "struct AType { double SomeFunc(int,long *,double &) { double ret(0); return ret; } template<class X,class Y,class Z,short AA> double SomeFuncTemplate(X,Y *,Z &) { double ret(AA); return ret; } }; template < class T > struct TTest { typedef char Bad; struct Good { char x[2]; }; template<T> struct helper; static Good check(helper<&AType::template SomeFuncTemplate<int,long,double,50> > *); static Bad check(...); static const bool value=sizeof(check(0))==sizeof(Good); }; template < class T, class C > struct TTest1 { typedef char Bad; struct Good { char x[2]; }; template<T> struct helper; template<class U> static Good check(helper<&U::SomeFunc> *); template<class U> static Bad check(...); static const bool value=sizeof(check<C>(0))==sizeof(Good); }; template < class T, class C > struct TTest2 { typedef char Bad; struct Good { char x[2]; }; template<T> struct helper; template<class U> static Good check(helper<&U::template SomeFuncTemplate<int,long,double,50> > *); template<class U> static Bad check(...); static const bool value=sizeof(check<C>(0))==sizeof(Good); }; int main() { static_assert(TTest < double (AType::*)(int,long *,double &) >::value, "failure in TTest" ); static_assert(TTest1 < double (AType::*)(int,long *,double &), AType >::value, "failure in TTest1" ); static_assert(TTest2 < double (AType::*)(int,long *,double &), AType >::value, "failure in TTest2" ); return 0; }" Both gcc 4.5.2 ( with -std=c++0x ) and msvc 10.0 put out the static assert "failure in TTest2". I do not see why this is happening. I have no tried clang, but if I could figure out how to use it in Windows I would. Anyone ?

2 2

[XInt] Some after thoughts
by falcou 15 Mar '11

15 Mar '11

Ok, as the ET based rambling went nowhere and some people (especially Steven) had some valid point on the simplicity of the underlying representation, i am about to propose the following plan. The premises still are that I believe that at some point an ET layers is worthwhile. So here it is: 1/ restructure XInt so a generic way to access to the needed internals of the big integer representation through a terse Concept providing way to specify how to store and retirvee bits o. 2/ Build the xinteger_t type on top of this generic layer. Let's stop here. At this point, we fulfill needs expressed by Chad and Steven: a simple and generic large integer library ready to be used. Now this I can see as a very valid candiate to be accepted right now. So now, what's going afterward ? By using the concept and interface, we ( and by we, maybe I mean only me for the moment) can do the following: 3/ implement a EDSL on top of the interface defined in 1/ By reusing the low level memory and computation interface we can build a ET-enabled large integer that behave the same way than the original large integer type in 2/ but allow us to add "fancy" optimisations 4/ Have a way to say large integer use SIMD register of 128 bits and implement a SIMD aware large integer Or any combination of 3+4 or any other similar extension. So, can the effort required by 1/ (definition of a minimal concept for handling representation of large integer) and 2/ seems valid ? I think this actually gives everything to everyone : the simplicity concerned public and the "fancy" public. Of course, the only thing Chad may have to do is 1+2, leaving 3+ to people interested to provide such extension later. How does it sound ?

10 30

[xint] Boost.XInt formal review
by Vladimir Prus 15 Mar '11

15 Mar '11

Boosters, the formal review of the Boost.XInt library, by Chad Nelson, starts now and will run through March 11. The documentation for the current version is available at: http://www.oakcircle.com/xint_docs/ The source code is available via Subversion at: http://svn.boost.org/svn/boost/sandbox/xint or can be downloaded at: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=xint.z… Here are the important points: 1. All comments are appreciated. Even if you don't have the time for in-depth study of everything, comments on parts of the library are welcome. In particular, if you are already using logging in your applications and have specialized requirements, you might want to directly check how the proposed library handles them. 2. The reviews and all comments should be submitted to the developers list, boost(a)lists.boost.org and the email should have "[xint]" prefix in the subject to make sure it's not missed. The deadline for reviews is 23:59, March 11, PST, or 2:59, March 12, EST, or 7:59 March 12, UK time, 10:59, March 12 MSK 3. Please explicitly state in your review whether the library should be accepted. 4. The general review checklist is provided below: - 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? - Are you knowledgeable about the problem domain? Thanks, Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

39 201

[endian] Alternative implementation of endian_flip
by Mike Patterson 15 Mar '11

15 Mar '11

I wrote the attached code years ago. When I noticed the proposed Boost Endian library, I figured now was as good a time as any to share it. My code provides an alternative solution to Beman's boost::integer::endian_flip function that may or may not be a useful improvement. My implementation exposes a single function template, boost::endian::swap, that accepts any type, but only swaps the endianness of 16-bit, 32-bit, and 64-bit types. Features: 1. Slightly more compact. 2. Accepts any type, not just u?int(16|32|64)_t. + This might be useful for unions/structs, e.g., MSVC's LARGE_INTEGER, and when writing function templates. - Decreases the chance that the compiler can identify improper use (e.g., "swap(my_64_bit_object);"). 3. Uses bit shifting/masking instead of a temporary variable. ~ I'm not sure if this is any better or worse from the compiler's perspective. - My 64-bit implementation may not work on older compilers. -Mike

2 1

Conformance issues in Boost.Icl
by Doug Gregor 15 Mar '11

15 Mar '11

Hi all, I've been going through the Boost.Icl test failures for Clang, and there are few conformance issues that should be addressed on the Boost side. The main issue is the test fastest_set_icl_set.cpp, which has some declaration-ordering issues with templates that only Clang seems to diagnose (I've verified that Clang is right). The basic problem, which is repeated in a few places, is that Boost.Icl adds operators and operator templates into namespace boost::icl, e.g., from <boost/icl/concept/element_associator.hpp>: namespace boost{namespace icl { template <class Type> inline typename enable_if<is_associative_element_container<Type>, Type>::type operator + (Type object, const Type& operand) { return object += operand; } } } Now, this operator + can be used with any associative element container, which includes std::set, but only in a context where normal name lookup will find the operator. ADL doesn't help, since the associated namespaces of std::set don't include boost::icl [1]. In the test file fastest_set_icl_set.cpp, that use of the operator comes from the instantiating this macro in <lib/icl/test_laws.hpp>: #define DEFINE_ASSOCIATIVITY_CHECK_WRT(op_tag, op_sign) \ template<class Type, class TypeB, class TypeC> \ void check_associativity_wrt_##op_tag(const Type& a, const TypeB& b, const TypeC& c) \ { \ Type left = (a op_sign b) op_sign c; \ Type right = a op_sign (b op_sign c); \ BOOST_CHECK(left==right); \ } which is instantiated withe op_sign=+ in namespace boost::icl, so name lookup on + looks inside namespace boost::icl and finds the operator+ from earlier. Except that it doesn't, because <lib/icl/test_laws.hpp> is included *before* <boost/icl/concept/element_associator.hpp>. So, the operator+ we wanted isn't visible from the template definition, and isn't visible to ADL during template instantiation, and the code is ill-formed. Moving the inclusion of test_laws.hpp earlier fixes this particular instance of the problem, but there's a more serious one lurking: the header <boost/icl/concept/element_set.hpp> tends to come very early in translation, and has this: template<class Type> inline typename enable_if<is_element_set<Type>, Type>::type operator & (Type object, const Type& operand) { return object &= operand; } which depends on other operator &= definitions in namespace boost::icl that tend to come later (including in headers that #include <boost/icl/concept/element_set.hpp>). I didn't try to detangle these relations, because it's a header ordering issue that requires more knowledge of the library than I have. The right fix is probably to provide forward declarations for these operations in a common header that always gets included very early. Another probably-not-significant issue is that the use of template template parameters whose template parameters have default arguments (in <lib/icl/test/test_interval_quantifier_shared.hpp>) *might* not be well-formed in the standard. The standard is fairly silent on the issue, although the likely resolution of core issue #150 ([3], item #2) does support this usage, and Clang seems to have been the only compiler to get this wrong. Big thanks to Joachim for such an excellent compiler test case :) - Doug [1] Naturally, the template arguments given to set::set might bring boost::icl into scope, but the test we're talking about using std::set<int>. [2] This is a common compatibility issue. See http://clang.llvm.org/compatibility.html#dep_lookup [3] http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#150

2 3

[shared_ptr] ISA issue on MIPS
by Oliver Kowalke 15 Mar '11

15 Mar '11

Hi, as I can read in the archive of the mailing list - several times an issue related to the invalid opcode poped of. It seams that it is not fixed in the current code. MIPS has several ISAs (instruction set architectures) - the file boost/smart_ptr/detail/sp_counted_base_gcc_mips.hpp uses in its inline assembler ll/sc opcode which was added to MIPS II ISA. If you compile boost for MIPS I ISA (which gcc does by default on all LINUX installations I've seen) you get an assembler error like 'opcode not supported on this processor : mips1 (ll/sc)' What about patching sp_counted_base_gcc_mips.hpp to work even if gcc uses MIPS I ISA (see appended patch - others already suggested)? regards, Oliver -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

1 0

[Random] - statistics_test for boost::uuids::detail::seed_rng
by Andy Tompkins 14 Mar '11

14 Mar '11

Hi, I'm trying to determine how well the boost::uuids::detail::seed_rng generates random numbers. I changed (just on my machine) the statistics_test of the random library so that it will also test seed_rng. Sadly I don't really know how to interpret the results that follow. I included the mt19937 results as well. I assume the results are good. Would someone confirm that and maybe tell me how good/bad they are? D:\Code\boost-trunk\libs\random\test>statistic_tests.exe Confidence level: 0.99; 1-alpha = 0.01; chi_square(19, 36.1909) = 0.99 Running tests on seed_rng KS: 15.92 16.4 equidistribution: 19.28 15.84 2D: 27.12 17.6 runs: up: 18 33.04 down: 22.96 11.12 gaps: 23.6 15.68 poker: 15.6 24.32 coupon collector: 17.2 11.76 permutation: 27.92 21.12 maximum-of-t: 24.4 8.48 birthday spacing: 16.4 20.5333 Running tests on mt19937 KS: 21.36 19.2 equidistribution: 22.16 20.88 2D: 29.2 18 runs: up: 16.72 19.04 down: 21.68 37.6* [0.00666986] gaps: 12.72 19.2 poker: 18.48 14.8 coupon collector: 18 11.76 permutation: 17.04 22.8 maximum-of-t: 14.96 22.08 birthday spacing: 19.6 10.6667 Regards, Andy.

2 3

[context] MSVC Build
by Fernando Pelliccioni 14 Mar '11

14 Mar '11

Hi Oliver, I am interested in testing your Context Library. This time I am using MSVC 9 on Windows XP (32-bits). I compiled the library in this way bjam --build-dir="C:\Program Files\boost\boost_1_46_0" --toolset=msvc-9.0 --build-type=complete --with-context stage I need to change your "Jamfile.v2" file because my $(BOOST_ROOT) env variable is set to "C:\Program Files\....". The blank space in the envvar causes an error on copy command. I replaced $(CP) $(>) $(TO) by $(CP) $(>) "$(TO)" I didn't test on Unix. What if I have not set the environment variable BOOST_ROOT? Is it strictly necessary? I send the modified Jamfile.v2. Thanks and regards, Fernando Pelliccioni.

1 0