March 2011 - Boost - lists.boost.org

OK to remove Concept related config macros?
by John Maddock 16 Mar '11

16 Mar '11

I notice we have some Boost.Config macros related to C++0x concepts, except of course concepts are no longer part of C++0x... anyone object if I remove these along with their associated tests? Regards, John.

7 9

is_base_of: bug in trunk, not in sandbox
by Frédéric Bron 16 Mar '11

16 Mar '11

Thanks to Christopher Jefferson, I discovered a bug in the trunk (in fact in 1.46.0) for is_base_of in the type_traits library. is_base_of<int, int>::value should be true according to the doc: "is_base_of<Base, Base>::value is an integral constant expression that evaluates to true: a class is regarded as it's own base. However the following program prints 0 and not 1 with g++ 4.4.5 on linux: #include <boost/type_traits/is_base_of.hpp> #include <iostream> int main() { std::cout<<::boost::is_base_of<int, int>::value<<'\n'; return 0; } Using the sandbox version of is_base_of works just fine. This makes my type trait extension fail on 6 tests when using only the trunk (for the 6 comparison operators). I have a workaround for my extension which is to add "or is_same<T, U>" but it would be better if is_base_of would work correctly. Frédéric

5 8

Looking for a speaker
by Sergey Razin 16 Mar '11

16 Mar '11

Hello! Perhaps not on a topic of a particular library, but as a contributor to boost as well as big fan of opensource I felt it would be appropriate to post this request here. One of the largest in southeast open source conferences "Palmetto Open Source Conference" will take place in Columbia, SC March 23-25. Link: http://www.posscon.org check out speakers, contributors and sponsors, tracks, etc. As one of the key contributors I felt that we are very much lacking C and python representation, and for that what's better then Boost? In addition x0 is on the way with boost in it, the interest is there...! I am looking for a speaker. Preferably a key member of the boost community and/or boostcon speaker. I know that's sort of a short notice, but the event is FUN (check out), sponsorship is welcome but not required, and as a speaker you just have to show up and enjoy all the perks. If you interested to participate and you fall in the above mentioned category please contact me @ sergey.razin(a)gmail.com or via this mailing list (whatever is easier). Certainly if you interested to attend, please feel free to contact me as well and we will work out deal for you (especially if you bringing a group). Not many people know about boost, but they should, and certainly it will open up consulting opportunities as well (a couple of major firms in the area are looking). Looking forward for your email. Thank you! Sergey

1 0

[asio] file i/o under linux
by Kamil Nowosad 16 Mar '11

16 Mar '11

