- Boost - lists.preview.boost.org

Forking boost's git
by Mathias Gaunard 13 Sep '13

13 Sep '13

Hi, I would have liked to fork Boost to maintain my own version with my patches before they get merged in master. I was considering using git for this, unfortunately I don't know how to make this happen with submodules. Do I need to fork each submodule separately and to edit the .gitmodules file? Is there a way to not have to do that by hand?

1 0

[COUNTERTREE + SUBALLOCATOR ] version 2.0
by Francisco José Tapia 13 Sep '13

13 Sep '13

Hi this message is to announce the version 2.0 of the *[countertree + suballocator]* library. 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. Actually the most important libraries and environments for parallel development, *don't provide parallel algorithms for th**e** data structures based on trees* ( set , multiset, map and multimap), and all the operations with these data structures are done with 1 thread. This is due to the difficult to divide the element of the tree between an arbitrary number of threads. (If you want to access to the element in the position 1000, you must go sequentially forward from the position 0 or sequentially backward from the last position. The [countertree + suballocator] library provide data structures set, multiset,map and multimap compatibles with the STL data structures *plus the access to the elements by their position like in a vector, and random access iterators*, You can manage it like a vector. Many parallel algorithms designed for vectors, can be used without changes with the countertree data structures. This make *easy **the **design **of **parallel algorithms* for these data structures. In the library there are a concurrent and a non concurrent versions of all the data structures. The non concurrent version are designed for to be executed inside 1 thread, or for to be accessed by several threads only in read operations (like the STL data structures), they provide a bit more speed than the concurrent version. The concurrent version is *thread safe with all the operations*, one thread can be read and other writing over the same data structure in a safe mode ( as you can see in 2.3 -examples) The concurrent library provide the full set of functions of the STL , plus an *additional set of functions*. These functions have the mission of resolve the problems appeared in the concurrent development. By example, you have a map, find an iterator from a key and with the iterator modify the element, but in the middle, other thread delete the element, and when try to access with the iterator, the program crash, and it is very difficult to reproduce the error for to debug. These additional functions make a pack with the two things, first with a read lock which permit concurrent reads, and when obtain the iterator with an exclusive lock for to modify. These additional functions *prevent the problems* like the previously described, with an *easy interface* for to understand and use for the final user. I don't know if exist any other library with tree based structures with random access iterators. I had search for and didn't find. If someone knows someone, please, say me, I am interested to know something new and collect good ideas. I suppose it don't exist because i didn't see parallel support for data structures based on trees, in any library or parallel tools. I request help to the Boost community because I am in the *moment “perhaps” *. Perhaps I forgot something, perhaps something is wrong, perhaps someone decision was not correct, perhaps it can be done in other way... *Please*, is someone see any fail, any omission, any alternative or simply any comment, please say me, in order to reach the final objective, *provide to the C++ community a good, fast, robust and reliable tool.* In my opinion, this library or other with similar functionality, is the last big part needed for to begin to think about a *concurrent STL* . You can find concurrent libraries with vectors and arrays. You have too, concurrent libraries with containers based on hash functions. With the countertree library you have concurrent set, multiset,map and multimap. The concurrent linked list can be implemented with the concurrent vector_tree ( other data structure of the library). The concurrent STL is a very big project, and must involve many agents and perspectives. From the users associations, to big computers makers and big data providers, passing by the compiler makers, the parallel tools providers... But I am sure the *Boost community* will play a central role by prestige, knowledge and experience designing libraries You can find the documentation and the code in the GitHub 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.… Sincerely yours Francisco Tapia fjtapia(a)gmail.com ** I you don't try the library, perhaps the most interested parts of the documentation is the 1.5.- Next improvements. Where explain the future parallel algorithms for the library and how they can improve others areas of the computation with the augmented trees.*

3 6

Some patches to remove obsolete MSVC version checks
by Stephen Kelly 13 Sep '13

13 Sep '13

Hi, I've created patches to remove or simplify some ifdefs for MSVC versions which are now obsolete. There are many more to do. http://www.steveire.com/msvc_obsolete_versions_patches This is a followup to this thread: http://thread.gmane.org/gmane.comp.lib.boost.devel/243094 (Removing old config macro and increasing compiler requirements., 2013-07-29) The patches are most easily applied locally and reviewed with a git-svn checkout and git am. I'll also apply to get SVN access so I can commit patches myself. Thanks, Steve.

