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

Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
by Brian Wood 24 Mar '11

24 Mar '11

Dave Abrahams: >At Wed, 23 Mar 2011 14:29:20 -0700, >Emil Dotchevski wrote: >> It is not independent matter because that is exactly what >> BOOST_THROW_EXCEPTION guarantees, except when the library contains >> try..catch or rethrows using throw without arguments, which are rare >> cases. I agree that going the extra mile to workaround those >> additional cases is usually unreasonable. > > I suppose that might be true, depending on your definition of "work > properly." There's no such thing as "working properly without > exceptions" if the library was coded for use with exceptions and you > really need a recoverable response to, say, resource exhaustion. > > That said, "libraries should generally use BOOST_THROW_EXCEPTION" is a > good rule for Boost, and I wouldn't mind having something like it in > the inspect tests, provided that libraries with a legitimate reason > not to use it can be registered as exceptions to the rule. I think you are both more knowledgeable about exceptions and this Boost library than I am, but here's my thinking. In the last 2 or 3 months I added a try/catch and throw without arguments to a file in my library -- http://webEbenezer.net/misc/ReceiveCompressedBuffer.hh . That's the only one so it is rare for me but there are a lot of libraries that are bigger than my library. So I'm not sure it is rare in other libraries. It seems to me that as a library grow this restriction is just waiting for you to run into it. I guess it's a trade-off though if I understand correctly. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

2 1

[GSoC] SIMD proposal
by Mathieu - 24 Mar '11

24 Mar '11

Hello everyone, I'm a french student preparing a Master in Computer Science. I'm highly interested in participating in the 2011 GSoC with Boost. I'm particulary keen on working on the boost.simd subject. I think having SIMD abstraction in boost could be really beneficial (the first example which comes to mind is boost.math). However I have some questions about the subject in order to do my proposal, some of them have already been discussed with Joel Falcou and Mathias Gaunard on IRC, but here it is : One of the main concern I have is that nt2 relies heavily on cmake to detect various things like SSE instruction set support etc. From what I know (I ported nt2 to OpenBSD a while ago), depending on the architecture different methods are used, in order to be portable, like reading from sysctl in OSX or lauching a little executable which collect various informations using cpuid. So the question is : is bjam able to do everything we need to do, or will we need to do the detection in any other way? I use, and I kind of know bjam but I'm not an expert either, I believe Vladimir Prus will be able to help here. Another thing that is a bit blur for me at the moment, is what is the scope of boost.simd? I mean, from what I see the simd part is quite deep-rooted in nt2, has dependencies on several modules of it, so will boost.simd be a subset of nt2 simd module or will we need to rewrite part of it to avoid dragging huge dependencies (and well, end up doing boost.nt2). Mathieu Masson. Regards.

6 14

[type_traits] MSVC rejects typename -- why?
by Lorenzo Caminiti 24 Mar '11

24 Mar '11

Hello all, The following code compiles on GCC (v3.4.3) but it does not on MSVC (cl.exe v14): #include <boost/type_traits.hpp> template<typename T> void f(T& x) { struct s { T g() { // GCC needs this typename but MSVC does not -- why?? typename boost::remove_reference<T&>::type i = 0; return i; } }; x = s().g(); } int main() { int x; f(x); return 0; } MSVC does not accept the `typename` inside `s::g` because it says it's not within a template (but I think it is within a template...). GCC instead requires that `typename`. Which compiler is right? (What does the standard say?) How do I program this code so it works on all compilers? Thank you very much. -- Lorenzo

3 3

[type_traits] Most Unifying Proposal for operator names Was: Review Typetraits Extension.
by Joachim Faulhaber 24 Mar '11

24 Mar '11

Dear Frédéric, Operatorists, list, on occasion of the current naming discussion on operator traits I started a wiki page with an operator functor naming table that allows for an overview over names of operators, functors (and related concept names) across the standard and boost. I compared the name stems only, independent of the question of a 'has_' or 'has_operator_' prefix. Basically it's an extension of Frédéric's operator names table 1.7 from his docs, extended by proto and boost::operator names. Comparing the names I tried to find "Most Unifying Proposals" for names in column MUP: https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators Also I took a look at the current and new standard's functor class templates from header <functional>. I wonder why all the functors only use one template parameter, which restricts their use leaving out the interesting cases of functors for mixed type overloaded operators. template <class T> struct op_functor { ... } instead of template <class T, class U=T, class R=T> struct op_functor { ... } Also I don't understand, why inheritence form binary_function<T,U,R> is no longer declared, but instead of this, the redundant declaration of all associated types for every functor. Does this codereplication serve any purpose? Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

3 6

[bjam] auto linking fail
by Tal Agmon 24 Mar '11

24 Mar '11

Tested on windows Jamroot defines 1.47.0 outputs libs missing patch version causing auto link to fail.. -- Sent from my mobile device

1 0

[move] [ thread] ambiguous call to overloaded function
by Tal Agmon 24 Mar '11

24 Mar '11

