September 2013 - Boost - lists.preview.boost.org

Re: [boost] [threads] Memory leaks in Boost threading support? Version boost_1_53_0
by Vicente J. Botet Escriba 16 Sep '13

16 Sep '13

Le 15/09/13 16:58, Paul Morrison a écrit : > Hi Vicente, > > I got your note about the memory leak not being connected to > condition_variable, but this one seems to be... see png file attached... > > Any suggestions you may have would be appreciated! > > TIA > > Paul M. > > PS I wasn't sure how to make sure that my reply got back to you in > person! :-) No, what I mean is that my comment had nothing to be with the condition_variable memory_leak. Unfortunately, I have not found yet what could be the cause. If you can post a short example that reproduce the issue this would surely help. Best, Vicente

1 0

[C++11] If you have an old class with a throwing destructor...
by Daryle Walker 16 Sep '13

16 Sep '13

I just got reminded of a breaking change in C++11 regarding this. Destructors without any exception specification in C++11 get `noexcept(true)` added to them. This means that pre-C++11 classes with throwing destructors turn into `std::terminate` bombs when imported to a C++11 project! I have two^H^H^Hthree such classes in Boost, so I just reported myself. (It's bug #9088, if you're curious.) Any other maintainers as stu^H^H^Henlightened as me should review their classes and add `noexcept(false)` when compiling in C++11 mode. If there are other libraries affected, maybe someone should make an en-masse bug ticket. Daryle W.

11 20

[units] problems
by Robert Ramey 16 Sep '13

16 Sep '13

I want and need the boost.units functionality. I'm sure that this is what I want. But I've spend a lot of time going through the documentation and I'm having real difficulties figure out how to use this. There's a lot there so I feel that what I want must be in there somewhere. I've started going through the tutorial example and there are a couple of problems. First of all, it doesn't compile on my machine. Looking at the tutorial, it actually contains two programs - one of which is commented out. I tried the commented out one as well - it didn't compile either. Note that other than in the header, there are very few if any comments in this code. It doesn't qualify as a tutorial. What I expect to see is: #include <boost/units/quantity.hpp> #include <boost/units/systems/si/length.hpp> #include <boost/units/base_units/us/mile.hpp> void main(){ using namespace boost::units; using namespace boost::units::si; using namespace boost::units::us; quantity<length, float> l1; l1 = 1000.0 * meters; quantity<length, float> l2; l2 = 1.0 * miles; // compile error quantity<length, float> l3 = l1 + l2; } and I expect this to pretty much work. The documentation says " Implicit conversions between unit systems are allowed only when the reduced units are identical, allowing, for example, trivial conversions between equivalent units in different systems (such as SI seconds and CGS seconds)" so I expected that it can convert miles into kilometers. This is a disappointment - but I'll assume that the authors have a good reason for this. So I'm interest in figuring out how to fix this but the manual doesn't seem to help me. I know a huge amount of effort has been invested in this package, but I'm afraid this issue of documentation is a big obstacle to this package being used every where it could be. Note to authors of boost libraries. When you think you've got the documentation done, hand it to someone who isn't familiar with it and ask him to make a small example using the library in 30 minutes. If he can't do that, it's time to go back to work. Most users will give up if they can't get some sort of love back from the library in that amount of time. Robert Ramey

5 13

Re: [boost] [threads] Memory leaks in Boost threading support? Version boost_1_53_0
by Paul Morrison 16 Sep '13

16 Sep '13

>> Hi Vicente, >> >> I got your note about the memory leak not being connected to >> condition_variable, but this one seems to be... see png file >> attached... >> >> Any suggestions you may have would be appreciated! >> >> TIA >> >> Paul M. >> >> PS I wasn't sure how to make sure that my reply got back to you in >> person! :-) > PPS having trouble reducing size of attachment - hope you can read it!

1 0

[threads] Memory leaks in Boost threading support? Version boost_1_53_0
by Paul Morrison 14 Sep '13