1 0

[asio] boost::asio::async_connect reports success on failure
by Ben Pope 13 Sep '13

13 Sep '13

Hi all, I've found a regression between 1.53 to 1.54; if you compile boost/libs/asio/example/cpp11/chat/chat_client.cpp and point it at a host and port that doesn't exist or refuses the connection, instead of coming back with an error, such as host not found or connection refused, it reports success (on the conversion to bool). (you might want to embellish the example with a std::cout << error_code.message() << std::endl;) This appears to be the case across Linux, Darwin, iOS and Android :( synchronous connect seems to work correctly (i.e., echo/blocking_tcp_echo_client.cpp) Ben

2 4

Removing old config macro and increasing compiler requirements.
by Stephen Kelly 12 Sep '13

12 Sep '13

Hi there, I've been working on the modularization effort from a CMake point of view, and from an 'actual modularization' point of view, looking at interdependencies: http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/9/focus=26 I'd like to start on reducing interdependencies, and I'd like to start reasonably small, as no-one in the boost community knows me and see how it goes from there. I'm very active in CMake, Qt and KDE. Currently, in the modularized boost repos, boost::config and boost::core depend on each other. I listed 3 ways of fixing this on the ryppl list: http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/201 My preference is the removal of BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS, and requiring compilers to have the feature. That way boost/config/suffix.hpp will no longer need to include boost/{non_,}type.hpp. My preference is increasing the compiler requirement, because that may open up more similar opportunities for reducing dependencies and interdependencies throughout boost. Grepping indicates that that means increasing the compiler requirements to something like __DMC__ > 0x840, GCC > 3.2, BOOST_INTEL_CXX_VERSION > 500, VC++ > 7.0. Comments? Thanks, Steve.

15 82

proposal for metafunction mpl::eval
by klaus triendl 12 Sep '13

12 Sep '13

Hi, I'm not so much into meta-programming, so I'm not sure whether there's already an alternative available. Nevertheless I'd like to propose a new metafunction that simply evaluates its argument: template<typename F> struct eval: F::type {}; I've found it somehow useful because it avoids syntactical sugar when specifying a condition to be evaluated for eval_if: eval_if< eval<apply<UnaryF, Arg>>, F1, F2 >; instead of writing: eval_if< typename apply<UnaryF, Arg>::type, F1, F2 >; Any comments on this? -- klaus triendl

4 6

[interprocess] Different processes accessing shared memory in different locations
by Tom Sanham 11 Sep '13

11 Sep '13

Hi Our application has the following scenario using Boost V1.0.52: 1) Process A writes to boost interprocess shared memory. The files appear at C:\ProgramData\boost_interprocess\... 2) Process A launches Process B 3) Process B attempts to read from shared memory but fails. It is attempting to read from: C:\Users\<username>\AppData\Local\Temp\boost_interprocess\... This failure only occurs on one single Windows 8 64 bit machine out of many we have tested. On all other machines, the application works perfectly. Please could somebody advise: What changes to our application could be made to avoid this? What changes to the machine's configuration (eg. Registry) could be made to avoid this issue? Many thanks Thomas Sanham

3 4

[asio] Mixing streambuf-based async_read and async_read_until
by Gavin Lambert 11 Sep '13

11 Sep '13

I was tracing through some code today (using Boost.Asio 1.53) and noticed something that seems a little odd to me. Given a boost::asio::streambuf that already contains data (typically from a previous read), the async_read_until operation will check the buffer first to see if it can find the specified delimiter already, and will only fetch more data from the stream if it needs to. It does appear to perform at least one async_read_some per async_read_until call, but this will be a zero-length-read that will not actually hit the network/wherever. (Could probably be optimised a little further though.) The async_read operation however will not check the buffer. While it won't destroy any existing data (it just appends) it will still fetch additional data from the stream up to the specified completion condition, ignoring however much is already in the buffer. For example, if buf already contains 32 unconsumed bytes then async_read(s, buf, transfer_exactly(16), cb) will fetch 16 more bytes from the network, leaving 48 bytes in the buffer but only passing 16 to the read handler. Of particular note is that it will wait for those 16 bytes to be read from the network -- it's not satisfied with the data it already has. The net effect of these behaviours I think is that if you're using async_read_until exclusively or async_read exclusively then everything will behave fairly normally. If you are mixing these two operations on the same stream then you will either be losing data (if you use separate streambufs) or reading more data than you should (if you use the same streambuf and don't check outside of ASIO to see if it already contained enough data). Maybe it's just me, but I find it surprising that async_read doesn't check if the supplied streambuf already satisfies the completion condition, given that async_read_until does and the docs for async_read do say that it's allowed to make zero async_read_some calls. Is this a bug or is it expected behaviour?

