January 2015 - Boost - lists.preview.boost.org

[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

libraries affected by common factor gcd and lcm namespace change moving from math to integer library
by Paul A. Bristow 30 Jan '15

30 Jan '15

A quick grep (for gcd_ and lcm_ in *.*pp) suggests that the following libraries are affected by gcd and lcm namespace change moving from math to integer library. At present, math_fwd.hpp provides some typedefs and declarations needed for these, and a copy of the common factor codes, so nothing may fail immediately, but these duplicate will be removed after at least one release. Chrono Interprocess Math Multiprecision Ratio Rational Units All libraries should use the declarations in integer/integer_fwd.hpp and /integer/common_factor_ct.hpp and /integer/common_factor_rt.hpp. (And there may be documentation changes too?) Something needs to be done ;-) (If you want *me* to resolve anything, then I need write access to your library). Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

4 4

[uuid] Issue 9407: please merge fix
by Antony Polukhin 30 Jan '15

30 Jan '15

Hi, Looks like Boost.UUID library is not maintained. Could someone take care of that library. Especially I'm interested in applying a pull request to fix 9407 <https://svn.boost.org/trac/boost/ticket/9407> issue ( https://github.com/boostorg/uuid/pull/2) Pull request has been already reviewed by Andrey Semashev and significantly improved. -- Best regards, Antony Polukhin

3 9

[Filesystem] problem with tutorial documentation
by Tom Yonkman 30 Jan '15

30 Jan '15

On the http://www.boost.org/doc/libs/1_57_0/libs/filesystem/doc/tutorial.html page, the text after the tut4.cpp code box appears to be obsolete as it doesn't match up with the current code in tut3.cpp and tut4.cpp. Tom Yonkman

2 1

[predef] Announce: Build time configuration for Predef defs.
by Rene Rivera 29 Jan '15

29 Jan '15

Following on the concept by Peter Dimov of using the BBv2 config feature combined with tests I'm pleased to announce that Predef now has a similar feature. In the develop branch of Predef you can now do the following: import ../libs/predef/check/predef : require : predef-require ; run macos_only_test.cpp : : : [ predef-require "BOOST_OS_MACOS" ] ; run vc15_only_test.cpp : : : [ predef-require "BOOST_COMP_MSVC >= 15.0.0" ] ; The expression(s) to check can use any of the definitions that Predef has. The general for is: "<DEF> <OP> <VERSION>". Where <OP> is any of the usual C/C++ relational operators. And <VERSION> is a partial or complete triplet of integers. You can specify multiple checked expressions that are all required. Also part of this is a more general "check" rule that allows for custom build requirements. For example: import ../libs/predef/check/predef : require check : predef-require predef-check ; run macos_only_test.cpp : : : [ predef-require "BOOST_OS_MACOS" ] ; run vc15_only_test.cpp : : : [ predef-check "BOOST_COMP_MSVC >= 15.0.0" : <define>THIS_IS_MSVC : <build>no ] ; I'll put this into master as soon as I have appropriate documentation. Enjoy. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 12

Wiki, website, and stuff..
by Rene Rivera 29 Jan '15

29 Jan '15

I was contemplating editing the release schedule documentation < https://svn.boost.org/trac/boost/wiki/ReleaseSchedule> and thinking if it would be better to start moving such documentation away from the Trac wiki. And I think it is a good idea to move that documentation elsewhere. Especially if it's some place where it's easier to manager the editing permissions and contributions. So I was thinking about what options we had. What I'm aware of as choices are: * Another project in Github just for wiki like documentation. * Using the website project wiki for it. * Adding it directly to the website given how easy it is to edit online now. Although not so easy to preview because of the way the web site works. * A github pages site of some sort. Are there other options? Any opinions on the above options? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 4

List of boost headers in boost/ (was RE: preprocess operation problems)
by Fletcher, John P 29 Jan '15

29 Jan '15

I have been involved in a discussion about the problem of keeping uptodate the header files in the top level boost/ which only get updated if they are links to the corresponding file in the boost/libs/ subdirectory which they refer to, if there is one. To give an idea of the size of the problem of headers in boost which are not links, attached is a list of all the *.hpp files in the current boost/ on develop. Only a very small number of them are links. Some of them may only contain links to headers in other directories and these will be being updated, but some of the top level headers are substantial files in themselves. These files are not being updated from when I set up the local git repository. This means that if the underlying file changes, the two get out of step. This has happened in the case of boost/integer_fwd.hpp as discussed in the other thread. My interest is to be able to maintain and update the particular library I have agreed to maintain, Boost Phoenix. That has many dependencies not only of its own but also the tools e.g. test and preprocess, which I need to use from time to time. I hope we can evolve a situation where it is clear to a maintainer what is needed to keep a consistent working environment. I know that is not easy because of the way tools, such as compilers and indeed the C++ standard itself, keep on changing. We do need a working platform which we can understand and work with. I think some of the present problems are arising because of very reasonable attempts to make boost more consistent. Some of the changes of configuration are causing problems not forseen, because of the wide interdependence of the boost libraries. John Fletcher