14 Sep '13

I am running a number of Boost threads communicating via bounded buffers. My programs seem to run properly, but I get a number of memory leaks, usually 4- and 8- byte areas, although a few are longer. As far as I can tell, they are coming from inside Boost, as there is no mention of lines in my code. OTOH, although my code runs fine, it is quite possible that there are subtle errors in it! I am using _CRTDBG_MAP_ALLOC, which is being used correctly as it detected one area of my own that I was not freeing up, and that has been fixed. I am running VC++ 2010 Express on a 64-bit machine. Here is my memory leak display - I tried setting a few of the numbers as breakpoints, using_CrtSetBreakAlloc(), but most of them did not cause breaks. The first one broke at a new in > boost::detail::basic_condition_variable::get_wait_entry() Line 180 + 0x7 bytes C++ Why wouldn't this get freed up?! Note: <bad exception > looks ominous - where is it coming from?! Detected memory leaks! Dumping objects -> {8624} normal block at 0x02312550, 4 bytes long. Data: <HC1 > 48 43 31 02 {8615} normal block at 0x0015F8F8, 4 bytes long. Data: <h!1 > 68 21 31 02 {8602} normal block at 0x023117A0, 4 bytes long. Data: < 51 > F8 35 31 02 {5584} normal block at 0x02311760, 4 bytes long. Data: <@ > 40 F7 15 00 {4013} normal block at 0x0015F948, 4 bytes long. Data: < 1 > 00 17 31 02 {3924} normal block at 0x02314048, 4 bytes long. Data: < <1 > 20 3C 31 02 {3883} normal block at 0x02314008, 4 bytes long. Data: < +1 > D0 2B 31 02 {3862} normal block at 0x02313CA0, 4 bytes long. Data: <h!1 > 68 21 31 02 {445} normal block at 0x02314088, 4 bytes long. Data: < R1 > 88 52 31 02 {440} normal block at 0x023145F8, 4 bytes long. Data: <HC1 > 48 43 31 02 {430} normal block at 0x02314648, 4 bytes long. Data: < 51 > F8 35 31 02 {402} normal block at 0x02313FC0, 4 bytes long. Data: < 1 > 98 1D 31 02 {395} normal block at 0x023136B8, 4 bytes long. Data: < +1 > D0 2B 31 02 {382} normal block at 0x02313A18, 4 bytes long. Data: < 51 > F8 35 31 02 {355} normal block at 0x02312B90, 4 bytes long. Data: <HC1 > 48 43 31 02 {332} normal block at 0x023121E8, 4 bytes long. Data: <h > 68 F8 15 00 {316} normal block at 0x02311978, 4 bytes long. Data: <HC1 > 48 43 31 02 {298} normal block at 0x023117E0, 4 bytes long. Data: < 51 > F8 35 31 02 {270} normal block at 0x023106D0, 4 bytes long. Data: < 1 > E0 0E 31 02 {256} normal block at 0x02310C50, 4 bytes long. Data: < R1 > 88 52 31 02 {225} normal block at 0x0015FC30, 4 bytes long. Data: < > 90 F9 15 00 {217} normal block at 0x0015F5C0, 8 bytes long. Data: <l > 6C F5 15 00 00 00 00 00 {213} normal block at 0x0015E7B8, 8 bytes long. Data: < > 14 E7 15 00 00 00 00 00 {212} normal block at 0x0015E770, 8 bytes long. Data: < > EC E6 15 00 00 00 00 00 {208} normal block at 0x0015D900, 8 bytes long. Data: <\ > 5C D8 15 00 00 00 00 00 {207} normal block at 0x0015D8B8, 8 bytes long. Data: <4 > 34 D8 15 00 00 00 00 00 {203} normal block at 0x0015CA48, 8 bytes long. Data: < > A4 C9 15 00 00 00 00 00 {202} normal block at 0x0015CA00, 8 bytes long. Data: <| > 7C C9 15 00 00 00 00 00 {198} normal block at 0x0015BB90, 8 bytes long. Data: < > EC BA 15 00 00 00 00 00 {197} normal block at 0x0015BB48, 8 bytes long. Data: < > C4 BA 15 00 00 00 00 00 {193} normal block at 0x0015ACD8, 8 bytes long. Data: <4 > 34 AC 15 00 00 00 00 00 {192} normal block at 0x0015AC90, 8 bytes long. Data: < > 0C AC 15 00 00 00 00 00 {188} normal block at 0x00159E20, 8 bytes long. Data: <| > 7C 9D 15 00 00 00 00 00 {187} normal block at 0x00159DD8, 8 bytes long. Data: <T > 54 9D 15 00 00 00 00 00 {183} normal block at 0x00158F68, 8 bytes long. Data: < > C4 8E 15 00 00 00 00 00 {182} normal block at 0x00158F20, 8 bytes long. Data: < > 9C 8E 15 00 00 00 00 00 {178} normal block at 0x001580B0, 8 bytes long. Data: < > 0C 80 15 00 00 00 00 00 {177} normal block at 0x00158068, 8 bytes long. Data: < > E4 7F 15 00 00 00 00 00 {173} normal block at 0x001571F8, 8 bytes long. Data: <Tq > 54 71 15 00 00 00 00 00 {172} normal block at 0x001571B0, 8 bytes long. Data: <,q > 2C 71 15 00 00 00 00 00 {168} normal block at 0x00156340, 8 bytes long. Data: < b > 9C 62 15 00 00 00 00 00 {167} normal block at 0x001562F8, 8 bytes long. Data: <tb > 74 62 15 00 00 00 00 00 {164} normal block at 0x00155B30, 8 bytes long. Data: < Z > D4 5A 15 00 00 00 00 00 {162} normal block at 0x001559E0, 8 bytes long. Data: < Y > 84 59 15 00 00 00 00 00 {160} normal block at 0x00155890, 8 bytes long. Data: <4X > 34 58 15 00 00 00 00 00 {158} normal block at 0x00155740, 8 bytes long. Data: < V > E4 56 15 00 00 00 00 00 {156} normal block at 0x001555F0, 8 bytes long. Data: < U > 94 55 15 00 00 00 00 00 {154} normal block at 0x001554A0, 8 bytes long. Data: <DT > 44 54 15 00 00 00 00 00 {152} normal block at 0x00155350, 8 bytes long. Data: < R > F4 52 15 00 00 00 00 00 {150} normal block at 0x00155200, 8 bytes long. Data: < Q > A4 51 15 00 00 00 00 00 {148} normal block at 0x001550B0, 8 bytes long. Data: <TP > 54 50 15 00 00 00 00 00 {146} normal block at 0x00154F60, 8 bytes long. Data: < O > 04 4F 15 00 00 00 00 00 {144} normal block at 0x00154E10, 8 bytes long. Data: < M > B4 4D 15 00 00 00 00 00 {140} normal block at 0x00154C40, 16 bytes long. Data: < K > 0C 1D EF 00 02 00 00 00 01 00 00 00 88 4B 15 00 {139} normal block at 0x00154BF0, 14 bytes long. Data: <bad exception > 62 61 64 20 65 78 63 65 70 74 69 6F 6E 00 {138} normal block at 0x00154B88, 44 bytes long. Data: < h > F4 1C EF 00 00 00 00 00 68 F8 EE 00 18 F8 EE 00 {135} normal block at 0x00154A98, 16 bytes long. Data: <\ 0J > 5C 1C EF 00 02 00 00 00 01 00 00 00 30 4A 15 00 {134} normal block at 0x00154A30, 44 bytes long. Data: <D 8 > 44 1C EF 00 00 00 00 00 88 F7 EE 00 38 F7 EE 00 Object dump complete.

2 2

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