1 0

Incompatible Boost license file in boost.container
by Philip Bennefall 10 Sep '13

10 Sep '13

Hi all, I was looking at boost.container, and found that boost/container/deque.hpp has similar problems as boost/detail/endian.hpp had before that was fixed. Parts of deque.hpp seem to be covered by a license that is not compatible with the Boost software license. I quote: // Copyright (c) 1996,1997 // Silicon Graphics Computer Systems, Inc. // // Permission to use, copy, modify, distribute and sell this software // and its documentation for any purpose is hereby granted without fee, // provided that the above copyright notice appear in all copies and // that both that copyright notice and this permission notice appear // in supporting documentation. Etc. Kind regards, Philip Bennefall

4 4

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

10 Sep '13

Hi, I have working in the implementation of the cpo library, so I keep working and I expect to make a formal proposal within 2 or 3 months, and meanwhile I will try my best to answer mails. > Date: Wed, 28 Aug 2013 11:18:03 +0400 > From: Andrey Semashev <andrey.semashev(a)gmail.com> > The storage strategy does not mandate the interface of the container. > unordered_set/map are implemented as a number of buckets (i.e. > single-linked lists), yet they provide sequence interface with an > additional ability to iterate within a single bucket. I don't see why a > similar approach couldn't be taken in your container. I will not provide the classifier container with a push_back or push_front method, instead I will use insert, I suppose it is just about the meaning of sequence, I expect a sequence to keep an order on items while container means just a collection of items in not a particular order. On the other hand I will provide a way to iterate over a "single bucket". Actually, I have been working on benchmarking and that seems to be the better option to iterate over the classifier because it reduces the number of virtual method calls in the iteration. I also will provide a const random access iterator and some other utilities to access a particular item in the container. > > You can't create std::multiset<shape> but you can create > boost::intrusive::multiset<shape>. The reason for that is that > std::multiset attempts to allocate storage for shape, while > boost::intrusive::multiset doesn't, leaving this to the user. This allows > you to insert any objects derived from shape to the single > boost::intrusive::multiset and work with this container pretty much the > same way you would with std::multiset. You can even insert the very same > object in multiple containers if you need to. I recommend you to have a > look at Boost.Intrusive, it is a truly amazing library. The interface for my library needs to be far more simple than the interface in Boost.Intrusive, but I will consider that option to implement the details. Up to now, I am only using std containers to avoid dependencies, but I will consider other options to optimize speed and size performance. [snip] About "polymorphic vector", that is, a container that stores different types contigously, I should say that the interface needs to be as easy as in the classifier, so I will discard solutions that needs any requirement to objects apart from being copyable, default constructive or the like. I will try to develop a prototype from Larry Evans' example (with his permission). But because I am not an expert on alignment and memory optimization, I will try to use something "more standard", actually I am going trying to use the allocator to compute the "right" address to place an object of a given type that is greater that a "free" memory pointer. In that way, I also expect to take advantages of allocator such as tbb cache aligned allocator. Again, thank you all for your comments. Regards, Santiago -- ESCUELA TÉCNICA SUPERIOR DE INGENIEROS INDUSTRIALES UNIVERSIDAD POLITÉCNICA DE MADRID Santiago Tapia Fernández | DEPARTAMENTO DE AUTOMÁTICA, INGENIERÍA ELECTRÓNICA E INFORMÁTICA INDUSTRIAL José Gutiérrez Abascal, 2 | 28006 Madrid TEL +34 91 336 4266 E-MAIL stapia(a)industriales.upm.es www.industriales.upm.es

3 2