5 5

preprocess operation problems
by Fletcher, John P 29 Jan '15

29 Jan '15

I run with all the boost libraries on develop. Today the preprocess operation will not run unless I patch the file boost/integer/common_factor_ct.hpp with the following code after the includes. #ifdef BOOST_NO_INTEGRAL_INT64_T typedef unsigned long static_gcd_type; #else typedef boost::uintmax_t static_gcd_type; #endif The compiler errors had indicated that this definition was missing. I have not traced the change which caused this problem, and I have not run preprocess for some time so don't know what happened and when. I can now run with gcc 4.6 John Fletcher

4 14

Template Instantiation Profiler with Callgrind Output (KCacheGrind)
by Mikael Persson 29 Jan '15

29 Jan '15

Hi boost developers and users, I just wanted to announce a recent development in my little pet-project, which is Templight: a template instantiation profiling tool based on Clang. I think that many of you would be interested in experimenting with it because many boost libraries are great examples of template-heavy libraries and many maintainers, developers and users might be interested in gathering data and diagnosing the real compilation costs (in time and memory) of various components of Boost. Templight is a Clang-based profiler that can act as a drop-in replacement (e.g., in cmake) for the clang compiler, with the addition of generating a complete trace of the template instantiation history with associated time and memory (optional) costs. This allows you to see not only how deeply recursive certain template instantiations are, but also identify which instantiations the compiler spends the most time or memory on. It is basically to meta-programming what a run-time profiler is to ordinary code. The templight profiler itself has reached a fairly stable state. It works at least under Linux and Windows (through "templight-cl.exe", which is a drop-in replacement for "clang-cl.exe", which is compatible with MSVC "cl.exe"), but probably works wherever clang works. Which means that you are welcome to try it. I have also used it successfully to build a few cmake-based projects (by setting CC and CXX environment variables to point to templight). Templight is currently also used in the back-end of the "metashell" project as well (an interactive shell interpreter and debugger for C++ template meta-programs). You can build the templight profiler against the clang source (with a patch + some added code), as it instructs on the github readme: https://github.com/mikael-s-persson/templight But most recently, I have created a separate set of tools to convert templight trace files to other formats. The most awesome of these outputs is the "callgrind" output, which produces a "meta-"call-graph, that is similar to (and in the same format as) call-graphs generated by run-time profiling tools like callgrind, but the profiling data is, of course, related to the compilation costs (time / memory). That conversion tool is available here: https://github.com/mikael-s-persson/templight-tools With that, you can open the converted templight trace files in the visualization tool KCacheGrind, which is great (works both on unix-like systems and Windows, thanks to Qt5). Here is a screenshot of that for one of Boost.Container's example programs: https://raw.githubusercontent.com/mikael-s-persson/templight-tools/master/i… I really hope that some of you will give this a try. I'm really hoping that it will be useful to you, and that you can provide feedback and feature requests. I couldn't think of any better target audience for this tool. Cheers, Mikael. -- Sven Mikael Persson, M.Sc.(Tech.) PhD Candidate and Vanier CGS Scholar, Department of Mechanical Engineering, McGill University,

2 3

[config] [detail] Macro BOOST_WORKAROUND
by Andrzej Krzemienski 28 Jan '15

28 Jan '15

Hi Everyone, I have a couple of concerns regarding macro BOOST_WORKAROUND. 1. Is usage thereof recommended? 2. Why is it documented in Boost.Config but defined in Boost.Detail? 3. Should it not belong to Boost.Config? 4. Why should I use it rather than manual if (BOOST_INTEL < 551) ? Now, that it is in Boost.Detail, I have to make a dependency on Boost.Detail, and indirectly on Boost.MPL because other components in Boost.Detail do. Regards, &rzej

4 4

[test] Who had the emulation of Test written using gtest?
by Niall Douglas 28 Jan '15

28 Jan '15

