January 2015 - Boost - lists.boost.org

[new libraries] [sort] New Library Check list updated
by Beman Dawes 07 Feb '15

07 Feb '15

As we started through the process of adding the sort library as a module, it became obvious the docs for how to do this were quite out-of-date. The best document for adding new libraries is https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList#New…, and that section has now been updated. Although this document is written from the perspective of release managers, the New Library Checklist section serves as a roadmap for what is expected as a new library goes through the stages of being added to a Boost distribution. Comments and corrections welcome, --Beman

5 6

boost interval arithmetic
by Павел Кудан 05 Feb '15

05 Feb '15

The difference in behaviour of comparison operators and basic arithmetic operators looks as probable misconception. Default and changeable behaviour of comparison operators consists in throwing exception in intermediate situation (intersecting intervals, ! (a>b) == (a <= b) is not applicable). Great decision for correct migration from float numeric code. The only and unchangeable behaviour of arithmetic operators consists in silent returning only one of possible intervals in intermediate situation (possible return is not single, multiple interval result). The source of mistakes and undesired behaviour at migration from float numeric. At least, throwing exception by arithmetic operators at intermediate situation would provide behaviour unity of comparison and arithmetic operators and functions. Best regards, Pavel Coodan

7 51

Boost regression testing on Android
by Dmitry Moskalchuk 04 Feb '15

04 Feb '15

Hi all, We've just published CrystaX NDK 10.1 (https://www.crystax.net/android/ndk) which is a drop-in replacement for the Google's Android NDK, and we've included prebuilt Boost 1.57.0 libraries there, to make life easier for those developers who want to use Boost on Android. The reason I write here is that in CrystaX NDK we were able to build Boost for Android without any changes in Boost sources, just because CrystaX NDK makes Android much more POSIX-conformant than original Android is, and Boost just works on top of it. If you're interested how we did it, please read description of CrystaX NDK release on https://www.crystax.net/android/ndk. Another important point is that we were able to run Boost regression tests on Android devices - again, without any changes in Boost sources, just providing own 'adbrunner' script as tests launcher. The only thing needed is to plug one or more Android devices to USB ports and/or run one or more Android emulators and then run script for Boost testing provided by CrystaX NDK. As long as those devices/emulators are available by ADB, Boost regressions tests will run on all of them. As far as I know, Boost is not yet officially supported on Android platform, mainly because of lack of regular regression testing procedure. I wonder if someone would be interested in our results and, if yes, would he/she like to participate in further Boost-on-Android improvements? -- Dmitry Moskalchuk

3 6

[mixin] Library name
by Borislav Stanimirov 04 Feb '15

04 Feb '15

To those unfamiliar with the Boost.Mixin - it is a new library submitted for review. The docs are here: http://ibob.github.io/boost.mixin/index.html The code is here: https://github.com/iboB/boost.mixin It has been suggested multiple times that perhaps the name "mixin" isn't appropriate, so I was wondering if I can find a better one. The current name, mixin, is, as the library itself, inspired by the mixins in the Ruby programming language. However, it doesn't do exactly what Ruby's mixins do (as mentioned here: http://ibob.github.io/boost.mixin/boost_mixin/introduction.html#boost_mixin… ) My current alternative ideas are: * EntityComponent - not great since it doesn't exactly follow the entity-component-system pattern, although it can be said that it allows the construction of entities from components. * DynamicMixin - to emphasize that it's not to be confused with the CRTP mixins. It still has "mixin" in it's name though. * Trait - since it resembles the traits in Self, Scala, PHP, etc. However, a trait is more a "compile time" feature (even when talking about PHP) * TypeComposition or TyCo - a very vague description * Polymorph - since it allows the composition of polymorphic types at run time, but that's pobably even more vague Other ideas are welcome. Thanks -- Borislav

3 2

Hi everyone
by PUNEET KOHLI 03 Feb '15

03 Feb '15

Hello guys. I came to know about your organization from the melange page.Your projects really got me interested. I am a very proficient in c & c++. I have been doing a lot of competitive programming for more than a year so , i can certainly code.I wish to apply to GSOC this year and would love the opportunity if it comes from your organization. Thus, i am looking for a way to contribute and work for you.

2 3

[sync] [thread] Faster mutex
by Antony Polukhin 02 Feb '15

02 Feb '15

Hi, One of the Mesa developers implemented a faster mutex: http://lists.freedesktop.org/archives/mesa-dev/2015-January/075260.html According to the sources of glibc, Mesa's mutex has a much smaller size (only 1 uint32_t vs 6 ints + 2 pointers), performs less actions before and after the actual syscall (no getting and setting of the mutex->__data.__owner, no type field checks) This gives an ~10% speedup. Just curious, maybe ideas from Mesa's mutex could be useful for some of the Boost libraries. -- Best regards, Antony Polukhin

4 4

[predef][check] linux clang triggers BOOST_MAC_OS
by Jürgen Hunold 01 Feb '15

01 Feb '15

