- Boost - lists.boost.org

[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

Re: [boost] Spinal Tap (WAS: Religious sensibility (WAS: RE: [XInt] CoW/Move Timings))
by Troy Straszheim 14 Mar '11

14 Mar '11

On Mon, Mar 14, 2011 at 9:53 AM, Mika Heiskanen <mika.heiskanen(a)fmi.fi> wrote: > > Once I started reading the list of like-minded bands, I kind of expected > to see Spinal Tap in there. > That works remarkably well in the subject line...

1 0

[config] Unable to locate boost main tree
by Belcourt, Kenneth 14 Mar '11

14 Mar '11

Hi John, I have an up to date copy of boost trunk on a new machine (u233) running RHEL 6.0 kernel (Santiago). You can see the results on the trunk page under Ornl-intel-11.1.064. For some reason the configure script is having trouble locating the boost main tree. I tried adding --with-boost=... to no avail. Is this a recent problem or perhaps this is the first attempt under 6.0? Any ideas? -- Noel [bkn@u233 config]$ ./configure *** ./configure: boost configuration utility *** Please stand by while exploring compiler capabilities... Be patient - this could take some time... Note that this test script only gives an approximate configuration - you will need to test the results carefully using the boost regression test suite before using the results. *** Info : .cpp used as extension for tests checking for boost main tree... not found configure: error: The boost main tree was not found. Specify its location by the --with-boost option.

3 8

[design] policy based. Was: [XInt] Review
by Joachim Faulhaber 14 Mar '11

14 Mar '11

2011/3/10 Chad Nelson <chad.thecomfychair(a)gmail.com>: > On Wed, 9 Mar 2011 19:11:31 +0100 > Joachim Faulhaber <afojgo(a)googlemail.com> wrote: > >> This is my review on the XInt library. [...] > > Thank you for the review, and the comments. Thank you for your replies and questions [...] >> 2.3 Policy based design >> ======================= >> >> I think policy based design is a very good and powerful technique that >> is specifically useful to separate implementation variants of class >> templates in clear and flexible ways. Unfortunately I can not see that >> you are actually using policy based design here. Because your design >> lacks typical policy classes that encapsulate implementation variants >> in a way that reduces codereplication and enhances flexibility. [...] > > As I'm not sure what kind of implementation you're thinking of, I can't > respond to this. So far as I can tell, my design is doing what you > describe for policy-based design. > >> There is a great deal of code replication in the current >> implementation of xint::integer_t. [...] This skeleton (and some >> variations of it) occurs over and over again only to propagate the >> call of the function to the implementing class at positions #1 and #2. > > integer_t handles some options, and passes the data to the implementing > class for others. It was the best solution I could find to handle all > options. Trying to be consistent with my own request ... >> "At the same time I'd like to call on the boost community to support >> Chad and to see an Integer library as an opportunity to develop more >> common understanding how a state of the art generic design looks like >> in this specific case." ... I invested some work to make my suggestion about good design more concrete. I will give you a small example of a policy based design that is directly related to some problems of code replication and insufficient separation of concerns in your library. At the same time I hope it'll help to understand policy based design, which includes getting a better understanding for myself. The only source of PDB that I've been using so far is Andrei's book from 2001. [Andrei Alexandrescu 2001, Moden C++ Design] But I found the page on wikipedia informative as well. http://en.wikipedia.org/wiki/Policy-based_design Maybe others can contribute more good sources, I did not research. Andrei's book has been really enlightening for me. I've never read a book about programming with so much delight. I can highly recommend it. As for the example. I picked one aspect of your design, the option for nothrow, that controls the handling of nan. Here I've criticized code replication in your code like if (Nothrow) {if (b.is_nan()) ... if (!is_nan()) { ... }} else {...} that reoccurs a lot in the implementation of integer_t. Using policy based design, we try to encapsulate all aspects of the code that relates to the handling of nans in a policy class. So we try to separate the concern "handling nan" from other parts of a class. In this case aint (not xint ;) //========================================================= // Using policies, we want to handle nan in a "nany" or // a "manly" way (manly: ignore it all together) struct nany; // Takes care for the nasty nan struct manly; // No, we don't want this template<class, class> class aint; // a int with nan policy // Meta function for naniness. template<class Type> struct is_nany { static const bool value = false; }; template<class Rep> // a int with nany policy is_nany struct is_nany<aint<Rep, nany> > { static const bool value = true; }; template<class Type> bool is_nan(Type const& value) { // Not perfect ... ok. for the example return value ==( numeric_limits<Type>::has_quiet_NaN ? (numeric_limits<Type>::quiet_NaN)() : (numeric_limits<Type>::max)() ); } // An int class with NaNPolicy: Rep is supposed to be some // integer implementation, including limitless integers // NaNPolicy encapsulates nan-handling. template<class Rep, class NaNPolicy = manly> class aint // no sunshine when she's gone { public: aint(): _value(){} aint(Rep const& val): _value(val){} aint& operator += (aint const& y) { NaNPolicy::plus_assign(_value, y._value); return *this; } Rep value(){ return _value; } private: Rep _value; }; // Finally two different NaN-policy classes struct nany { template<class Rep> inline static void plus_assign(Rep& x, Rep const& y) { if (is_nan(x)) ; else if(is_nan(y)) x = y; else x += y; } }; struct manly { template<class Rep> inline static void plus_assign(Rep& x, Rep const& y) { x += y; } }; BOOST_AUTO_TEST_CASE(nan_policy_study) { // No NaN protection aint<long> ago; // A no throw int with NaN protection aint<short, nany> sun(2); aint<short, nany> shine(7); sun += shine; cout << sun.value() << endl; // I is generic because it is suitable for all kinds of // integer types Rep including say xint::integer_t types aint<xint::integer, nany> ax_i; } //========================================================= 1. Encapsulation: The code necessary for the handling of nans is either encapsulated in the policy class, or it uses some meta code that is globally available. 2. Non intrusive: This code does not require changes in the class Rep, that implements the basic semantics. 3. Generic: So, apart from very little code around the existence and test of the NaN-element, the policy based design works for all integer implementations Rep that are model of a common integer concept, which is implicitly given in this case. 4. Abstraction: Moreover separation of concerns leads to abstraction here. We discover that this kind of "nan closure" not only works for integers but also for floting point numbers or continuous numbers like e.g. boost::rational. Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

3 5

[parameter] Compile-time performance
by Domagoj Saric 14 Mar '11

14 Mar '11

I have an in-house framework a part of which is very similar to Boost.Parameter so I tried to refactor it to use Boost.Parameter and, unfortunately, noticed a big compile-time hit (the project has a very large number instantiations of class templates with 'named non-type template parameters'). With my code (and MSVC++ 10) build time was ~56 seconds with a maximum cl.exe memory allocation size of ~720 MB. After switching to Boost.Parameter build time whent to ~2:24 seconds with a maximum cl.exe memory allocation size of ~815 MB. The most likely suspect is the usage of a forward-sequence for parameter type storage (argument packs) from which you fetch passed parameters using key-based lookup with the value_type<> metafunction. In my code I use an associative container (mpl::map) for the task which has a 'natural'/'efficient' key-based lookup... To confirm this I minimally changed the Boost.Parameter-based version of my code only to use mpl::maps instead of Boost.Parameter ArgumentPacks and built time fell to ~58 seconds...(true, this does not have all the compile-time check for correct usage and concept validation that ParameterSpecs and ArgumentPacks have but I'd expect this to have a much smaller effect than key-based lookup on a forward sequence)... Is there an inherent issue that forbids the use of an associative container for ArgumentPacks or can this be fixed? -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

3 6

xint review is closed
by Vladimir Prus 14 Mar '11

14 Mar '11

Boosters, the formal review of XInt library is now officially closed. Thanks for everybody for comments. Of course, it's fine to let ongoing discussion lead to conclusion, and I'll be watching those discussions. The review was relatively heated, and many experienced folks expressed radically different opinions. Therefore, coming up with yes/no result is not easy, and won't happen overnight. Instead, I plan to summarize on the issues raised by March 21, Monday to see whether we all are on the same page at least about issues, and then come up with final review result by March 28. Thanks, Volodya

2 1