Sometime during the past few weeks someone mentioned they had written out a set of Boost.Test macros which converted Boost.Test unit test suites into Google Test without needing to modify the Boost.Test using unit test suite. Can whoever that was make themselves known to me please? It would save having to replicate your effort here ... thanks in advance. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Re: [boost] [filesystem, regex, asio] These three libraries successfully ported to Windows Phone 8.1
by Moshe Rubin 28 Jan '15

28 Jan '15

On January 27, 2015 09:55 GMT, Paul A. Bristow wrote: >>> And thank you very much for the improved WinRT support. >> >> My pleasure. It was an education for me (in the positive sense of the >> word!) participating in porting Boost. I will only rest on my laurels >> once the port authorized by the crew and back in the repository <g>. > > I'm pleased to see that Windows Phone developers will now be able to use these Boost libraries. When we went looking for Boost ports for Windows Phone 8, we had a sinking feeling because no one had ported any of the libraries to WinRT. Steven Gates of Microsoft took the first step, and was a great encouragement to me and my company. I'm glad to be able to return the favor to the Boost project, as we have benefited very much from this excellent collection of libraries. > I'm also curious to know if you have tried to port the Boost.Math library? > > Although it contains a lot of esoteric mathy stuff that are unlikely to be mainstream on a phone > app, there are also some very simple-to-use statistics stuff that will/should be widely applicable. > > Have you tried this yet? Are there any obstacles that you can foresee? We did not need Boost.Math in our product so I did not look into building it. I'm happy to say that I just now built it for Windows Phone 8.1 on a Visual Studio 12 2013 system and it compiles and creates the resulting libs like a pro: <command> b2 toolset=msvc-12.0 windows-api=phone architecture=arm link=static --with-math variant=debug debug-store=database debug-symbols=on pch=off cxxflags=-ZW stage </command> Libraries created: (*) libboost_math_tr1-vc120-mt-gd-1_58.lib (*) libboost_math_tr1f-vc120-mt-gd-1_58.lib (*) libboost_math_c99-vc120-mt-gd-1_58.lib (*) libboost_math_c99f-vc120-mt-gd-1_58.lib The only warning message received, and there are many of these, is LNK4264: <snippet> msvc.archive bin.v2\libs\math\build\...\libboost_math_tr1-vc120-mt-gd-1_58.lib bin.v2\libs\math\build\...\sph_neumann.obj : warning LNK4264: archiving object file compiled with /ZW into a static library; note that when authoring Windows Runtime types it is not recommended to link with a static library that contains Windows Runtime metadata bin.v2\libs\math\build\...\sph_legendre.obj : warning LNK4264: archiving object file compiled with /ZW into a static library; note that when authoring Windows Runtime types it is not recommended to link with a static library that contains Windows Runtime metadata bin.v2\libs\math\build\...\sph_bessel.obj : warning LNK4264: archiving object file compiled with /ZW into a static library; note that when authoring Windows Runtime types it is not recommended to link with a static library that contains Windows Runtime metadata . . . bin.v2\libs\math\build\...\beta.obj : warning LNK4264: archiving object file compiled with /ZW into a static library; note that when authoring Windows Runtime types it is not recommended to link with a static library that contains Windows Runtime metadata bin.v2\libs\math\build\...\assoc_legendre.obj : warning LNK4264: archiving object file compiled with /ZW into a static library; note that when authoring Windows Runtime types it is not recommended to link with a static library that contains Windows Runtime metadata bin.v2\libs\math\build\...\assoc_laguerre.obj : warning LNK4264: archiving object file compiled with /ZW into a static library; note that when authoring Windows Runtime types it is not recommended to link with a static library that contains Windows Runtime metadata common.copy stage\lib\libboost_math_tr1-vc120-mt-gd-1_58.lib bin.v2\libs\math\build\...\libboost_math_tr1-vc120-mt-gd-1_58.lib 1 file(s) copied. </snippet> I encountered many of these warnings when building my ported libraries. The online documentation seems to indicate that this is a recommendation. I can tell you that the ported libraries, with these warnings, all function correctly with no problems. In short, it looks like Boost.Math compiles as-is for Windows Phone 8.1. Moshe

2 1

Re: [boost] [filesystem, regex, asio] These three libraries successfully ported to Windows Phone 8.1
by Moshe Rubin 28 Jan '15

28 Jan '15

