- Boost - lists.boost.org

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