Hello, Did anyone experience the following Revision 70494 tested on msvc2010 with headers the following headers: [code] #include< boost/thread.hpp> #include < boost/move.hpp > ... X x; boost::packaged_task<string_ptr_type> pt(boost::bind(&X::foo, boost::ref(x))); boost::unique_future<string_ptr_type> fs = pt.get_future(); boost::thread task(boost::move(pt)); fs.wait(); ... [code] outputs: .$(BOOST_ROOT)boost/move/move.hpp(304): could be 'boost::packaged_task<R> &boost::move<boost::packaged_task<R>>(T &)' or $(BOOST_ROOT)boost/thread/detail/move.hpp(44): or 'boost::detail::thread_move_t<T> boost::move<boost::packaged_task<R>>(T &)'

3 2

[XInt] CoW/Move Timings
by Chad Nelson 24 Mar '11

24 Mar '11

Below are the comparative timings with and without Copy-on-Write, and with and without Boost.Move. Times are measured in seconds, using two sets of ten integers (512, 2048, and 8192 bit). The tests consisted of adding each of those pairs of numbers together 10,000 times, multiplying them 10,000 times, and doing a "mulmod" operation on them (with a third randomly-generated modulus argument of the same size) 1,000 times. Each test was run three times, under as close to identical situations as I could manage, with the raw results in the first three columns; the fourth column is the average of the three. The compiler used was GCC 4.5.1, under Ubuntu Linux 10.10. The build was non-debug and used -O2 optimization. Otherwise, the settings were left at their defaults. The "review code" lines are for the unmodified review version of the code. All others are for the pass-by-reference version, with several other modifications that should have no measurable effect on the speed. The tests show pretty conclusively that Copy-on-Write, alone or in conjunction with Boost.Move, provides a noticeable speed improvement on all three sizes. They also prove that Boost.Move can work well in conjunction with it. I'll leave any further analysis to people who are probably more qualified than I. Note that the Boost.Move numbers could be a little better. The integer_t classes are move-enabled, but the internal data class is not as yet. The data class only sometimes uses return values, so the difference isn't likely to be great. I will make the updated code available on request for anyone who wants to examine the changes. 512bit CoW, no Move: 0.48, 0.47, 0.47: 0.48 No CoW, no Move: 0.61, 0.61, 0.62: 0.61 (worst) No CoW, Move: 0.57, 0.57, 0.55: 0.56 CoW, Move: 0.44, 0.44, 0.44: 0.44 (best) Review code, CoW, no Move: 0.50, 0.47, 0.47: 0.48 2Kbit CoW, no Move: 4.69, 4.79, 4.89: 4.79 (best) No CoW, no Move: 5.01, 5.19, 5.06: 5.09 (worst) No CoW, Move: 5.18, 5.00, 5.01: 5.06 CoW, Move: 4.80, 4.79, 4.86: 4.82 Review code, CoW, no Move: 4.88, 4.85, 4.94: 4.89 8Kbit CoW, no Move: 68.0, 68.8, 68.9: 68.6 No CoW, no Move: 70.4, 70.4, 70.2: 70.3 (worst) No CoW, Move: 70.9, 69.8, 69.6: 70.1 CoW, Move: 68.4, 68.2, 67.8: 68.1 (best) Review code, CoW, no Move: 68.8, 68.4, 68.8: 68.7 -- Chad Nelson Oak Circle Software, Inc. * * *

26 37

[system] error_condition::message is unclear to me
by Jochen Wilhelmy 24 Mar '11

24 Mar '11

Hi! I looked at boost::system and some things are unclear to me: if error_code and error_condition are low level and abstract versions of the same category, then if error_condition::message simply returns |category().message( value() )| then how does category know that it's a condition value and not an error value? (error_code::message also returns| category().message( value() ))| currently error_condition appears quite useless to me since the values have to be the same as in error_code. by the way msdn tells us that error_code is for system errors and error_condition is for user-defined errors but this may be as true as unicode is equivalent to utf16 ;-) another problem I see in system_error::what(). i think it's common sense that what() should return - standarsized strings across platforms - english strings and is used only for lookup. but the current implementation returns the translated string of the underlying operating system. -Jochen

1 0

[GSoC] Boost.Polygon edge, polyline and edge set concepts
by monish gupta 24 Mar '11

24 Mar '11

Hello community I want work on project : Boost.Polygon edge, polyline and edge set concepts. Could anyone provide me some weblinks to learn about polyline and edge set algorithms? Monish Gupta

2 1

Re: [boost] [Boost-users] [context review] Review starts today, Mars 21st 2011
by Oliver Kowalke 24 Mar '11

24 Mar '11

> This confuses me. > > I do understand that a default-constructed *context* object is useful > to be able to switch context from any place in the code. > > But I'm now asking about the usefulness of a default-constructed > *stack* object. A default-constructed *context* object is not passed a > stack object. because og the move-semantics supported by the stack class an default constructed stack instance means not-a-stack. It doesn't allocates memory. > If you're saying that a default-constructed context object must > nonetheless store a default-constructed stack object... this starts to > feel like an implementation detail leaking out into the API. It is not leaking - all classes providing move-semantics are used in this ways. Please look into boost.thread - boost::thread has a default ctor -> constructs a boost::thread instance that refers to Not-a-Thread. > In that case, what further Context work is needed to support Mac OS X? assembler implementation/fcontext - the source code has already an assembler file for MAC OS X (x86-64/i386). I wasn't able to test the code because I haven't a MAC OS X installation. Oliver -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

1 0