On 28 Jan 2015 at 02:04:22 GMT, Niall Douglas wrote: > And once again, my apologies for earlier. It is no excuse, but that > particular day I had the misfortune of combining codeine and a lot of > cough medicine due to a heavy flu. This affected my mind. I was quite > appalled with myself when I read what I had written to you the next > day, very embarrassing, I was clearly off in a grim imagination land > and had completely underestimated its effects on my wits. > > As a token of making good on my earlier behaviours, do feel free to > email me off list to review your pull requests for any problems, > either before or after you submit them. And thank you once again for > making the effort, it is hugely appreciated here. Rest assured, I harbor no ill will at all. Quite the contrary, notwithstanding the text written, it was obvious you were a battle-seasoned professional and knowledgeable software engineer, one worth listening to. As a newbie to the Boost mailing list, I have gained invaluable information from you and others that will stand me in good stead. The ones to feel sorry for are those involved in the Linux kernel -- Linus Torvalds most certainly does not apologize for his comments! <g> I appreciate your candor, a welcome trait in the professional world. I'm currently working on verifying the changes using the regression test suite, and cleaning up the changes based on the comments you posted the other day. Thank you for your kind offer to eyeball my pull requests before or after submitting them. I will certainly feel free to take you up on your offer. Moshe

1 0

[filesystem, regex, asio] These three libraries successfully ported to Windows Phone 8.1
by Moshe Rubin 28 Jan '15

28 Jan '15

After the helpful advice I received in this mailing list and other forums, I'm happy to report that the three Boost libraries, filesystem, regex, and asio have been successfully ported to Windows Phone 8.1. Our corporate product is back up and running on Windows Phone 8.1 devices. I assume there are others who will be happy to download the new Boost code for use in their WP 8.1 apps. These libraries will hopefully join those already ported by Steven Gates of Microsoft [http://blogs.msdn.com/b/vcblog/archive/2014/07/18/using-boost-libraries-in-…] I am therefore beginning the process of verifying the port using the Boost regression test suite (I have to decide how to get them to run under Windows Phone 8.1). When the code has passed the regression suite I will issue a pull request against the GitHub repository. Thanks again to everyone in this list for their helpful comments and suggestions, Moshe Rubin Technology Manager Hyperlync Technologies Ltd. Jerusalem, Israel

4 5

Re: [boost] [filesystem, regex, asio] These three libraries successfully ported to Windows Phone 8.1
by Moshe Rubin 27 Jan '15

27 Jan '15

On 26 Jan 2015 15:51, Niall Douglas wrote: >> When the code has passed the regression suite I will issue a pull >> request against the GitHub repository. > Some tips for creating a successful pull request: > > 1. Avoid #ifdef spam. Write thunk emulations of missing APIs where possible. Here's an example for GetTickCount64(): > https://github.com/boostorg/thread/blob/master/include/boost/thread/wi > n32/thread_primitives.hpp#L290. Remember Boost still supports Windows XP and exclusively targets an XP level Win32 API. Use GetProcAddress for newer APIs. > > 2. Avoid using macros to implement functionality. > > 3. Don't forget to modify the documentation where needed to support the changes. > > 4. It might sound obvious, but make sure the unit test suite still passes on Windows XP in default build settings on all of MSVC-8, > mingw32 and mingw-w64. You'd be surprised how often pull requests don't because they use some Vista or later API, or an API not supported by mingw32. If a pull request doesn't instantly go all green on all supported platforms it tends to not be merged and get put > off till much later (sometimes forever). > > Right now cygwin support is broken at least in thread, but other libraries are probably a lot better, so test that too. > > 5. Consider additional unit tests where appropriate. In this situation I'd doubt you'd need them. These are excellent points, obviously the product of your own "battles" with modifying the Boost source base. Many thanks for sharing them, and now is the perfect time to learn them. > And thank you very much for the improved WinRT support. My pleasure. It was an education for me (in the positive sense of the word!) participating in porting Boost. I will only rest on my laurels once the port authorized by the crew and back in the repository <g>. Moshe

3 2

[release] Release schedule changes..
by Rene Rivera 27 Jan '15

27 Jan '15

After some discussion in the Boost Release Team we've decided on an ongoing schedule for releases. Taking into account the realities of how long it takes for authors and the release team to work on a release we've decided to move to *three* releases a year. The targets for the releases will now be: * Spring release on the second Wednesday of April. * Summer release on the second Wednesday of August. * Fall/Winter release on the second Wednesday of December. There will be no January release. This will allow for the fact that most people are on extended holidays during Winter. It will also allow for people to work on larger changes that require more testing time during the longer Winter period. We are also moving to Wednesday release to allow the release managers non-weekend time to work before and after the release. Please consult the Boost calendar for specific dates and merge schedule for the next release. Thanks, the Boost Release Team. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