Hi, I have been working recently on support for asynchronous file i/o in asio library in linux. Perhaps some of my code will interest you. The interface allows for doing read, write and fsync/fdatasync operations. The implementation uses either POSIX AIO or linux-native libaio (this may be currently switched by #define ASIO_USE_LIBAIO). I have based the initial work on patch brought by Felipe Magno de Almeida in 2005 (http://lists.boost.org/Archives/boost/2005/09 /93068.php). As you may realize by studying my modifications of task_io_service, the file i/o operations are unable to coexist with operations of other kind within single io_service. I did not have time to test it thoroughly, but basic tests pass. The patch is created against 1_45_0 version, however everything works well when applied to 1_46_1. The tarball contains also a simple example file and a script that compiles it. I will be pleased to receive any feedback. -- Best regards, Kamil Nowosad

2 1

[boostcon] site down
by Michael Caisse 16 Mar '11

16 Mar '11

This is my second day not being able to access the site. -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 1

[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

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

[python] extracting a string and a one-length list containing a string
by Allan Johns 13 Mar '11

13 Mar '11

Hello, Given a boost::python object, how can I the difference between that object containing a string, or a sequence of length 1 whos zeroeth element is a string? Ie: "foo" --vs-- ["foo"] bp::extract<std::string> succeeds in both cases. I can use PySequence_Check to test for a sequence, and then I can test the length of the zeroeth element - if >1 then it's ["foo"] - but then I still can't disambiguate ["X"]. tia! Allan

2 2

[range] Should the result of irange satisfy the BidirectionalRangeConcept?
by Vicente Botet 13 Mar '11

13 Mar '11

Hi, I'm trying to define an enum_range and I based my implementation on the one from irange. While writing my test I started just by checking that my enum_range satisfied the RandomAccessRangeConcept requirements and there were some errors with BidirectionalRangeConcept. I replaced by the result type of the irange function and the errors appear also there. It seems that there is an issue concerning the category tags ..\..\../boost/concept_check.hpp:212:13: error: conversion from 'boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>' to non-scalar type 'std::bidirectional_iterator_tag' requested Am I missing something? Best, Vicente == Test == #include <boost/range/concepts.hpp> #include <boost/range/irange.hpp> using namespace boost; BOOST_CONCEPT_ASSERT(( BidirectionalRangeConcept < iterator_range< range_detail::integer_iterator > > )); == Result == gcc.compile.c++ ..\..\..\bin.v2\libs\enums\test\enum_range__random_access_range_concept__pass.test\gcc-mingw-4.5.0\debug\enum_range\random_access_range_concept.pass.o In file included from ..\..\../boost/range/concepts.hpp:19:0, from ..\..\../boost/range/algorithm/equal.hpp:14, from ..\..\../boost/range/iterator_range_core.hpp:29, from ..\..\../boost/range/iterator_range.hpp:13, from ..\..\../boost/enums/enum_range.hpp:24, from enum_range\random_access_range_concept.pass.cpp:15: ..\..\../boost/concept_check.hpp: In destructor 'boost::Convertible<X, Y>::~Convertible() [with X = boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>, Y = std::bidirectional_iterator_tag]': ..\..\../boost/concept/detail/general.hpp:38:28: instantiated from 'static void boost::concepts::requirement<boost::concepts::failed************ Model::************>::failed() [with Model = boost::Convertible<boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>, std::bidirectional_iterator_tag>]' ..\..\../boost/concept_check.hpp:579:1: instantiated from 'boost::BidirectionalIterator::~BidirectionalIterator() [with TT = boost::range_detail::integer_iterator]' ..\..\../boost/concept_check.hpp:571:1: instantiated from 'static void boost::concepts::requirement<boost::concepts::failed************ Model::************>::failed() [with Model = boost::BidirectionalIteratorConcept<boost::range_detail::integer_iterator<int> >]' ..\..\../boost/range/concepts.hpp:333:1: instantiated from 'boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > >' ..\..\../boost/concept/detail/has_constraints.hpp:42:5: instantiated from 'const bool boost::concepts::not_satisfied<boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > > >::value' ..\..\../boost/concept/detail/has_constraints.hpp:45:31: instantiated from 'boost::concepts::not_satisfied<boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > > >' ..\..\../boost/mpl/if.hpp:67:11: instantiated from 'boost::mpl::if_<boost::concepts::not_satisfied<boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > > >, boost::concepts::constraint<boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > > >, boost::concepts::requirement<boost::concepts::failed************ boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > >::************> >' ..\..\../boost/concept/detail/general.hpp:56:1: instantiated from 'boost::concepts::requirement_ > >)>' enum_range\random_access_range_concept.pass.cpp:27:3: instantiated from here ..\..\../boost/concept_check.hpp:212:13: error: conversion from 'boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>' to non-scalar type 'std::bidirectional_iterator_tag' requested ..\..\../boost/concept_check.hpp: In destructor 'boost::Convertible<X, Y>::~Convertible() [with X = boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>, Y = std::forward_iterator_tag]': ..\..\../boost/concept/detail/general.hpp:38:28: instantiated from 'static void boost::concepts::requirement<boost::concepts::failed************ Model::************>::failed() [with Model = boost::Convertible<boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>, std::forward_iterator_tag>]' ..\..\../boost/concept_check.hpp:551:1: instantiated from 'boost::ForwardIterator::~ForwardIterator() [with TT = boost::range_detail::integer_iterator]' ..\..\../boost/concept/usage.hpp:22:29: instantiated from 'boost::concepts::usage_requirements::~usage_requirements() [with Model = boost::ForwardIterator<boost::range_detail::integer_iterator<int> >]' ..\..\../boost/concept/detail/general.hpp:38:28: instantiated from 'static void boost::concepts::requirement<boost::concepts::failed************ Model::************>::failed() [with Model = boost::concepts::usage_requirements<boost::ForwardIterator<boost::range_detail::integer_iterator<int> > >]' ..\..\../boost/concept_check.hpp:546:1: instantiated from 'boost::ForwardIterator<boost::range_detail::integer_iterator<int> >' ..\..\../boost/concept_check.hpp:573:3: [ skipping 6 instantiation contexts ] ..\..\../boost/range/concepts.hpp:333:1: instantiated from 'boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > >' ..\..\../boost/concept/detail/has_constraints.hpp:42:5: instantiated from 'const bool boost::concepts::not_satisfied<boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > > >::value' ..\..\../boost/concept/detail/has_constraints.hpp:45:31: instantiated from 'boost::concepts::not_satisfied<boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > > >' ..\..\../boost/mpl/if.hpp:67:11: instantiated from 'boost::mpl::if_<boost::concepts::not_satisfied<boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > > >, boost::concepts::constraint<boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > > >, boost::concepts::requirement<boost::concepts::failed************ boost::BidirectionalRangeConcept<boost::iterator_range<boost::range_detail::integer_iterator<int> > >::************> >' ..\..\../boost/concept/detail/general.hpp:56:1: instantiated from 'boost::concepts::requirement_ > >)>' enum_range\random_access_range_concept.pass.cpp:27:3: instantiated from here ..\..\../boost/concept_check.hpp:212:13: error: conversion from 'boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>' to non-scalar type 'std::forward_iterator_tag' requested -- View this message in context: http://boost.2283326.n4.nabble.com/range-Should-the-result-of-irange-satisf… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[range] compile error with extra ; with some compilers and options
by Vicente Botet 13 Mar '11

13 Mar '11

Hi, The extra ";" in has_range_iterator.hpp results in a compiler error on some compilers with -pedantic option. Could this patch be applied on trunk? Thanks, Vicente Index: has_range_iterator.hpp =================================================================== --- has_range_iterator.hpp (revision 69537) +++ has_range_iterator.hpp (working copy) @@ -19,7 +19,7 @@ { namespace range_detail { - BOOST_MPL_HAS_XXX_TRAIT_DEF(type); + BOOST_MPL_HAS_XXX_TRAIT_DEF(type) template struct has_range_iterator_impl -- View this message in context: http://boost.2283326.n4.nabble.com/range-compile-error-with-extra-with-some… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[Track] What's up with track
by Robert Ramey 13 Mar '11

13 Mar '11

I log into track system with my name (ramey). The I select issues and select "my Issues". It seems that now the list includes all the issues previously closed so the count is 254 going back to 2004. The actual number should be on the order of 15. Can someone fix this or tell me what to do differently? Robert Ramey

2 1

boost::mpi::scatterv and boost::mpi::gatherv fixed versions
by Júlio Hoffimann 13 Mar '11

13 Mar '11

Hi, I did some changes in attachments. (ticket #5292) Regards, Júlio.

1 0