- Boost - lists.boost.org

[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

A possible solution to the SFINAE/decltype puzzler
by pfultz2 01 Feb '15

01 Feb '15

A couple years ago Eric Niebler posted a question on here about improving error messages with SFINAE and trailing decltype: http://boost.2283326.n4.nabble.com/C-11-decltype-SFINAE-puzzler-td4632622.h… The problem was getting a useful error message when writing something like this: struct h_f { template<class T> auto operator()(T x) const -> decltype(*x) { return *x; } }; constexpr static h_f h = {}; struct g_f { template<class T> auto operator()(T x) const -> decltype(h(x)) { return h(x); } }; constexpr static g_f g = {}; struct f_f { template<class T> auto operator()(T x) const -> decltype(g(x)) { return g(x); }; }; constexpr static f_f f = {}; int main() { f(0); } His solution at the time was to turn the substitution failures into errors. Of course, this has some problems as well. First, it removes the template constraints from the functions. Secondly, it can produce more errors(rather than one error with multiple "notes"). Ideally, it would be better to transport to the top the substitution failures. Well, using template aliases this can be done: https://gist.github.com/pfultz2/3d66795ef18361699fbb When I compile this code I get an error like this: reveal1.cpp:104:5: error: no matching function for call to object of type 'const reveal_failure<f_f>' f(0); ^ reveal1.cpp:56:10: note: candidate template ignored: substitution failure [with Ts = <int>, Id = identity]: indirection requires pointer operand ('int' invalid) auto operator()(Ts&&... xs) const -> decltype(F()(std::forward<Ts>(xs)...)) ^ Now, when there is multiple overloads(or multiple notes), this can be extended to handle this situation, as well. An overload for each note, can be added. Plus, the backtrace can be "flattened" so that only the "leafs" are shown. I do this here: https://gist.github.com/pfultz2/ac74129e73393f798e41 So for the 'advance' function it shows an error like this: reveal2.cpp:288:5: error: no matching function for call to object of type 'reveal<conditional<advance_advanceable, advance_decrementable, advance_incrementable> >' advance(f, 1); ^~~~~~~ reveal2.cpp:215:13: note: candidate template ignored: disabled by 'enable_if' [with Ts = <foo &, int>, Id = identity] REQUIRE_OF(models<Advanceable(Iterator, int)>()); ^ reveal2.cpp:7:82: note: expanded from macro 'REQUIRE_OF' #define REQUIRE_OF(...) template<class Id> using apply = typename std::enable_if<(Id()(__VA_ARGS__)), int>::type ^ reveal2.cpp:234:13: note: candidate template ignored: disabled by 'enable_if' [with Ts = <foo &, int>, Id = identity] REQUIRE_OF(models<Decrementable(Iterator)>()); ^ reveal2.cpp:7:82: note: expanded from macro 'REQUIRE_OF' #define REQUIRE_OF(...) template<class Id> using apply = typename std::enable_if<(Id()(__VA_ARGS__)), int>::type ^ reveal2.cpp:258:13: note: candidate template ignored: disabled by 'enable_if' [with Ts = <foo &, int>, Id = identity] REQUIRE_OF(models<Incrementable(Iterator)>()); ^ reveal2.cpp:7:82: note: expanded from macro 'REQUIRE_OF' #define REQUIRE_OF(...) template<class Id> using apply = typename std::enable_if<(Id()(__VA_ARGS__)), int>::type ^ reveal2.cpp:168:10: note: candidate template ignored: substitution failure [with Ts = <foo &, int>]: no matching function for call to object of type 'advance_advanceable' auto operator()(Ts&&... xs) -> decltype(F1()(std::forward<Ts>(xs)...)) ^ ~~ reveal2.cpp:174:10: note: candidate template ignored: substitution failure [with Ts = <foo &, int>, $1 = 0]: no matching function for call to object of type 'conditional<advance_decrementable, advance_incrementable>' auto operator()(Ts&&... xs) -> decltype(F2()(std::forward<Ts>(xs)...)) ^ So there is one note for each overload of `Advanceable`, `Decrementable`, and `Incrementable`. There is two additional notes at the bottom, this comes from the original function(ideally it would need to be normalized). I go into more detail about how this works here: http://pfultz2.com/blog/2015/01/31/improving-error-messages/ However, this is isn't quite perfect yet. First, it requires putting the type requirements into a nested failure struct. Secondly, not all the types are reported back to clang. It doesn't show the user what type `Iterator` is. Ideally, it would be nice if there was a way to push clang to report the substitution failure at least one level deeper for an expression. This is about as close as I've gotten. Is there any feedback? Questions? Perhaps some improvements? Thanks, Paul Fultz II -- View this message in context: http://boost.2283326.n4.nabble.com/A-possible-solution-to-the-SFINAE-declty… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

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