Hi! I'm using clang + libc++ on Linux and the Predef "check" magic activates "BOOST_MAC_OS". That means I get: Performing configuration checks - symlinks supported : yes warn: Unable to construct ./info_as_objcpp warn: Unable to construct ./info_as_objc - BOOST_OS_MACOS : yes when running the predef test suite. Command chain: cd libs/predef/test rm -rf ../../../bin.v2/libs/predef/ ../../../bin.v2/check/ ../../../bin.v2/project-cache.jam b2 -a --verbose-test 2>&1 -d+2 --debug-configuration | tee verbose.log verbose.log is attached as zip file. And in fact the macos test are run: clang-linux.compile.c.without-pth BOOST_ROOT/src/devel/boost/bin.v2/libs/predef/test/macos_endian.test/clang- linux-3.7.0/debug/macos_endian.o which is only supposed to be run on macos. The test even passes because it internally checks for "__APPLE__" being defined, which should probably be removed, as the check should be done by the build system. Compiler: clang++ -v clang version 3.7.0 (trunk 227683) Target: x86_64-unknown-linux-gnu Thread model: posix That is current clang trunk. Though I'm already running with -d+2 --debug-configuration I get no output from the configuration test itself. Any ideas on how to debug this further? 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

2 3

Change in range requirements
by Ganssauge, Gottfried 01 Feb '15

01 Feb '15

Please consider the following program: bool predicate(char c) { return c != '0'; } int main (int, char **) { using namespace boost::adaptors; boost::copy( boost::make_iterator_range( std::istream_iterator<char>(std::cin >> std::noskipws), std::istream_iterator<char>()) | filtered(predicate), std::ostream_iterator<char>(std::cout)); return 0; } It works brilliantly with boost-1.54 although std::istream_iterator is only an input iterator. Recently I tried switching to boost-1.57, but suddenly this program stopped working - it won't compile any longer, because istream_iterator is not a forward_iterator: g++ -I ~/source/aurora-python/test-build/parts/boost range_filter.cpp -o range_filter ... # lots of gobbledygook skipped range_filter.cpp:18:64: required from here /home/gotti/source/aurora-python/test-build/parts/boost/boost/concept_check.hpp:210:13: error: conversion from 'boost::iterators::single_pass_traversal_tag' to non-scalar type 'boost::iterators::forward_traversal_tag' requested Y y = x; ^ When I build an equivalent program using boost::filter_iterator it keeps compiling and working fine. Why is it, that the requirements for certain range adaptors (e.g. filtered, transformed) suddenly exclude input ranges? The corresponding iterator adaptors keep working... Gottfried Ganßauge Entwickler Content Engineering & Development ------------------------------------------------------------------ Haufe-Lexware GmbH & Co. KG Ein Unternehmen der Haufe Gruppe Munzinger Str. 9, 79111 Freiburg Tel. +49 761 898-0 Internet: http://www.haufe-lexware.com ------------------------------------------------------------------ Kommanditgesellschaft, Sitz und Registergericht Freiburg, HRA 4408 Komplementäre: Haufe-Lexware Verwaltungs GmbH, Sitz und Registergericht Freiburg, HRB 5557; Martin Laqua Beiratsvorsitzende: Andrea Haufe Geschäftsführung: Isabel Blank, Markus Dränert, Jörg Frey, Birte Hackenjos, Randolf Jessl, Markus Reithwiesner, Joachim Rotzinger, Dr. Carsten Thies ------------------------------------------------------------------

2 1

[type_traits] Rewrite and dependency free version
by John Maddock 01 Feb '15

01 Feb '15

I'm going to throw this out there to see what folks think: In a branch called "Version2", see https://github.com/boostorg/type_traits/tree/Version2 is a partially rewritten type_traits lib: it doesn't yet contain all the traits of the old one, but there's a pretty good selection to test. The main pros for this version are: 1) Zero dependencies other than Boost.Config. 2) No horrible macro-obfuscation - all "real code", making it easier to read and maintain. 3) Substantially reduced template instantiations where practical - often half as many as before. 4) Substantially reduced #includes - the aim is that all files should include only what they need and no more - with what's needed determined by the actual implementation variant when appropriate. There were also a lot of spurious #includes left over from old workarounds no longer used. The main cons: 1) I don't know what I've broken, but surely something, you can help by testing but I would guess we would never be 100% sure it's all right until it's out in the field. This is the main reason for avoiding this until now. 2) MPL interoperability should still work, but files which expect type_traits headers to have included mpl ones will be broken unless they explicitly include what they need. 3) Current MPL inter-operability is fragile see https://github.com/boostorg/type_traits/blob/Version2/include/boost/type_tr… 4) Function dispatching to an mpl::bool_ involves an (inline) function call where as the old inheritance scheme did not. This should mostly disappear once optimizations are turned on, but is still a potential issue for some folks I suspect. 5) I haven't got to the "difficult" headers like common_type.hpp yet. 6) Whatever I've forgotten ;) Of course (2), (3) and (4) could be solved by making mpl's bool.hpp some kind of "core" header. So... what I need from you kind folks is: * Is this the right way forward? * Can you test with your favourite compilers and compare with results for develop - So far I've tested with msvc-10,11,12,14 Intel 14,15, GCC-4.5.4...4.9.1, plus a reasonably recent clang. * If anyone would like to help converting further traits all help would be much appreciated.... Oh and the compiler requirements in the docs are all wildly out of date too... Regards, John.

22 115

Bugs
by Mudit Sharma 31 Jan '15

31 Jan '15

Where can i find bugs which can be solved for boost? Thanks!

2 1