Boost modular: Build without version number suffixes
by Robert Dailey 27 Jan '15

27 Jan '15

When I build modular boost on Linux Mint 17, I get SO files named like so: libboost_date_time.so.1.57.0 with a corresponding symlink without the version number: libboost_date_time.so I'd like it to build without the version number because when I rename the base file to remove the version, code links fine but during runtime it tries to load the SO with the version number at the end. I don't know how to fix that, so I assume the fix is to build boost without the version numbers. Any help is appreciated.

5 8

[doc][build]
by Damian Vicino 27 Jan '15

27 Jan '15

Hi, I noticed the boost.build site links to documentations are broken in http://www.boost.org/doc/libs/1_57_0/tools/build/index.html <http://www.boost.org/doc/libs/1_57_0/tools/build/index.html>: http://www.boost.org/doc/libs/doc/html/bbv2.html <http://www.boost.org/doc/libs/doc/html/bbv2.html> http://www.boost.org/doc/libs/1_57_0/tools/build/doc/userman.pdf <http://www.boost.org/doc/libs/1_57_0/tools/build/doc/userman.pdf> both return 404. I got there following links in installation documentation.

1 0

[endian] [bikeshed] Conversion function naming discussion
by Beman Dawes 26 Jan '15

26 Jan '15

Naming is always a bike shed issue. I'm starting a separate thread for those who don't care can easily ignore it. The current names I'm least comfortable with are the conversion function names in the endian sub-namespace: big_to_native big_to_native_inplace native_to_big native_to_big_inplace little_to_native little_to_native_inplace native_to_little native_to_little_inplace conditional_reverse conditional_reverse_inplace These are quite explicit, but are a bit too long and awkward for my taste. I'd be willing to change these names if someone can come up with replacements that are shorter and less awkward, but still reasonable explicit. --Beman

4 5

Boost 1.58 schedule available?
by Barend Gehrels 26 Jan '15

26 Jan '15

Hi, Boost 1.57 was released last November 3, so it is probably about the time to merge to master again? Is there already a schedule available? Thanks, Barend

13 36

RFC Expression Validity Asserts
by Matt Calabrese 26 Jan '15

26 Jan '15

I've found it useful, especially in tests, to easily be able to do expression validity checking via SFINAE in a static assert. In other words, it's frequently useful to want to quickly test to make sure that a particular expression does or does not compile, similar in some ways to a concepts-lite usage pattern. The general idea is that you want to static assert that, given a series of object declarations of a specific type, a specified expression or series of expressions that deal with those objects would or would not cause substitution to fail had the object types been dependent on a template parameter. It internally relies on a macro that is invoked as such: ////////// IS_VALID_EXPR( (int) a, (float) b, // etc.. (a + b) (a - b) // etc. ) ////////// The above macro invocation results in an expression that is a constexpr bool which is true iff substitution would not fail. With the above macro, one can do, for instance: static_assert(IS_VALID_EXPR((const int) a, ++a), "Some error message."); I've found this pattern so common that I've created a macro that takes such a series of declarations and expressions and automatically produces a simple static_assert, outputting the declarations and the expression that did not compile. A slimmed down version of this macro can be toyed with via the link below (this slim version allows only one declaration and one expression per macro): http://ideone.com/RHd6FM Briefly, using the macro as such: STATIC_ASSERT_VALID ( (const int) a, ++a ); is able to produce a very human-readable error message: prog.cpp:58:1: error: static assertion failed: ******************** Given: const int a; The following expression was expected to compile but did not: ++a ******************** There is a similar macro for verifying that an expression does not compile, which I find is much more useful in practice. Notable is that the validity macro is an expression -- no statement or other declarations are introduced -- and the static assert macro produces a single static_assert. This means that you can use the assertion macro in the normal scopes that any static_assert can be used (namespace scope, class scope, function scope...). One limitation is that because it uses lambdas behind the scenes, the context in which the validity macro may be used is slightly restricted (I.E. it can't be used in an un-evaluated context). Is this something people would generally find useful? If it is considered generally useful, I don't think it's really worthy of its own library, so where would it go? Years ago I probably would have just assumed utility, but I'm not really sure where it would go in the modern boost structure. The slim version can easily have no dependencies, though the more general solution ideally depends on Boost.Preprocessor. The macros themselves require C++14, though slightly less-useful forms (ones that introduce additional declarations) could be made that would work in C++11. -- -Matt Calabrese

5 14