- Boost - lists.preview.boost.org

[interprocess] condition variables and spurious wakeups
by eg 26 Apr '15

26 Apr '15

Hi, I was hoping to get some clarification on whether the boost::interprocess library implementation of condition variables is susceptible to spurious wake ups. Most other library implementations (pthreads, boost::thread, std::thread) seem to be and are documented as such. I couldn't find any mention in the interprocess documentation nor find anything definitive in my google searching. Thanks in advance, Ed

2 1

Latest dependency report
by Peter Dimov 25 Apr '15

25 Apr '15

... generated from the develop branch: http://www.pdimov.com/tmp/report-develop-c3bb6eb/module-overview.html http://www.pdimov.com/tmp/report-develop-c3bb6eb/module-levels.html http://www.pdimov.com/tmp/report-develop-c3bb6eb/module-weights.html

2 2

[boost_document_library] [GSoC'15] How to Start? Any standards to follow?
by Abhinav Tripathi 25 Apr '15

25 Apr '15

Hello, I have finally set up my development environment on Ubuntu 14.10 x64... I am now able to compile any program consisting of Both OpenOffice and Boost code. I have made succesfully small examples with multiple files with both boost and OpenOffice sdk code and compiled them. . I am now ready to start writing code for the document library. What i could think of till now is : 1. Make the project on github and keep it synced 2. Separate classes in different headers with proper namespaces . What i am looking for : 1. Any suggestions on how to start! (More specifically) 2. Are there and standards that need to be followed for developing any library for boost (like using or not using some syntaxes &/or libraires) 3. Any suggestions as to what practices i should use, like which syntaxes/libraries to prefer. . Also, i see that all the boost libraries are independent (i.e., only dependence is within boost itself) [as far as i know]. While what i will be writing will depend on OpenOffice sdk. So, what are its chances to be accepted as an "actual boost library"? . Regards, Abhinav

4 5

tokenizer for overlapping delimiters?
by Jorge Cardoso Leitão 25 Apr '15

25 Apr '15

Dear boost devs, I'm writing here because I've been coding a tokenizer that I believe, given its generality, could be an addition to Boost. I'm asking for a judgement on whether the idea has room in boost or not. The interface I'm proposing is a function of two arguments, a string (call it text) and a set of strings (call it key-terms), that returns a vector<string> (call it result) which fulfils 4 constraints: 1. a string in the result can only be either a key-term or a string between two key-terms; 2. the concatenation of the result is always the original text; 3. a key-term containing other key-terms has priority over the latter; 4. a key-term overlapping other has priority based on its position in the text A tokenizer that divides a string by delimiters is a subset of this interface whose key-terms are the delimiters. This is considered in Boost.Tokenizer, where the key-terms are *non-overlapping. *The critical addition here is the ability to deal with *overlapping key-terms*. A common use case of overlapping key-terms is when you have key-terms that you want to consider as single tokens but they overlap with common delimiters. A practical example: tokenize a string (with words separated by spaces) and guarantee that both `"United States of America"` and `"United States of Brazil"` are interpreted as single tokens. The non-triviality appears because such feat requires storing which key-terms are using a previous sub-string, and how to reverse in case the match fails. (e.g. "United States of " is common to both terms above, but once the first letter appears, either one or both can be discarded as potential matches). Some examples in pseudo-code (see how they fulfil constraints 1-4) tokenize("the end", {}) --> {"the end"} tokenize("the end", {" "}) --> {"the", " ", "end"} tokenize("foo-bar", {"foo", "foo-bar"}) --> {"foo-bar"} tokenize("the end", {"the e", " ", "end"}) --> {"the e", "nd"} tokenize("foo-tars ds", {"foo", "foo-bar", "-tar"}) --> {"foo", "-tar", "s ds"} As a proof of concept, I've implemented such interface and respective test cases, which you can find in https://github.com/jorgecarleitao/tokenize. Any change is possible to accommodate to boost standards: this can be generalized to arbitrary sequences, to arbitrary types, and to use iterators, documented, better tested etc. But before anything else, I would like to ask for an opinion on whether this is sufficiently general and useful to be considered to boost. Thank you for your time, Best regards, Jorge

2 2

Description of pre-requisites for building Boost 1.58.0?
by Marko Asplund 25 Apr '15

25 Apr '15

Hi, While trying to build Boost on Ubuntu 14.04.2 LTS I noticed that the build failed because some library dependencies were missing on my system. I was unable to find documentation about library dependencies and other pre-requisites for building Boost. Are these documented somewhere? Some build related info can be found here, but I couldn't find info about required libraries: http://www.boost.org/doc/libs/1_58_0/more/getting_started/unix-variants.html I was able to build Boost after installing libpython-dev, libbz2-dev packages. This was with default Boost configuration, so other libraries may be required for custom configurations. marko

2 1

[CMT] List of libraries being maintained
by Edward Diener 24 Apr '15

24 Apr '15

Is there a list of libraries being maintained by the community maintenance team ?

3 2

[config] Configuring for C++14 and later library features.
by John Maddock 24 Apr '15

24 Apr '15

Folks, I have an open PR for adding BOOST_NO_CXX14_INTEGER_SEQUENCE (https://github.com/boostorg/config/pull/58) Unfortunately, the correct way to check for std::integer_sequence is to include <utility> and then check for __cpp_lib_integer_sequence. The problem is that we went to some lengths to remove dependencies on <utility> in https://github.com/boostorg/config/pull/40. Further, if we get requests for more such feature-detection macros, we would end up including the whole std lib (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3745#recs.cpp14) This doesn't look acceptable to me, but what to do? The only solution I can see is to simply not support these features in Boost.Config, but rather rely on users needing these features checking the std detection macros directly. Which will work up until someone implements a feature without defining the appropriate macro :( Thoughts? Thanks, John.

7 10

Re: [boost] [thread] Windows compilation broke with 8853a4c
by Jürgen Hunold 24 Apr '15

24 Apr '15

Hi Vicente, On Mittwoch, 22. April 2015 22:50:05 Vicente J. Botet Escriba wrote: > I have rolled back the changes. Please let me know if it works now on > develop. Yes, everything is working again. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

1 0

Git tag for 1.58
by Brian Ravnsgaard Riis 24 Apr '15

24 Apr '15

Hi, 1.58 is still not tagged in the git repo. Does anyone know the sha1 of the relevant commit...? Regards, Brian

1 0

[config] gcc,msvc,mingw visibility
by Robert Ramey 24 Apr '15

24 Apr '15

I've been enabling limited gcc visibility so that it works similarly to msvc *_DECL attributes and will export from the DLL/DSO only those symbols which need to be exported. I've had a lot of difficulty with this. I followed the instructions http://www.boost.org/doc/libs/1_58_0/libs/config/doc/html/boost_config/boos… which more or less boil down to using BOOST_SYMBOL_EXPORT when functions are exported, BOOST_SYMBOL_IMPORT when functions are imported, and BOOST_SYMBOL_VISIBLE on class declarations. I set my Jamfile.v2 in the library build to enable gcc visibility=hidden and let her rip. After the more or less normal back and forth it seemed that the library built and work on all platforms/compilers. .... EXCEPT Mingw. Hmmmm - this shouldn't be too tough, just look at how the other libraries did it. Turns out that it seems that no boost libraries actually enable gcc visibility in their builds - at least as far as I can tell. (I didn't dig into the depths of jam tools files). After a fair amount of research I concluded that for windows platforms - regardless of whether they are built with minnow (gcc) or mdvc, one needs to define BOOST_SYMBOL_VISIBLE as BOOST_SYMBOL_IMPORT or BOOST_SYMBOL_IMPORT which of course makes things more complicated. So here is what I came up with. My questions are: a) did I do this right? b) is there a simpler way c) if the answer to the above is no - can the documentation be updated? Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/config-gcc-msvc-mingw-visibility-tp46747… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 3