- Boost - lists.boost.org

[rational] Updated for fix; run tests
by Daryle Walker 22 Aug '13

22 Aug '13

Earlier today, I uploaded a fix a narrowing-conversion bug to boost::rational. (Ticket #5855, change-set [85418]) But I did another check-in first (change-set [85417]). The lower-numbered change represented a problem while fixing the ticket. C++11 adds two static members to std::numeric_limits. One of them, max_digits10, represents how many digits are needed to be printed to (near) guarantee text/binary conversion. Boost.Test uses it in its C++11 code, so it expects any version of numeric_limits to have it, which caused errors with Boost.Rational since that part of the test code hasn't been touched since it was written nearly 7 years ago! (There was a minor tweak over 5 years ago.) One advantage with Git is that I could have checked both changes separately. Here, for Subversion, I had to back out the second change, commit the first, then redo the second to get them recorded independently. I just did a quick look at our regression tests, and most of them involve one or both of the issues I just fixed. So can everyone do a test cycle sooner rather than later? (The "teeks99-08(e|f|g|h)-Ubnutu12.04-64" teams need to make sure Clang is installed and in the PATH.) Daryle W.

1 0

[countertree] Concurrent set and map with random access iterators
by Francisco José Tapia 21 Aug '13

21 Aug '13

Hi this message is to announce the version 2.0 of the [countertree + suballocator] library. *This library provide a **concurrent** and **thread safe** implementation of the tree based data structures (**set, multiset, map** and **multimap**, plus a new data structure named **vector_tree**) with **random access iterators** and **access by position** like a vector. * *This permit to distribute the elements stored in the trees, between an arbitrary number of threads, identically as do with the vectors, making easy the design of **parallel algorithms** applied to the tree based data structures (as you can see in 2.3.- Examples<https://dl.dropboxusercontent.com/u/8437476/works/countertree_2.0/doc/P2.3_…>and 3.6.- Examples<https://dl.dropboxusercontent.com/u/8437476/works/countertree_2.0/doc/P3.6_…>) , and their use by the **multicore development tools** as **OpenMP, Threading Building Blocks ...* *You can find the documentation and the code in the GitHub* *https://github.com/fjtapia/countertree_2.0*<https://github.com/fjtapia/countertree_2.0> or you can see online in my dropbox page : https://dl.dropboxusercontent.com/u/8437476/works/countertree_2.0/index.html<https://dl.dropboxusercontent.com/u/8437476/works/countertree_2.0/doc/index…> If you prefer download a file with all the code and the documentation : https://github.com/fjtapia/countertree_2.0/blob/master/doc/countertree_2.0.… Perhaps the most interested parts of the documentation are : 1.4.- Concurrent version where explain the problems and new functions implemented 1.5.- Next improvements. Where explain the future development of the library and the concurrent algorithms 1 year ago I presented the request for the evaluation of the [countertree+ suballocator] version 1.0. The approval process is stopped due to the absence of review managers, and in the meanwhile I continued with the develop of this version 2.0. This version is big ( 50.000 lines ) and involve many programming areas ( algorithms, memory management, threads, locks ...) In the design process I must took many decision according my knowledge. I am sure there are many things to correct and improve. In the Boost community there are many people with knowledge and experience, and I trust they can help me in order to provide to the C++ users a good library. If you find an error, or you miss something in the library or have any idea or comment about it, please mail me and I will correct as soon as possible. Sincerely yours Francisco Tapia fjtapia(a)gmail.com *The Boost Formal Review Schedule is in http://www.boost.org/community/review_schedule.html where you can see the projects and their situation.

1 0

Re: [boost] Request to allow contribution to Boost.Multiprecision cpp_bin_float
by Jyotesh Choudhari 20 Aug '13

20 Aug '13

Thanks for your replies. >>> I would like to contribute to the development of Boost.Multiprecision >>> cpp_bin_float library. Can I work on it? If yes, then how can I start? >> Hi Jyotesh, >> Paul Bristow, Chris Kormanyos and I have been discussing this off-list. >> There is a prototype implementation in the sandbox under the >> multiprecision.cpp_bin_float directory.? The current code is pretty much >> complete, but under-tested.? The binary-decimal and decimal-binary >> conversion routines used are also brain-dead and do not round correctly (I >> have a mostly working version that does this correctly on my hard drive, but >> it's not quite ready for commit yet). > Yes. But remember, Jyotesh, John has taken a different direction > than my original code in the sandbox. His implementation is in > a different directory, and it's likely that we will stick with John's > and leave my prototyping to rest. May I know which directory is this? >> So one of the things we need is for >> folks to try this out and see what breaks (or rather to see what they can >> break!). > Such as try some simple math functions or to use it in > conjunction with boost::math::constants for, say, computing > a few hundred digits of pi or log(2). OK. I will try these. >> Some of the std lib function test cases in the sandbox also fail >> currently as their error rates are too high.? Many are also much slower than >> say MPFR.? Chris, would have a better idea which most need working on. > Always important are square root, sine, cosine, and log. >> And finally, the implementation uses all integral arithmetic internally (via >> cpp_int), so one big improvement we need is for someone to write Karatsuba >> and FFT based multiplication routines for cpp_int (Karatsuba is probably the >> higher priority).? Oh and we have no docs yet. > Yes, very important, as this is a huge limitation of cpp_dec_float --- > at least for the digit hunters among us. :-) I will implement Karatsuba algorithm and let you know when I am finished. Thanks and Regards, Jyotesh Choudhari >> Anything there look like something you'd like to work on? >> Thanks for the interest, John. > Thanks for the interest. > Sincerely, Chris.

2 1

Is there BOOST_ENABLE_IF macro now?
by TONGARI J 20 Aug '13

20 Aug '13

Hi folks, It's over 2 years since this post: http://boost.2283326.n4.nabble.com/New-powerful-way-to-use-enable-if-in-C-0… The macro looks sweet and I wonder if we have this macro in Boost in case that I missed it. Thanks.

5 27

Re: [boost] [boost::spirit::basic_hold_any] needs non template operator=
by Hartmut Kaiser 20 Aug '13

20 Aug '13

> I found that hold_any template operator= is not used during assignment to > another hold_any (as intended by its developer). Instead compiler uses > self generated version of operator= which doesn't forward to assign(const > basic_hold_any&). This leads to memory corruption. > The fix is simple - you need to add explicit operator=(const > basic_hold_any&). > My compiler is gcc 4.4.7 and I use option -std=c++0x Version of boost is > 1.53 but I don't see that something changed in 1.54 so it should have the > same issue. Please provide a patch which I will gladly apply. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

1 0

[thread] Dividing into Boost.Thread and Boost.Sync
by Andrey Semashev 20 Aug '13

20 Aug '13

Hi, In our private conversation Vicente J. Botet Escriba, Tim Blechmann and myself have formed a proposal to split the current Boost.Thread library into two libraries: Boost.Thread and Boost.Sync. The former will retain its thread management features, such as thread class, futures and TLS. The latter will contain all thread synchronization components, such as: - locks - mutexes - condition variables - call_once Mutexes and condition variables in Boost.Sync will not support thread interruption and will be as simple and lightweight as possible. For example, one of the benefits I'd like to achieve with this is that synchronization primitives should become decoupled from the timing libraries. I'm not sure we'll be able to make the whole library header-only, but we will try to. If some component is header-only, it will not require linking to Boost.Sync. We plan to add new components to Boost.Sync after the extraction is made. The current candidates for addition are: - spin_mutex and yield_spin_mutex. There are several implementations in Boost, namely in Boost.SmartPtr, Boost.Log and Boost.Atomic. The plan is to refine them into two flavors of spin mutex and move to Boost.Sync and then switch these libraries to the common implementation, if possible. - once blocks from Boost.Log. - portable Windows-style events. There is a prototype implementation in Boost.Log. Boost.Thread will depend on Boost.Sync and will retain headers and possible glue code for backward compatibility. For instance, I think it will have to implement interruptible condition variable. Comments are welcome.

6 17

[serialization] Portable binary archive
by Renato Forti 19 Aug '13

19 Aug '13

Hi All, I am using boost serialization to transfer files, because of portability, I am using: boost::archive::text_oarchive boost::archive::text_iarchive But in testing I've done, it seems to quadruple the size of the file! I saw it in serialization test folder: boost_1_54_0/libs/serialization/example 4 files to work in binary mode (that are very more efficient way): portable_binary_iarchive.cpp (hpp) portable_binary_oarchive.cpp (hpp) My Question: Why not this files are on the library? Anyone ever used them in production? Are safe? How to use? How build serialization lib with these files? I need change bjam of serialization to include these files? One more question: Someone has used Google Protocol Buffer? Could compare with boost serialization? <https://code.google.com/p/protobuf/> https://code.google.com/p/protobuf/ Thanks

1 0

Request to allow contribution to Boost.Multiprecision cpp_bin_float
by Jyotesh Choudhari 19 Aug '13

19 Aug '13

I would like to contribute to the development of Boost.Multiprecision cpp_bin_float library. Can I work on it? If yes, then how can I start? Thanks and regards, Jyotesh Choudhari

3 2

[asio] how to limit speed of tcp socket on asio?
by Renato Forti 19 Aug '13

19 Aug '13

Hi All, Anyone can help-me! I want know if have some way to limit speed of tcp socket on asio? For sample if my app open a socket and start to send a file to my server! How to limit upload speed? If I want limit to 100kb/s, have any way? Anyone have any idea: how I can achieves this? Thanks

2 1

Re: [boost] [cpo-proposal] presentation of the idea
by Santiago Tapia 19 Aug '13

19 Aug '13

> Date: Fri, 16 Aug 2013 13:00:57 +0200 > From: Thorsten Ottosen <thorsten.ottosen(a)dezide.com> >> int main(int argc, char** argv) >> { >> classifier<base, std::allocator> collection; >> >> collection.insert( derived_A(21) ); >> collection.insert( derived_B(40) ); >> >> classifier<base, std::allocator>::iterator i, e = collection.end(); >> >> for ( i = collection.begin(); i != e; ++i ) >> { >> const base& x = *i; >> std::cout << x.do_something(6) << std::endl; >> } >> >> return 0; >> } > > I would like to see the use of forwrding in-place construction: > > collection.push_back<derived_A>( 21 ); > > using variadic templates. OK, I will try. > >> - The container's name is classifier because it classifies objects >> internally using the RTTI. > > I had similar ideas that I wanted to implement. I didn't expect to use > RTTI. Basically I wanted the class hierarchy's base class to derive from > a class with pure virtual functions that allowed the container to > perform the inplace-contruction, copying and alignment stuff. I am trying to make the interface of the container as easy as possible. I think using RTTI is an easy solution. > >> - The container classifier is _not_ a sequence. > > I would expect the container to allow forward iteration. I assume you > mean that erase/insert into the middle is prohibited? I imagined that > only push_back/pop_back was supported. > >> - The classifier uses continuous storage in memory for objects of the >> same type, therefore it is expected to improve cache efficiency with respect >> to solutions that use pointers (and new to allocate objects), especially if the >> client code uses some cache-aware allocator. > > I wanted to call my class template polymorphic_vector, taking base class > and allocator template arguments. I imagined that the storage > would be completely contigious, even when many different types of > objects where stored into the container. This would give maximum cache > efficiency. Then if the user wanted to sort or otherwise manipulate the > sequence, he could just create an std::vector<T*> of the elements > (Thus, push_back should probably return a pointer to the constructed > element). I am thinking about including that std:vector<T*> internally in another container, thus, I could provide a random access iterator. That could be "sequence_classifier". But I see a problem: if we only sort the vector<T*> then the objects in memory of consecutive iterations will not be contigous in memory and we will lose some of the cache efficiency. I will try to provide another kind of iteration, actually a two-levels iteration, like in a matrix, in order to gain access to the vectors of objects. That way we might sort objects of the same type without drawbacks. > > All in all, I hope you will persue this idea. I certainly have many > use-cases for it in code where efficiency matters, and in code where > using Boost.Intrusive is just must more work. > > kind regards > > Thorsten > Date: Fri, 16 Aug 2013 19:20:36 -0500 > From: Larry Evans <cppljevans(a)suddenlink.net> >> Yes, that is the idea. Actually, whether the implementation uses a collection >> of vectors or other mechanism is an implementation detail. I use a map >> of vectors in the classifier container, but I will try other implementations. > Is the map key something like the type_info: > > http://www.cplusplus.com/reference/typeinfo/ Yes, actually a wrapper of typeinfo because of a problem with typeinfo I could not workaround. But that is an implementation detail, I mean, that will be an inner detail of the library and I might find a better solution without changing the interface of the classifier container. > > If there is a separate vector for each type, then the storage for a > container containing more than one type can't be contiguous, > since the vectors for the containers for the types cannot be > contiguous, or am I missing something? I think what Thorsten > was aiming at in this post: > > http://article.gmane.org/gmane.comp.lib.boost.devel/243504 I could not follow the link... ? > > was each element in the container was truly contiguous. IOW, > given a container, c, then. > > c.insert(T1()); > c.insert(T2()); > > The T1 inserted into c would be contigous with the T2. No, in the prototype of the classifier T1 will not be contigous with T2, but: c.insert(T2()); c.insert(T2()); first object of T2 will be contigous with second object of T2. > > [snip] >>> Date: Tue, 13 Aug 2013 23:33:25 +0400 >>> From: Andrey Semashev <andrey.semashev(a)gmail.com> >>>> >>>> - The container classifier is _not_ a sequence. >>> >>> Why? Is this intentional? >> >> Both intentional and accidental, because I want to allocate objects >> contiguously in memory I have to store them in a collection of >> vectors, the container is not a sequence but a collection of sequences, >> one sequence for every class in the classifier. >> I will implement a sequence, but later. >> > > The above reinforces my above conclusion that T1 and T2 elements > cannot be contiguous in the container. A container might store T1 and T2 contigously, but up to now, that is not my idea, because it is more difficult and I am not sure about the efficiency of that alternative. Actually, I have read somewhere that there is a cache memory for functions, in that case, classifying the objects by type could be a good implementation because the virtual methods could be stored in the cache until the objects of that type were finished. > Date: Sat, 17 Aug 2013 08:12:48 -0400 > From: Rob Stewart <robertstewart(a)comcast.net> > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Subject: Re: [boost] [cpo-proposal] presentation of the idea > > On Aug 16, 2013, at 9:21 AM, Santiago Tapia <santiago.tapia(a)upm.es> wrote: > >>> Date: Tue, 13 Aug 2013 23:33:25 +0400 >>> From: Andrey Semashev <andrey.semashev(a)gmail.com> >>> >>>> - The allocator argument in the classifier will be applied to every object added to the classifier. Thus, the allocator is provided without its argument. The std::allocator is the default argument. >>> >>> You can use the standard interface for allocator rebinding: >>> >>> typedef allocator<T> allocator_T; >>> typedef typename allocator_T::template rebind<U>::other allocator_U; >>> >>> You can use std::allocator<void> by default then. >> >> I am not sure how to do this. I need a allocator with a parameter in order to get: allocator<triangle>, allocator<square>, ... this allocator must be instantiated when an object of a new class is inserted in the classifier. > > That's the point of rebind. Starting with allocator<A>, you can get allocator<B>. The spelling of allocator<B> just looks odd: > > typename allocator<A> template ::rebind<B>::other > > ___ > Rob > Understood, thank you both for the comment. > Date: Sat, 17 Aug 2013 09:20:14 -0500 > From: Larry Evans <cppljevans(a)suddenlink.net> > > The attached demonstrates, I believe, what Thorsten was aiming at > an shows the storage of *different* types in contiguous storage. > > HTH. > > > -regards, > Larry > >

3 2