April 2009 - Boost - lists.preview.boost.org

Re: [boost] [threads] making parts of Boost.Threads header-only
by Brian Wood 09 Apr '09

09 Apr '09

Anthony Williams writes: >Emil Dotchevski <emildotchevski(a)gmail.com> writes: >> >> I am against such a move. Boost Threads requires linking for other >> features which makes it one of the few libraries in Boost that can be >> properly designed to avoid unnecessary physical coupling. Unless >> something is proven to cause performance problems it should not be >> inlined, regardless of how simple it is. > >Wow, that's a hard line you've drawn there. I'm not sure I agree. The >only reason this matters is if you're going to be changing the >implementation and don't want to recompile the code that uses the >header. For boost users, the implementation only changes if they change >boost versions, and in that case I would expect people to recompile >anyway --- I wouldn't trust something compiled against boost 1.37 to >link against a 1.38 lib, for example. I'm sure you know more about Boost than I do, but I disagree that the implementation only changes when users change versions. There are fixes that have to be applied by users to libraries from time to time. I tend to agree with Emil's arguments here. Brian Wood Ebenezer Enterprises www.webEbenezer.net

6 6

[exception] updated in the trunk and in the release branch
by Emil Dotchevski 09 Apr '09

09 Apr '09

Two new functions added: current_exception_cast (http://svn.boost.org/svn/boost/trunk/libs/exception/doc/current_exception_c…) and current_exception_diagnostic_information (http://svn.boost.org/svn/boost/trunk/libs/exception/doc/current_exception_d….) There is a minor breaking change in the interface of the get_error_info function: it used to return shared_ptr, now it returns just a raw pointer: http://svn.boost.org/svn/boost/trunk/libs/exception/doc/get_error_info.html. This limits the lifetime of error_info objects to not exceed the lifetime of the exception object, which could make custom platform-specific error_info optimizations possible (the type of the pointee is guaranteed to be copyable, so if the user needs to hold on to it after the exception object has expired, they can simply copy it instead of relying on shared_ptr to keep it afloat.) -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

[Polynomial] Review Result
by John Maddock 09 Apr '09

09 Apr '09

Apologies for the delay in putting this together... First off I'd like to thank the author for submitting this for review - I wish all our SOC students were similarly diligent! :-) We received a number of reviews of this library, but none were in favor of acceptance in its current form, and most thought that there was still a fair bit of work to do to get the library into shape. However, most thought that the library could be accepted into Boost given sufficient changes/enhancements. Therefore the library is not accepted into Boost at this time, but I would like to encourage the author to continue to work on the library and resubmit at a future time. In no particular order the main review comments are summarized below: Principal comments: * Documentation, especially the background is inadequate and needs a good proofreading a) From the examples are nothing that a competent programmer couldn't figure out from the declarations. Some more interesting or useful examples would be nice, particularly for things like the special forms. It's not exactly clear what I would do with those functions. b) There is no documentation or references to the various algorithms used. Those, too, would be nice. c) Doc.html appear to have been created 'the Hard Way'. Would be much more useful and look nicer if produced with the Quickbook, Doxygen... toolchain. And make it maintainable by other people. * Use of constructors and assignment operators that modify their arguments isn't acceptable - best to find another interface for this. * Several reviewers noted that the code didn't build for them, in particular log2 isn't available on all platforms/compilers. * evaluate_polynomial() and evaluate_polynomial_faithfully() take their coefficient arguments in the opposite order of all the other functions/constructors in the library, without providing any reason for that choice. That's seems somewhat surprising. I'd suggest fixing that, or at the very least providing an argument in the documentation why this makes some sense. * Rename evaluate() to horner() and provide evaluate() as an inline call to horner(). * Rename evaluate_faithfully() to compensated_horner(). * Things that say "Be careful about this" generally need fixing. * It would be nice to have operator* and operator/ as well as *= and /=. * Considering they share the same core algorithm, it might be nice to have a function that could do division and return the remainder at the same time. Something like poly::divide(P &divisor, P &quotient, P &remainer) * FFTs are good for multiplying polynomials above a certain size, but they are rather heavy for small polynomials and can lead to unexpected crosstalk between terms. There should be an option for * that doesn't use the FFT, and it should be the default for small polynomials. * operator/= has a hardcoded "std::vector<double> new_coefficients" that later gets rounded?? This should be fixed to work with any type that fulfills the necessary conceptual requirements (and tested and documented what those requirements are - it would be nice if they were the same as the rest of Boost.Math). * The name FieldType is mathematically misleading since the instantiating type is very likely not to be a field (e.g. int or a multiple precision integer type). * the Polynomial class provides a fairly minimalist set of supported functions. This may well be deliberate (if so, apologies), but I would like to see a richer interface including such things as - content (gcd of coefficients, where that makes sense) - polynomial discriminant - resultant of 2 polynomials - evaluation of homogeneous polynomial ( f(x) = sum c_i x^i,f(a,b) = sum c_i a^i b^(d-i) ) - evaluation at a polynomial (f(g(x))) - Pseudo-division of polynomials - finding roots over C - finding roots over F_p - factorisation over Z - factorisation over F_p * We had one feature request for extending support to finite fields. * This constructor: template<typename U> polynomial(const U& v); had me a little confused at first - is there any advantage to making this a template rather than simply accepting a const FieldType& as the single argument? * It's not clear from the documentation what this constructor does: polynomial(InputIterator first1, InputIterator last1, InputIterator first2); It needs to clearly state the degree of the resulting polynomial and whether it passes through all/any of the points - in fact maybe the constructor should have a final parameter for the degree of the polynomial and use least-squares fitting when required? Likewise for the member function template<typename InputIterator> void interpolate(InputIterator first1, InputIterator last1, InputIterator first2); * Operators: the / and % operators need good descriptions of what they do, given that no exact division is possible. As someone else has already noted, a function to calculate divide and remainder in one step would be useful too. * GCD: presumably this is restricted to polynomials with integer coefficients? If so it should say so. * Evaluation: The docs should say what method is used for the evaluate_faithfully method and give a reference. Renaming as someone else suggested may be better too, but personally I'm easy either way on that. I'm not sure whether there should be an evaluate_by_preconditioning method, shouldn't the polynomial "know" that it has been preconditioned and react accordingly. I haven't looked/checked but do the usual arithmetic operators still work if the polynomial has been preconditioned? I assume probably not, but if that's the case there should be a stern warning to that effect, *and* checks in code to prevent us from doing something stupid :-) BTW, preconditioning can be applied to polynomials of any degree I believe it's just that it gets hard to implement in the generic case. In addition I'd like to see the evaluation functions templated, so that the type being evaluated can differ from FieldType - it would surely be quite common for example to create and manipulate polynomials with integer coefficients, but then want to evaluate on a floating point type. There is machinery in Boost.Math BTW to handle the mixed argument-promotion and calculation of the result type, let me know if you need help in using this. * Special Forms: the functions provided do *not* generate polynomials in the alternative forms, but rather generate the named polynomial of order N, which is rather less useful, but at the very least the docs need updating to reflect this. * test_arithmetics.cpp fails on cygwin: or at least it did once I added a using std::pow; to start of operator*= to get things compiling. * None of the code builds with msvc: there are a couple of issues here: friend polynomial<FieldType> boost::math::tools::gcd<>(polynomial<FieldType> u, polynomial<FieldType> v); Needs to be changed to: friend polynomial<FieldType> boost::math::tools::gcd<FieldType>(polynomial<FieldType> u, polynomial<FieldType> v); to get msvc to Grok the code. After that there are a bunch of failures due to the use of log2 which msvc doesn't support (and since it's not part of the std other compilers are likely to complain too). * I haven't looked too hard at the implementation, except to echo the comments posted previously that the Conceptual requirements for FieldType need documenting and *testing*. There are concept checking classes and archetypes in Boost.Math which may be of use here. Again, shout if you need help in figuring out how to use these. I did notice that operator*= for example uses std::complex<double> internally which effectively limits the precision that can be achieved - to be useful to me - and to replace the existing "implementation detail" polynomial class in Boost.Math - I would need the polynomial class to be usable with arbitrary precision types such as NTL::RR or mpfr_class. Also as previously noted, multiplication of small polynomials may well be more efficient with the "naive" algorithm, so some performance tests and experimenting is required here. Related to this, use of "round" should be restricted to types that are known to be integers? Regards, John Maddock Review Manager for Polynomial Library.

2 1

why the output is different?
by Dongfei Yin 09 Apr '09

09 Apr '09

I write some code like this: #include <iostream> using namespace std; class Base1 { public: typedef Base1 base; void f() { cout<<"Base1::f()"<<endl; } }; class Base2 { typedef Base2 base; public: void f() { cout<<"Base2::f()"<<endl; } }; class A : public Base1 , public Base2 { public: A() { base::f(); } }; void main() { A a; } the output is : Base1::f() But if the definition of class A modified like this, class A : public Base2 , public Base1 { public: A() { base::f(); } }; the out will be: Base2::f() the output depends on the sequence of base class, that means the "typedef" in base class is unreliable. complier gives no warning. I try these code at both VS2005 and VS2008, the result are same.

2 1

[math] Help needed porting to AMD64/Linux platforms
by John Maddock 09 Apr '09

09 Apr '09

Folks, I'm still having trouble with some failures that appear to be specific to Linux on AMD64, if anyone with access to such a platform can help me out I'd be most grateful. You can test whether your machine exhibits the issue by: cd into libs/math/test and bjam gcc test_hypergeometric_dist1 If that fails, then I'm looking for the output from the following program to try and track down the cause of the error (caution this will be quite voluminous!): #define BOOST_MATH_INSTRUMENT #include "boost/math/distributions.hpp" int main() { double x = 30520, r = 130605, n = 130605, N = 523360, p = 1.315394088731268169855067478460234e-53, q = 1; boost::math::hypergeometric_distribution<> hyp(r, n, N); unsigned x_found = quantile(hyp, p); BOOST_MATH_INSTRUMENT_VARIABLE(x_found); return 0; } Perplexed yours, John.

3 5

[proto] _value doesn't enforce zero arity
by troy d. straszheim 09 Apr '09

09 Apr '09

I see some funny behavior when misusing _value: #include <boost/proto/proto.hpp> namespace bp = boost::proto; int main(int, char**) { bp::terminal<int>::type t = {0}; bp::terminal<int>::type hmm = bp::value(t * 2); bp::terminal<int>::type uhm = bp::_value()(t * 2); bp::terminal<const int&>::type hrm = bp::value(2 * t); bp::terminal<const int&>::type feh = bp::_value()(2 * t); } Which does compile.. but the docs say that _value requires an expression of zero arity. Here as usual is an attempt at a patch, to see if I'm learning anything: BOOST_MPL_ASSERT_RELATION( remove_reference<Expr>::type::proto_arity_c, ==, 0L); in the body of struct _value in transform/args.hpp. How'd I do? -t

6 16

[Testing] Sandia-tiger-x86 intel-darwin compiler crashes
by Emil Dotchevski 08 Apr '09

08 Apr '09

I'm wondering if someone with access to that compiler can help me diagnose the problem and/or submit compiler bug reports. Here are the tests that seem to crash the compiler: http://www.boost.org/development/tests/trunk/developer/output/Sandia-tiger-… http://www.boost.org/development/tests/trunk/developer/output/Sandia-tiger-… This one has no log, but might not be a crash: http://www.boost.org/development/tests/trunk/developer/output/Sandia-tiger-… Thanks, Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

Patches in trac...
by Marshall Clow 08 Apr '09

08 Apr '09

At BoostCon last year, we had a discussion about the Trac system. One of the things that we discussed was the fact that the "Patches" tag in Trac was really a bad way to label things. Don't get me wrong - patches are a good thing. However, if a submitted patch fixes a problem, it should be categorized as a "bug report" with a fix attached. And if a patch adds new functionality, it should be categorized as a "feature request" with a proposed implementation attached. The conclusion that was reached at the end of the discussion was that we wanted to get rid of the "Patches" label for Trac tickets, and to move all the existing patches to either "Bugs" or "Feature Requests". I am proposing that this happen immediately after the release of version 1.39 - or immediately after BoostCon, say. What do people think? -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

2 2

Moving property map library into a directory
by Jeremiah Willcock 08 Apr '09

08 Apr '09

The Boost Property Map Library (property_map) currently consists of a number of files in the top-level boost/ include directory. It would probably be better to move all of them into a subdirectory, especially as Nick Edmonds and I will be adding new files and directories into that library soon. Should I do that move? I will update Boost.Graph; are there other libraries in Boost that use property_map? -- Jeremiah Willcock

4 4

Re: [boost] Compilation errors upgrading boost from 1.34 to 1.37 (Windows)
by tinkertom 08 Apr '09

08 Apr '09

I figured out what my problem was: When constructing a boost::mutex::scoped_lock in 1.33 the second parameter is a boolean. In 1.38, boost::mutex::scoped_lock (defined as unique_lock) constructor is overloaded using different types as the initial lock state instead of a single constructor with a boolean. In the constructor I now have to use adopt_lock_t, defer_lock_t, or try_to_lock_t as the second parameter. In 1.33: boost::mutex mtx; boost::mutex::scoped_lock lock(mtx, false); In 1.38 now looks like: boost::mutex mtx; boost::mutex::scoped_lock lock(mtx, defer_lock_t()); -Tom -- View this message in context: http://www.nabble.com/Compilation-errors-upgrading-boost-from-1.34-to-1.37-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Shorter link to getting started
by Vladimir Prus 08 Apr '09

08 Apr '09

I would like to modify the configure script to mention getting started, so that user knows where to look for information, but unfortunately, the current URL is a bit long: http://www.boost.org/doc/libs/1_38_0/more/getting_started/unix-variants.html It is 77 characters, so it does not leave any space for any other text. Can the website administrators arrange for some shorter redirect to be available? Say http://www.boost.org/getting_started/unix-variants.html ? Thanks, Volodya

4 3

[data_binding] Lets bind data
by Kasra 08 Apr '09

08 Apr '09

Hi, I am looking for interest in data_binding techniques in C++. The idea is to have a class that could bind to a list of data and when ever any of them is changed the value of the binder is changed too: data_bindee<mpz_class> x; data_bindee<mpz_class> y; typedef tuple<mpz_class,mpz_class> my_bind_tuple_type; struct my_bind_pred_type { template<typename BinderT> void operator(BinderT& me, my_bind_tuple_typeT t) { me.x = get<0>(t); me.y = 2 * get<0>(t); } }; data_binder<struct { mpz_class x,y; }, my_bind_tuple_type, my_bind_pred_type> point(x, y); // when ever data of x and y is changed the value of point // is updated too. Any suggestions?? Kasra With Best Regards -- Kasra Nassiri

1 0

Preliminary progress on Boost.Python py3k support
by Haoyu Bai 08 Apr '09

08 Apr '09

Hi, I did some preliminary work on BPL py3k support in these days. With Troy's help we have a py3k SVN tree in sandbox now, which is branched from trunk. I also tried to compile BPL with Python 3, and by following the error report of the compiler, I did some patch - now we have 14 .cpp files out of 28 in total can be compiled. The patch is committed, you can see it here: [2]. Please point me out if the code has something don't conform to Boost coding policy. There's also something interesting, maybe a bug I caught, for example: (Search the changeset to see details) 39 // XXX(bhy) Potentional memory leak here since PyObject_GetAttrString returns a new reference 40 // const char *mod = PyString_AsString(PyObject_GetAttrString( self_, const_cast<char*>("__module__"))); 41 PyObject *mod = PyObject_GetAttrString( self_, "__module__"); Also I found some potential problem with Py_ssize_t, I will take this as a chance to fix them. The biggest problem I see still is the "Text Vs. Data Instead Of Unicode Vs. 8-bit" in py3k. As we discussed and the suggestion by Niall [3], we have a clear solution for this and I will work towarding this. The other changes in py3k such as PyObject_HEAD change, int type removal and unbound method removal also affected Boost.Python's code, but they don't require logical change of BPL code and easy to handle. Hopefully in the end of this summer, we will have a Boost.Python library with Python 3 support! Thanks again for many people's help! References: [1] https://svn.boost.org/trac/boost/browser/sandbox-branches [2] https://svn.boost.org/trac/boost/changeset/52118 [3] “Nabble - Python - c++-sig - Some thoughts on py3k support,” http://www.nabble.com/Some-thoughts-on-py3k-support-td22564813.html. -- Haoyu Bai

2 1

[interprocess] Assign to shared_lock from scoped_lock
by Chard 08 Apr '09

08 Apr '09

If I have (template args removed for brevity): shared_lock sh_lock(mutex); scoped_lock sc_lock(move(sh_lock), try_to_lock); // Try for exclusive if (sc_lock) { ... sh_lock = move(sc_lock); // Drop back to shared *** not available } Should that assignment operator be available? Currently I'm working around this with: sh_lock.swap(shared_lock(move(sc_lock))); [or, alternatively: sh_lock = move(shared_lock(move(sc_lock))); ]

2 1

Re: [boost] [Any] Reference counting
by Michael Howell 08 Apr '09

08 Apr '09

Steven Watanabe <watanabesj(a)gmail.com> wrote: > Have you read http://www.gotw.ca/gotw/045.htm? I haven't read it, and have looked into atomic numbers, but couldn't find the "Boost Way" to do it (except perhaps poking around with shared_ptr innards). I wanted to use intrusive counts, since we have control over the object we are sharing. Thorsten Ottosen <thorsten.ottosen(a)dezide.com> wrote: >If you want to improve the performance of any, the thing to do is to add > a small buffer optimization such that all buildin types (or equally > small UDT) are created on the stack. I'll look into that. Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> wrote: > Also, any is a value type. We do not want it to have reference > semantics. So you'd need to use COW. Actually, copy on write/implicit sharing is what I was proposing, if you had looked at the code. > Hence this is fairly useless, especially since we're getting move > semantics soon. "Soon" is relative. The trunk GCC may support it instantly (may already), but Debian Stable won't, nor will MSVC (both which will be used for a good while). Also, you usually copy the value when you store it, which may or may not involve writing. For example: #include <boost/any.hpp> using namespace boost; struct example { any variable; }; int main() { example object; example object2; any value = "I Love Boost!"; object.variable = value; object2.variable = value; return 0; } Thanks for replying, everyone. -- Michael Howell mhowell123(a)gmail.com

4 5

"[gsoc] Thread scheduler support for boost" [Re: for vicente.botet]
by Indradip Ghosh 07 Apr '09

07 Apr '09

Hi Vicente, Sorry for having missed your question earlier on my intended GSOC proposal. I actually intended to design the fine-grained scheduler for threadpool class itself. My detailed application is listed here in the googlesites: http://sites.google.com/site/threadpoolschedulergsoc2009/ Please let me know if you have any questions/ comments regarding my proposal. Thanks and Regards, Indradip. > Message: 7 > Date: Mon, 30 Mar 2009 08:36:36 +0200 > From: "vicente.botet" <vicente.botet(a)wanadoo.fr> > Subject: Re: [boost] "[gsoc] Thread scheduler support for boost" > To: <boost(a)lists.boost.org> > Message-ID: <C1B76DB53B1544F9B2C5618DB7A708EF@viboes1> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > I'm wondering this shouldn't be considered as an extension of the Boost.Thread library more that the Boost.ThreadPool library. The ThreadPool library can be improved once these extension are in place, but also other application or libraries using threads. > > Let me know if I'm missing someething? > > Best, > Vicente

1 0

Performance measurement
by Govindan, Nandagopal (GE Healthcare) 07 Apr '09

07 Apr '09

Hi, I would like to know how performance measurement( time & memory ) done in boost. Do boost has some following APIs to measure performance?? Profiler.start() Code to be measured Profiler.stop() Printstatistics() Regards Nandagopal

3 3

[gsoc] improving any and variant
by Mathias Gaunard 07 Apr '09

07 Apr '09

A few little ideas that could eventually be joined to be a single GSoC project: - Allow visitation for Any. This can actually be generalized to any object that exposes a type_info, such as polymorphic objects. Techniques, including non-portable ones based on name mangling, could be experimented to get more efficient dispatch. - Add SBO to any. - Improve variant so that the functor doesn't require to expose a result_type. The result_type can be automatically deduced by "joining" all the possible return types obtained by boost::result_of. - Allow the easy construction of a visitor from lambda expressions, with a syntax like variant<int, std::string> a = "foo"; int b = match(a).with( args<int>(_1), args<std::string>(size(_1)) ); instead of the potentially more verbose struct my_visitor : static_visitor<int> { int operator()(int a) { return a; } int operator()(const std::string& b) { return b.size(); } }; variant<int, std::string> a = "foo";; int b = apply_visitor(my_visitor(), a);

5 5

Intrusive list/ilist and rbtree marshalling support
by Brian Wood 07 Apr '09

07 Apr '09

I'm happy to announce that version 1.8 of the C++ Middleware Writer is available on line -- http://webEbenezer.net/cgi-bin/samb.cgi<http://webebenezer.net/cgi-bin/samb.cgi>. This version adds support for the following: * Exclusive marshalling support of boost::intrusive::list and boost::intrusive::rbtree. Neither Boost Intrusive nor Boost Serialization offer serialization support of the Intrusive containers. Rather than having two types called 'list,' we refer to boost::intrusive::list as an ilist. An example of this support is here -- http://webEbenezer.net/rbtree_marshalling.html<http://webebenezer.net/rbtree_marshalling.html>. * Several new options on the user interface including: + An "Error Handling" option that indicates whether the code should be written using return codes or exceptions. The exception support is new in this release. This option affects the signatures of the generated marshalling functions. + A "Code Structure" option that indicates whether the code should be written in header-only format or separated interface and implementation files. The separated interface and implementation support is new in this release. This option also affects the signatures of the generated marshalling functions. + A choice between unsigned short or unsigned int as the type for constants written by the C++ Middleware Writer. Constants that identify messages and user defined types are written by the software. Previously the constants were always unsigned ints. * A mechanism to turn off automatic code generation for a type. Adding a // comment within a class declaration with "hand_written_marshalling_code" in the text of the comment will disable default code generation for that type. For example, class bag { // hand_written_marshalling_code ... }; As the comment indicates, you will provide the implementation of the marshalling functions for this class. This option is not available with /* */ comments. Additionally, I would like to say that I find the Intrusive library to be sound and am using it internally in the C++ Middleware Writer. Thanks to the authors: Olaf Krzikalla and Ion Gaztañaga. Brian Wood Ebenezer Enterprises www.webEbenezer.net <http://www.webebenezer.net/> "Then Samuel took a rock and set it up between Mizpah and Shen. He named it Ebenezer [Rock of Help] and said, 'Until now the L-RD has helped us.'"

1 0

[program_options] multitoken arguments
by Carlo Medas 06 Apr '09

06 Apr '09

Dears, we've been using boost::program_options and it works great. We just found a minor thing, which could be an issue, and I'm reporting it to you: when specifying and using a multitoken argument, it actually works only if put as last parameter of command line; in any other case, it eats all remaining parameters. My specification is as follows: desc.add_options() ("output,o", bpo::value<std::vector<std::string> >()->multitoken(), "use output setup for discovery/scan"); If then I want to use it like follows, it works: > fing -p1 -p2 -p3 -o 1 2 3 But if the user inverts the order, it does not work anymore, meaning that p3 is eaten by -o option. > fing -p1 -p2 -o 1 2 3 -p3 Is this a known limitation? Or maybe my specification above is not correct? Thanks in advance, Carlo Medas

2 4

Re: [boost] Shorter link to getting started
by Anders Dalvander 06 Apr '09

06 Apr '09

ghost(a)cs.msu.su wrote: > I would like to modify the configure script to mention getting started, > so that user knows where to look for information, but unfortunately, > the current URL is a bit long: > > http://www.boost.org/doc/libs/1_38_0/more/getting_started/unix-variants.html > > It is 77 characters, so it does not leave any space for any other text. > > Thanks, > Volodya What happens after 77 characters, do characters start falling off the edge of the screen? Hasn't that theory been disproved yet? J/K. It would be nice to have shorter URLs, the non version specific URL is even a character longer: http://www.boost.org/doc/libs/release/more/getting_started/unix-variants.ht… Regards, Anders

3 2

"[gsoc] Thread scheduler support for boost"
by Indradip Ghosh 06 Apr '09

06 Apr '09

Hi , I am writing to poll for suggestions/ questions/ comments regarding my GSOC application listed here : http://sites.google.com/site/threadpoolschedulergsoc2009/ Please let me know if I could clarify any concerns. Thanks, Indradip.

1 0

[boost test] boost testing framework xml schema‏
by Daniel Carrara 06 Apr '09

06 Apr '09

I would like to know where I can find the xml schema for the test logs produced at the end of the testing with --log_level=all and _log_format=XML. Thanks, Daniel _________________________________________________________________ Windows Live™ SkyDrive: Get 25 GB of free online storage. http://windowslive.com/online/skydrive?ocid=TXT_TAGLM_WL_skydrive_032009

2 1

[mpl][doc]bug: prior.html should have Bidirectional Iterator requirement.
by Larry Evans 06 Apr '09

06 Apr '09

The prior.html document: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/prior.html says prior requirement is that Iterator be a Forward Iterator; yet, http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/forward-iterato… makes no mention of prior. Also, compiling prior on a list iterator shows: /home/evansl/prog_dev/boost-svn/ro/boost-trunk/boost/mpl/next_prior.hpp:40: error: no type named 'prior' in 'struct boost::mpl::l_iter<boost::mpl::list1<char> >' Hence, the prior requirement should be Bidirectional instead of just Forward Iterator. -regards, Larry

2 1

My ideas for GSoC project
by Balša Raičević 05 Apr '09

05 Apr '09

Hello, I'm a Computer Science student from Faculty of Mathematics, University of Belgrade. I am interested in working on The BGL. I have a lot of experience with C++ and code refactoring also, since I've done a lot of tutoring and encountered a lot of strange students' code :) I have taken a deep look at BGL ( which is why I'm writing my proposal so late :) ) and to some extend its extension - The Parallel Boost Graph Library. I am mostly interested in graph partitioning, as I find them very useful for parallel computing. I understood the importance of it when I had to do some major calculations for numerical approximations and wanted to use all the CPU power available :) In the project idea list ( https://svn.boost.org/trac/boost/wiki/soc2009#Graphpartitioning) it's said that it would be good to implement algorithms similar to those in METIS ( http://www.cs.umn.edu/~metis <http://www.cs.umn.edu/%7Emetis>). I've read some of George Karypis' "Publications Related to Graph Partitioning", so I was wondering if I could discuss with someone which algorithms would be good to implement, and of course, how. I found little, if any, discussion about that in mailing list archive. Other thing I would really like to see is hypergraph partitioning. I see that implementing hypergraphs in the BGL is one of GSoC projects, so I would like to know would it be possible, if that project is not awarded to anyone for this summer, to do basic implementation of a hypergraph, or (since I see there is already a discussion about that) if somebody else would do that project, to collaborate on hypergraph partitioning algorithms. Last, but not least, an important question: I would like to use this work as part of my Master's Thesis. I looked at GSoC FAQ ( http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs#cours…) so I guess it is OK with the program, but I would still like to discuss it with potential mentor. Thanks ahead, Balsa

1 1

boost::shared_mutex performance
by Tim Blechmann 05 Apr '09

05 Apr '09

hi all, i did some performance tests of boost::shared_mutex and a wrapper class to posix pthread_rwlock_t, which provides most of the interface from the sharedlockable concept (without the timed locking, which should be easy to add). i am not sure, whether the boost::shared_mutex class is supposed to give some guaranties (like fairness), that my wrapper implementation doesn't provide ... it does outperform the boost::shared_mutex implementation by a factor of about 2.5, though (linux, x86_64) benchmark code and wrapper class are attached. seeing these speedups, would it be reasonable to introduce a boost::native_shared_mutex class, based on a native implementation? best, tim -- tim(a)klingt.org http://tim.klingt.org The first question I ask myself when something doesn't seem to be beautiful is why do I think it's not beautiful. And very shortly you discover that there is no reason. John Cage.

1 0

Naga Rama Lokesh Gopu, student - link id zaq1xsw2 , Google Summer of Code
by Lokesh Gopu 05 Apr '09

05 Apr '09

Hi sir , My name is Naga Rama Lokesh Gopu, My link id is zaq1xsw2, I have submitted a proposal on creating new math library with advanced functions, But i have submitted in the last hour before deadline. That s the reason i cant mention clearly in that proposal. i don't know how to prove my self that i am eligible for this project, i submitted the details of my project proposal. In rush you may made my proposal ineligible. I am ready to do code almost all the day more than 3 months. my contact number is (+91 9246476974) I cant find the individual email address who like to do job of mentor. I am ready to do any mathematical project of our wish , Because i am damn good in those topics of good depth. I am not writing any story here, I just want to make u understand my self. If any one like to do mentoring for my project . Please make my proposal eligible , and make me to work harder in this summer. the polynomial function in the boost libraries are not in good depth , i can do more work on the all such topics. I cant clearly mention the work i can do.. Please reply me your opinion about my project on creating new math library. Please understand me i am very enthusiastic to do that in this summer . Finally make my proposal eligible, and mentor my project . Reply is must, even a string of reply! Thank you for understanding me

1 0

[Any] Reference counting
by Michael Howell 05 Apr '09

05 Apr '09

The attached patch add reference counting "implicit sharing" to Boost.Any. It is my first patch to Boost, so it will probably need some changes. -- Michael Howell mhowell123(a)gmail.com

5 5

[gsoc] Students who have an application pending
by troy d. straszheim 04 Apr '09

04 Apr '09

Please try to keep your application up to date with mailing list archive links (via gmane or whatever) to the heads of threads about your proposals. Just add something like a "links to discussion" section at the bottom. This will really help us. If no discussion has taken place here about your proposals, if you update your proposal with a link to this message, you'll still get points for having seen this message at all... :) -t

5 7

[gsoc] Range/Iterator in Boost.Crypto
by Kasra 04 Apr '09

04 Apr '09

Hi all, I have got more excited about GSoc so I have been working ahead of schedule to get boost.crypto going. At this time I have completed my schedule until 05/05/2009. Here I need some advice on the design principles for my interface. I have decided to implemented a generic buffer called crypto_buffer, this buffer is intended to implement bufferings for a stream (stream ciphers/hash algorithms). The class head is as follows: // this class manages 1 block of state_size that the stream is deposited on // also arbitary numbers of buffers that the underlying transformer // wished to include. // when the buffer # 1 is filled in with data the transformer is called // to process the buffer and this is continue untill the end of buffer template< class Transformer, // the algorithm that will transform the buffer size_t Buffers, // the # of buffers this transformer will manage bool FixedOutput, // if the output buffer is constant bool BitBuffered // byte or bit buffered? > class crypto_buffer { public: typedef Transformer transformer_type; typedef BOOST_DEDUCED_TYPENAME transformer_type::size_type size_type; ... // the size of input block which ensured optimal buffering performance static constexpr size_type transform_size = transformer_type::transform_size; // the size of blocks which is stored between transition states static constexpr size_type state_size = transformer_type::state_size; private: transformer_type m_transformer; public: // create a new stream void create(); // transform all but the final stream block template<CryptoBuffer bufferT> size_type transform(bufferT& , const bufferT&); // transform the final block of our stream template<CryptoBuffer bufferT> size_type transform_final(bufferT& , const bufferT&); }; Notice the 'CryptoBuffer' concept. The question is how to implement this concept. Iterators and Ranges is suggested by other previously, however, how could we impelemnt them for the above interface? The reason for my question is I am not sure if I could implement a library that doesn't require for example a block-cipher to have 1-block of input in contiguous memory. For hash functions and stream ciphers is much easier since the contiguity requirement could be a byte or a bit which could be done easily. Any suggestions?? With Best Regards -- Kasra Nassiri

1 0

[GSOC] Regarding the project Boost.DeVector
by Satyam Shekhar 04 Apr '09

04 Apr '09

Hi, I am interested in doing the Boost.DeVector project for GSOC 2009. I had certain queries regarding this project: 1. Does the standard specify any sort of implementation for deque, or does it only specify the requirements and interface? I ask this because if we assume a dynamic array implementation which grows on both the sides, implementing 'reserve', and specifying the size of the chunk should be a trivial task. 2. What are the examples of the low-level operations for which this container is over-encapsulated? Regards Satyam

6 14

[gsoc] Application period ends today / review period begins.
by troy d. straszheim 04 Apr '09

04 Apr '09

Student application period ends today at 19:00 UTC, 12 Noon PDT. Then we have until the 15th to review and rank all (over 50 as of now) student proposals and match them with mentors. -t

4 7

[serialization] serializing std::bitset
by Kenny Riddile 04 Apr '09

04 Apr '09

I need to serialize a std::bitset. I found an implementation by Brian Ravnsgaard Riis from 2006 in the vault that doesn't work with xml archives out of the box since it fails to use nvp wrappers internally. Should I just add the nvp wrappers or is there anything more current for serializing std::bitsets?

3 5

Release schedule
by Vladimir Prus 03 Apr '09

03 Apr '09

Hi, the calendar at http://www.boost.org/development/index.html has: 1.39.0 Closed for major code changes for today and: 1.39.0 Closed except by permission for next Friday, Apr 10th. I have a few questions: 1. Is this schedule still up-to-date? I did not notice any reminder emails. 2. I assume this refers to all commits to release branch? 3. What is 'major code change'. Will wholesale merge of Boost.Build count as one (though I'm not away of any disturbing changes on trunk). 4. Would it be possible to move both deadlines over the weekend to Apr 6 and Apr 13 respectively? I'm sure many developers have more spare time on weekend, so it will make it easier to complete changes. I, in particular, have some changes in pipeline to make building Boost less confusing for newcomers, and certainly will appreciate having that weekend of Apr 11-12. Thanks, Volodya

4 4

[statechart] Bug when switching inner-states?
by George van Venrooij 03 Apr '09

03 Apr '09

Hi, I have attached a test program that gives some curious results, indicating the statemachine does not reach its proper state when performing state changes in orthogonal regions. The machine attached contains a main state that handles an "update" event. That main state contains 2 inner states, one of which also handles the "update" event. If that inner state transits to another state and back again, the "update" event no longer arrives at it, which in my opinion is a bug. If I modify the state machine so it does not have 2 but only 1 inner state, then the behavior matches my expectations. Could someone please verify if this is bug or tell me if my usage scenerio is incorrect. Regards, George van Venrooij Organic Vectory http://www.organicvectory.com #include <boost/statechart/state_machine.hpp> #include <boost/statechart/event.hpp> #include <boost/statechart/simple_state.hpp> #include <boost/statechart/custom_reaction.hpp> #include <iostream> namespace bs = boost::statechart; using namespace std; // The main event, should be handles by a sub-state and the main state struct update_event; // An event triggering the sub-state to switch struct toggle_event; // A dummy event struct other_event; // Sub-states in 2 orthogonal regions struct state_1A; struct state_1B; struct state_2A; struct state_2B; // Main state struct parent_state; // State machine consisting of the main state struct machine : bs::state_machine<machine, parent_state> { }; typedef boost::mpl::list < state_1A , state_2A > inner_states_t; // The main state has 2 orthogonal sub-states struct parent_state : bs::simple_state<parent_state, machine, inner_states_t> { typedef boost::mpl::list < bs::custom_reaction <update_event> > reactions; bs::result react(const update_event&) { cout << __FUNCTION__ << endl; return discard_event(); } }; struct update_event : bs::event<update_event> { }; struct other_event : bs::event<other_event> { }; struct toggle_event : bs::event<toggle_event> { }; struct state_1A : bs::simple_state<state_1A, parent_state::orthogonal<0>> { typedef boost::mpl::list < bs::custom_reaction <toggle_event> , bs::custom_reaction <update_event> > reactions; state_1A() { cout << __FUNCTION__ << endl; } bs::result react(const toggle_event&) { cout << __FUNCTION__ << endl; return transit<state_1B>(); } bs::result react(const update_event&) { cout << __FUNCTION__ << endl; return forward_event(); } }; struct state_1B : bs::simple_state<state_1B, parent_state::orthogonal<0>> { typedef boost::mpl::list < bs::custom_reaction <toggle_event> > reactions; state_1B() { cout << __FUNCTION__ << endl; } bs::result react(const toggle_event&) { cout << __FUNCTION__ << endl; return transit<state_1A>(); } }; struct state_2A : bs::simple_state<state_2A, parent_state::orthogonal<1>> { typedef boost::mpl::list < bs::custom_reaction <other_event> > reactions; state_2A() { cout << __FUNCTION__ << endl; } bs::result react(const other_event&) { cout << __FUNCTION__ << endl; return discard_event(); } }; struct state_2B : bs::simple_state<state_2B, parent_state::orthogonal<1>> { typedef boost::mpl::list < bs::custom_reaction <other_event> > reactions; state_2B() { cout << __FUNCTION__ << endl; } bs::result react(const other_event&) { cout << __FUNCTION__ << endl; return discard_event(); } }; int main(int argc, char* argv[]) { machine m; cout << "0. Initiating state machine:" << endl; m.initiate(); cout << endl << "1. Processing 'other_event':" << endl; m.process_event(other_event ()); cout << endl << "2. Processing 'update_event':" << endl; m.process_event(update_event()); cout << endl << "3. Processing 'toggle_event':" << endl; m.process_event(toggle_event()); cout << endl << "4. Processing 'update_event':" << endl; m.process_event(update_event()); cout << endl << "5. Processing 'toggle_event':" << endl; m.process_event(toggle_event()); cout << endl << "6. Processing 'update_event':" << endl; m.process_event(update_event()); return 0; } ////////////////////////////////////////////////////////////////////////// // Program output after building with VC 9 and Boost 1.37.0 // // Note the different event handling in step 6. as compared to step 2. // although the machine should be back in the same state. ////////////////////////////////////////////////////////////////////////// /* 0. Initiating state machine: state_1A::state_1A state_2A::state_2A 1. Processing 'other_event': state_2A::react 2. Processing 'update_event': state_1A::react parent_state::react 3. Processing 'toggle_event': state_1A::react state_1B::state_1B 4. Processing 'update_event': parent_state::react 5. Processing 'toggle_event': state_1B::react state_1A::state_1A 6. Processing 'update_event': parent_state::react */

2 1

Mutex vs Semaphore
by Jean-Sebastien Stoezel 03 Apr '09

03 Apr '09

Hi, I need to synchronize 2 threads, that is once one is done doing something, it should activate another thread that had been waiting in a pending state. I see the thread library offers mutexes and nothing else. I guess mutexes would do, but I do not believe I should use mutexes for my application. Mutexes are supposed to provide mutual exclusion when critical data is accessed. Semaphores should be used for what I want to do. However, I only see semaphores available in the interprocess library. I only need inter-thread synchronization, and going the long way with the interprocess library seems a bit overkill. It may be an ideology issue here. I would appreciate your comments on what to use in this case. Thanks, Jean

4 5

[gsoc] Min Cost Flow in Boost Graph library
by shilp gupta 03 Apr '09

03 Apr '09

Hey, I am interested in contributing to the Boost Graph library with algorithms. Some of my suggestions are, - minimum cost flow - weighted bupartite matching - maximum flow (based on blocking flows) I had a few questions to ask, Is there any significant progress already in development or implementation of minimum cost flow algorithms in Boost? To the best of my knowledge, Boost does not have a structure for bipartite graphs. Would it be appreciated if I work on one? I know that these can be represented using standard graph structures without much loss, but the simplicity (and scope) of bipartite graph's can be used to reduce constants in the run times of algorithms on them - maximum flow using blocking flows infact runs in O(sqrt(V)E) time for calculating the maximum cardinality matching in the bipartite case. Thanks! Regards Shilp Gupta

2 1

BOOST::SIMD - handling double : precision vs speed
by Joel Falcou 03 Apr '09

03 Apr '09

SIMD algorithms for double precision seem to be rather hard to do right. It's difficult to get the right precision with respect to the scalar reference as scalar algorithm take advantages of the internal 80 bits floating points register, thus leading comparison between our implementation and the reference to yields things like 3000 ulp (ie 10^-13 RMS instead of 10^16). Fixing this is difficult and even if it's possible for some algorithms, the average speed-up then drop to less than 10% - ie as fast as an unrolled scalar call over the SIMD vector elements. What should we enforce : precision or speed ? Or is the 10^-13 RMS enough ? Of course, this is mostly a problem on current SIMD extension in which vector of double only have 2 elements. It may be different with upcoming AVX and Larabee featuring larger vectors. Discussions welcome. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

7 6

A Boost.NumericAdaptor library to support big numbers
by Bruno Lalande 02 Apr '09

02 Apr '09

Hello, Barend quickly talked about this in the discussion about robustness, big numbers and GMP. We have discussed about the idea and I'd like to present it here to see if there's an interest. The idea started from the need to rely on big numbers in geometry computations that are sensitive to floating point errors. The most important points were: - big numbers are needed for those computations - it's difficult to develop a Boost Big Numbers library as efficient as the existing ones - having a Boost geometry library that *necessarily* depends on an existing big numbers library would impose to the user the way in which big numbers must be handled, and would imply a dependency that apparently disturbs some people Thus we had the idea of using an adaptor, that is a wrapper that would have the same semantics as a number, with an underlying implementation chosen at compile-time, by selecting a policy. There would be a IEEE policy that doesn't use any big number at all, and other policies that would be implemented upon the most widely used big numbers libraries. In the end it appears that this adaptor could become a library on its own since it can be useful in other libraries than just geometry. It could thus take the form of a Boost.NumericAdaptor library, aimed to any library developer who needs to optionally enable the use of big numbers for the most robustness-sensible operations of his library. He would just have to take a policy as a template parameter, and propagate this policy to a Numeric Adaptor used internally. The first user of this library would obviously be the GGL we're developing. Libraries like the fixed-size matrix being currently discussed as a GSoC project could offer take advantage of this kind of library, since ideally it has to support big numbers. The sample in attachment shows the numeric_adaptor, a IEEE policy, a GMP policy and a sample showing the use of the library. The implementation has to evolve of course, but the main points are here. Would there be an interest in adding such a library into Boost? Bruno Lalande Barend Gehrels

7 10

Back to Boost.SIMD - Some performances ...
by Joel Falcou 02 Apr '09

02 Apr '09

I'm still working on a potential Boost.SIMD proposal despite the apparent lack of interest by the list. Last discussion spawned the fact that actual performances figures may be interesting. So here's some (see end of mail). This table show for a subset of non-trivial functions the cycles needed to compute one value in scalar, using SSE2, some precision concerns and the actual speed-up. Most of them are super-linear because either : 1/ libc algorithm is badly implemented, or 2/ non-SIMD architectural difference between SSE2 FPU and scalar FPU leads to additional speed-up Most transcendental functions used a SIMD evrsion of the old yet useful Cephes C library based around various polynomial estimations. Results on Altivec processor are roughly the same except for transcendental where the use of a proper FMA instead of sequence of mul-add increases performances.For trivial function like +,-,*,/, I was happily surprised that indeed gcc is able to generate SIMD code. Alas, gcc auto-SIMD speed-up never exceed 2.54 while our code can go up to 3.5. Concerning the problem of interface and support of odd-ball vector size in a platform independant fashion, we use the remark of Matthias and provide a vec<T,C> class in which the vector cardinal can be speficified (and is equal to the native cardinal of said type by default). Things like vec<double,5> are handled as boost::array and provide same interface and set of functions. for any given functions, it cna be applied either to any vec<T,C> types or any native SIMD type (__m128 in SSEx or vector xxx in Altivec). Syntaxic sugar like v = v+4 is provided and perform consatnt splatting before SIMD evaluation. This still has to be boostified and made independant of the whole project it depends on. Once done, a preliminary version will be uploaded into the Vault. Current target architecture are : - SSE2, SSSE3,SSE3 - AltiVec for PPC and Cell processor (a patched version of boost is needed) Comments and questions welcomed. || -------------- || --------------- || scalar || -------------- vector ---------------- || ---- || || || || cycles ||cycles | ulp | rms | peak || s-up || || --------------------------------------------------------------------------------------------- || || abs_ || float || 2.0 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 2.4 || || acosh_ || float || 148.2 || 30.2 | 1 | 9.15e-09 | 1.19e-07 || 4.9 || || acos_ || float || 261.8 || 14.7 | 3 | 7.01e-08 | 2.38e-07 || 17.8 || || arg_ || float || 5.0 || 1.2 | 0 | 0.00e+00 | 0.00e+00 || 4.2 || || asinh_ || float || 152.8 || 32.4 | 1 | 1.22e-08 | 1.19e-07 || 4.7 || || asin_ || float || 256.5 || 11.6 | 2 | 5.32e-08 | 2.28e-07 || 22.1 || || atanh_ || float || 123.9 || 20.4 | 2 | 2.27e-08 | 4.55e-07 || 6.1 || || atan_ || float || 160.7 || 12.7 | 1 | 3.55e-08 | 6.74e-08 || 12.7 || || bitofsign_ || float || 5.1 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 6.1 || || boolean_ || float || 5.4 || 1.0 | 0 | 0.00e+00 | 0.00e+00 || 5.4 || || cbrt_ || float || 152.5 || 39.7 | 1 | 2.76e-08 | 7.77e-08 || 3.8 || || ceil_ || float || 16.6 || 2.8 | 0 | 0.00e+00 | 0.00e+00 || 5.9 || || cosh_ || float || 211.5 || 19.1 | 2 | 4.00e-08 | 1.83e-07 || 11.1 || || cos_ || float || 112.2 || 14.6 | 1 | 2.98e-08 | 1.11e-07 || 7.7 || || cospi_ || float || 103.6 || 12.1 | 1 | 3.43e-08 | 1.19e-07 || 8.6 || || cot_ || float || 142.8 || 17.8 | 3 | 5.54e-08 | 2.38e-07 || 8.0 || || cotpi_ || float || 142.1 || 17.1 | 6 | 9.62e-08 | 4.08e-07 || 8.3 || || exp10_ || float || 169.3 || 32.1 | 1 | 2.88e-08 | 1.19e-07 || 5.3 || || exp_ || float || 171.3 || 19.3 | 1 | 2.60e-08 | 1.19e-07 || 8.9 || || expm1_ || float || 294.1 || 42.6 | 3 | 2.89e-08 | 1.94e-07 || 6.9 || || floor_ || float || 16.9 || 2.7 | 0 | 0.00e+00 | 0.00e+00 || 6.4 || || gd_ || float || 602.4 || 35.8 | 3 | 3.93e-08 | 2.46e-07 || 16.8 || || indeg_ || float || 2.2 || 0.8 | 0 | 2.59e-08 | 5.94e-08 || 2.7 || || inrad_ || float || 2.2 || 0.8 | 0 | 2.53e-08 | 5.94e-08 || 2.6 || || iseqz_ || float || 5.5 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.3 || || iseven_ || float || 45.0 || 2.3 | 0 | 0.00e+00 | 0.00e+00 || 19.9 || || isfin_ || float || 5.9 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.6 || || isflint_ || float || 38.3 || 1.8 | 0 | 0.00e+00 | 0.00e+00 || 21.4 || || isgez_ || float || 6.0 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 7.4 || || isgtz_ || float || 6.0 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.5 || || isinf_ || float || 6.0 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.5 || || islez_ || float || 5.0 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 5.8 || || isltz_ || float || 5.0 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 5.8 || || isnan_ || float || 3.0 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 3.6 || || isnegative_ || float || 5.6 || 1.1 | 0 | 0.00e+00 | 0.00e+00 || 5.0 || || isnez_ || float || 5.4 || 0.9 | 0 | 0.00e+00 | 0.00e+00 || 6.2 || || isnotfinite_ || float || 3.0 || 0.8 | 0 | 0.00e+00 | 0.00e+00 || 3.6 || || isodd_ || float || 47.8 || 2.5 | 0 | 0.00e+00 | 0.00e+00 || 18.8 || || ispositive_ || float || 5.6 || 1.3 | 0 | 0.00e+00 | 0.00e+00 || 4.2 || || log10abs_ || float || 107.5 || 17.3 | 2 | 6.59e-08 | 2.12e-07 || 6.2 || || log10_ || float || 105.4 || 16.9 | 2 | 6.58e-08 | 2.12e-07 || 6.2 || || log1p_ || float || 149.7 || 18.8 | 1 | 9.16e-09 | 1.19e-07 || 8.0 || || log2abs_ || float || 107.5 || 17.2 | 1 | 1.89e-08 | 1.19e-07 || 6.3 || || log2_ || float || 105.5 || 17.1 | 4 | 1.90e-08 | 2.51e-07 || 6.2 || || logabs_ || float || 107.5 || 23.6 | 1 | 4.36e-08 | 1.19e-07 || 4.6 || || log_ || float || 108.3 || 15.4 | 1 | 9.12e-09 | 1.19e-07 || 7.0 || || mantissa_ || float || 22.1 || 5.0 | 0 | 0.00e+00 | 0.00e+00 || 4.4 || || oneminus_ || float || 3.3 || 0.8 | 0 | 5.16e-10 | 5.96e-08 || 4.0 || || oneplus_ || float || 3.4 || 0.8 | 0 | 2.87e-10 | 5.74e-08 || 4.1 || || rec_ || float || 37.4 || 4.3 | 0 | 2.48e-08 | 5.92e-08 || 8.8 || || round_ || float || 43.7 || 5.5 | 0 | 0.00e+00 | 0.00e+00 || 8.0 || || rsqrt_ || float || 105.4 || 11.3 | 1 | 3.62e-08 | 8.81e-08 || 9.3 || || signedbool_ || float || 9.3 || 0.9 | 0 | nan | 0.00e+00 || 10.6 || || sign_ || float || 12.1 || 2.5 | 0 | 0.00e+00 | 0.00e+00 || 4.9 || || signnz_ || float || 12.1 || 1.4 | 0 | 0.00e+00 | 0.00e+00 || 8.5 || || sinh_ || float || 267.2 || 19.1 | 3 | 2.38e-07 | 3.84e-07 || 14.0 || || sin_ || float || 110.5 || 17.0 | 1 | 2.98e-08 | 1.12e-07 || 6.5 || || sinpi_ || float || 115.8 || 14.4 | 1 | 2.98e-08 | 1.10e-07 || 8.0 || || sqr_ || float || 2.0 || 0.7 | 0 | 2.53e-08 | 5.94e-08 || 2.9 || || sqrt_ || float || 68.3 || 7.1 | 0 | 2.62e-08 | 5.96e-08 || 9.6 || || sqrtabs_ || float || 68.3 || 7.0 | 0 | 2.61e-08 | 5.96e-08 || 9.7 || || tanh_ || float || 206.4 || 20.8 | 197 | 1.63e-07 | 1.77e-05 || 9.9 || || tan_ || float || 153.0 || 17.8 | 2 | 4.18e-08 | 1.45e-07 || 8.6 || || tanpi_ || float || 156.2 || 18.0 | 2 | 4.16e-08 | 1.48e-07 || 8.7 || || --------------------------------------------------------------------------------------------- || -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

9 23

[Boost.Asio] Compiler warning in address_v6.hpp
by Fraser Hutchison 02 Apr '09

02 Apr '09

I'm new to boost and am looking for a bit of advice if possible. asio/ip/address_v6.hpp lines 58 & 355 yield the following compiler warnings when flag -Wmissing-braces (which is enabled by -Wall) is set: missing braces around initializer for 'u_char [16]' missing braces around initializer for 'in6_addr::<anonymous union>' These can be avoided by amending e.g. line 58 from boost::asio::detail::in6_addr_type tmp_addr = IN6ADDR_ANY_INIT; to boost::asio::detail::in6_addr_type tmp_addr = {{IN6ADDR_ANY_INIT}}; Is this worth submitting a bug report and patch for this, or not?

3 2

personal samsung
by Fernando Cacciola 02 Apr '09

02 Apr '09

11 6 100 6359

1 1

[gsoc] Proposal - Boost.Matrix - DRAFT RFC
by Kornel Kisielewicz 01 Apr '09

01 Apr '09

Hello all, Following the discussion in the threads: "[boost][gsoc] Interest check for 3d geometry proposal" "[boost] [gsoc] fixed size matrix class?" I post a draft of my proposal with a request for comments. Following the suggestions I decided to scale down the proposal to a polished and production-quality fixed-size Boost.Matrix library, with a big emphasis on correctness and performance. The application follows: Abstract ========= uBLAS is Boost's general linear algebra library, and it is a fine library indeed. However, in some cases it's design decisions, while quite rational for the general use case, are restrictive. This proposal is about a new library that would address some of these issues in the specific situation of vector and matrix operations on fixed sized structures. Suggested is a new library boost::matrix. The library would introduce a single container class that allows representation of fixed size vectors and matrices, and their respective standard operations. The library would define the following template template<typename T, std::size_t N, std::size_t M, class Traits> matrix and standard operations on it. The class would make heavy use of template specialization to allow efficient vector operations ( matrices with size 1xN ), and provide efficient operations for the common sizes (2-4). The class will provide the interface of STL containers with the exact concept depending on the Traits used. Care will be taken to allow transparent usage within STL and other boost libraries. Rationale ========== Boost.Matrix aims to be for uBLAS, what Boost.Array is for vectors -- a fixed size version to remove the overhead. The need is however greater, because while uBLAS provides a template for a fixed-sized version of it's arrays, the template is just a cover for the original uBLAS matrices. While the performance is comparable, the size includes a unnecessary field size. In cases that make heavy use of fixed sized matrices and vectors ( like real-time computer graphics ), such a tradeoff is unacceptable -- due to increased memory consumption as well as effective vectorized math operations, and alignment of structures passed ( a single 4D vector should effectively fit a 128 bit register, and a single 128 bit move operation ). Also, knowing the dimensions of a matrix/vector at compile time, allows for a more efficient operation implementation, both from the programmers side ( better algorithms ), as well as from the compilers side ( optimization ). Primary deliverables ===================== Boost.Matrix library, with the following features: a) a boost::matrix base container class for 2-dimensional matrices, with the proper behavious and semantics of a container, written following the boost coding guidelines, and with full portability in mind b) specializations for efficient vector (1xN matrix) handling c) operators for readable but efficient vector/matrix math d) operator specializations for matrices and vectors of the most common size (2-4) for most efficient implementation Secondary deliverables ======================= a) performance test suite, for testing optimizations b) unit tests for the whole library providing full operation coverage and code-coverage c) documentation for the whole library in the BoostBook format d) efficient implementation of interoperability of Boost.Matrix with other boost libraries (uBLAS in particular) Bonus deliverables =================== ( if time allows these will be delivered during program timeline, if not, they will be implemented afterwards ) a) optional (compile-time controlled) integration with Boost.SIMD to boost (no pun intended) performance b) performance tests on different compilers/architectures, further optimizations c) support for further boost libraries ( Boost.Assign, sandbox libraries, etc. ) Design issues ============== a) compile-time concept checking to only generare functions that make sense for the given type ( no floating point operations for integral types ) b) usage of templates to unroll the operations at compile-time to allow the compiler to optimize them ( needs to be tested case by case with the performance test suite ) c) usage of expression templates to eliminate temporaries in expressions d) care to keep most useful memory alignment ( to provide ease of use with direct usage in architecture dependent pipelines ) e) design with architecture-dependent optimizations in mind ( ease of expansion ) f) keeping all the standard boost practices, including workarounds for non-conformant compilers Project schedule ================= I plan to do at least weekly progress reports with emphasised design decisions (however well designed in the first phase, reality will probably change the design afterwards at least a little). Progress reports will be directed to the medium established with the mentor (blog, list or only direct communication). This will be my only job once summer starts, and will be treated as such during program coding timeline ( full-time schedule ) -- a week may fall out for a short vacation. Preplanning (April 20 - May 23) -------------------------------- Most of the major design decisions need to be done before the program starts. A end-user interface for the library should be established before the program starts. This will be summed up in a report that will be sent to boost-dev with a request for comments. Phase 1 (Correctness) - (May 24 - June 14) ------------------------------------------- A working basic (non-optimized) implementation, and a full test suite for the basic operations will be created. Goal for this phase is to provide a correct and working implementation. Basic usage document. Phase 2 (Functionality) - (June 14 - July 5) --------------------------------------------- Performance test suite. Compiler-level optimizations ( expression templates, unrolling, etc ). Basic library compatibility ( STL container, uBLAS ). Concept checking. Phase 3 (Optimization) - (July 6 - July 26) -------------------------------------------- Optimizations for vectors, optimizations for specific vector and matrix sizes, optimization checking through performance test suite. Code review for eventual optional architecture optimization ( Boost.SIMD for example ). General optimization of code. Update of documentation. Phase 4 (Finalization and bonuses) - (July 27 - August 10+) ------------------------------------------------------------ Testing on as many architectures as possible ( probably will need some help here ). Fixes. Cleanup of the code where needed. A report of the implementation that again will be posted to boost-dev with a request for comments. Here is included also buffer time if there will be delays in one of the former phases. If not, work will continue with the Bonus deliverables. Brief resume ============= I'm a Computer Science PhD student (2nd year) at the University of Wroclaw (Poland), in the field of Computer Graphics. My interests lie in Game Programming and Design, with a special hunch for Real-time Proceduraly Generated Content. I actively run self-designed courses and lectures at the University ( 3ds MAX course last year, Game Programming lecture this semester, and probably an Advanced C++ course next semester ). Currently, until the end of the semester, I'm working full-time at Tieto corporation, doing a large scale project for Nokia. Previously I worked at a smaller computer game company working on a massive multiplayer game. I've successfully taken part in two last GSoC's creating a Procedural City Generator for the BZFlag project. I consider myself a fairly competent C++ programmer, although I only recently discovered its true strengths ( learned to properly use and write in the style of STL, started reading Boost sources, and got hooked into C++0x ). I'm currently using the language both at work and for my own projects. The latter include a 3D game engine (in progress), and an unannounced space combat/trading game. I am a big fan of roguelike (ASCII) games, and managed to write several roguelikes up to date, the most famous one of them being DoomRL ( http://doom.chaosforge.org ) that did even get mentions in contemporary gaming magazines. Homepage : http://chaosforge.org/ IRC nick : Epyon E-mail : kornel.kisielewicz at gmail.com / epyon at cs.uni.wroc.pl -- regards, Kornel Kisielewicz

7 14

Extrinsec conversions (Was [safebool] Can we generalize it and put it intoutilities?)
by vicente.botet 01 Apr '09

01 Apr '09

----- Original Message ----- From: "Eugene Wee" <crystalrecursion(a)gmail.com> To: <boost(a)lists.boost.org> Sent: Wednesday, April 01, 2009 4:10 AM Subject: Re: [boost] [safebool] Can we generalize it and put it intoutilities? > > Hi, > > On Wed, Apr 1, 2009 at 6:20 AM, Vladimir Batov > <vladimir.batov(a)wrsa.com.au>wrote: > >> I glanced over "explicit conversion operators" in C++0x. It did not struck >> me as >> relevant to safe_bool. Care to elaborate? > > > It is relevant since you can say, define an explicit conversion function to > convert to bool, and yet avoid the very problems with say, also allowing > implicit conversion to int, that the safe bool idiom is used to avoid. In > other words, it is a language feature directly designed to replace the safe > bool idiom, and more. Hi, Thanks for the clarification. Even if the following is not related to the safe bool idiom it is related to conversions. The current standard allows to define intrinsec coversions, i.e. conversions that are defined either as a conversion operator on the from class or as a constructor on the to class. Vladimir StringConvert proposal seems to go towards a conversion from/to strings (If I've understood?). lexical_cast can be seen as an extrinsec converions of unrelated types via a common type stream type. I have proposed a generic convert_to template function that generalize extrinsicaly the explicit convertion of unrelated types. template <typename To, typename From> To convert_to(From&); One difference is that for C++0x explicit conversion you can write From from; To to=To(from); While for unrelated types you are forced to write From from; To to=convert_to<To>(from); The other difference is that constructors and conversion operators can be implicit, while the convert_to function can not. Do you think that it could be an interest in extending the C++0X standard to take care of these extrinsically defined conversions between unrelated types? Have a sens to have extrinsec conversions which implicitly convert? Should this convert_to<T> operator be considered as a friend class of T? I know that this is out of the scope of Boost, but I just wanted to know your opinion before posting to comp.lang.c++.moderated. Apologize if this has already been discused. Best, Vicente

3 2

[safebool] Can we generalize it and put it into utilities?
by Vladimir.Batov＠wrsa.com.au 01 Apr '09

01 Apr '09

Repeating safe-bool scaffolding over and over again is a real nuisance. It is worse for the end users as not exactly everyone is intimately familiar with the issue and the safe-bool workaround. Can we generalize it and put something like the following into utilities? struct safebool { typedef void (safebool::*unspecified_bool_type)() const; typedef unspecified_bool_type result; explicit safebool(bool v) : value_(v) {} operator result() const { return value_ ? &safebool::internal_bool : 0; } private: void internal_bool() const {}; bool value_; }; That way all we (and the users) will have to do to deploy the technique will be class Foo { ... operator safebool::result() const { return safebool(my_condition); } }; This seems simple and hassle-free. Thanks, Vladimir.

8 19

[gsoc] Concept check
by Kasra 01 Apr '09

01 Apr '09

Hi, I have decided to use the following concept for my gsco proposal regarding boost.crypto. The dilema at the moment what is the minimum contiguous ranges concept? Any suggestiong over the design? concept CryptoBuffer // which is a variable sized buffer that // uses an allocator that securely deletes. concept BlockCipher { typename value_type; typename size_type; typename traits_type; auto key(void) const throw(); template<CryptoBuffer CB> void key(const CB& ) const throw(invalid_key_size); template<CryptoBuffer CB> void encrypt(CB&, const CB& ) const throw(bad_state); template<CryptoBuffer CB> void decrypt(CB&, const CB& ) const throw(bad_state); }; struct crypto_stream_parallel_encryption { }; struct crypto_stream_parallel_decryption { }; struct crypto_stream_parallel : crypto_stream_parallel_encryption, crypto_stream_parallel_decryption{ }; concept ModeOfOperation { typename value_type; typename size_type; typename block_cipher_type; typename category; static constexpr size_type transform_size; static constexpr size_type state_size; const auto cipher() const throw(); void create() throw(); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update(CB0& , const CB1&); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update_final_block(CB0& , const CB1&); }; concept StreamCipher { typename value_type; typename size_type; typename block_cipher_type; typename category; static constexpr size_type transform_size; static constexpr size_type state_size; const auto cipher() const throw(); void create() throw(); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update(CB0& , const CB1&); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update_final_block(CB0& , const CB1&); }; concept HashAlgorithm { typename value_type; typename size_type; typename block_cipher_type; typename category; static constexpr size_type state_size; static constexpr size_type transform_size; void create() throw(); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type update(const CB1&); template<CryptoBuffer CB0, CryptoBuffer CB1> size_type finalise(const CB1&); }; Any suggestiong over the design? -- Kasra

1 0

has_operator_new
by Robert Ramey 01 Apr '09

01 Apr '09

I've made a TRAK item to request a new type traits feature - has_operator_new. I've included an implementation and a test - both type_traitsified. Hope you can see fit to check it out, and if it's OK, check it in. Let me know when you do this. Once this is in, I can clear a dependent feature request TRAK item from the serialization library. Robert Ramey

2 3

[gsoc] Interest check for 3d geometry proposal
by Kornel Kisielewicz 01 Apr '09

01 Apr '09

Hello all, I was instructed on the #boost-soc channel to post the initial interest check on the GSoC proposal on the dev list, so here it is. It was inspired by one of the project proposals from 2006 (Geometry Library). As a known fact Boost begins to be used in the gaming industry. Following the idea of code reusage, there are several generic algorithms and components reused by virtually every 3d gaming engine. Most particulary this is 3D math. Sure, Boost has a linear algebra library graph algorithms, and a proposed geometry library, yet what is missing is a high-performance low-dimensional linear algebra library ( vectors and matrices up to the 4th dimension ). Side by side we have also a need of several 3-dimensional algorithms -- including, but not limited to intersection tests, inclusion tests, volume bounding, and several computational geometry algorithms. My suggestion would be creating a 3d specific geometry library for boost, with reasonable performance and the most used algorithms. I'd be happy to work on such a library as a GSoC project. My goal is to assess the initial interest in such an GSoC proposal idea before preparing and posting a more detailed description. -- regards, Kornel Kisielewicz http://chaosforge.org/

22 56

GSoC 2009
by Julian Mautner 01 Apr '09

01 Apr '09

Hi everyone! I'm Julian, 21 years old, student at the university of Innsbruck, Austria. Currently I'm making my bachelor in physics and computer science. I really would like to participate as a GSoC-student of yours. I intend to write a proposal for the Boost.Devector project. But first I wanted to ask a few questions: 1) I didn't understand if devector is an intrusive container or it only has to use them? 2) What does this devector class should (exaclty) be capable to do? 3) Which methods are the most important to perform in O(1)? 4) I didn't used the boost-library very much in the past, is this a great problem for this project? Thanks for your time. Regards, Julian

2 1

[type-traits] compilation error in has_new_operator
by Andrey Torba 01 Apr '09

01 Apr '09

Hi All, After 52057-52061 commits the compilation error oocur: D:\c++\libs\boost_trunk\boost/type_traits/has_new_operator.hpp(40) : error C2039: 'nothrow_t' : is not a member of 'std' to reproduce try to compile: #include <boost/type_traits/has_new_operator.hpp> int main() { return 0; } Does it need #include <new>?

2 1