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

Version mismatch on develop
by Peter Dimov 20 May '15

20 May '15

On the current develop, autolink wants to link to (for instance) libboost_filesystem-vc80-mt-s-1_59.lib, but b2 builds libboost_filesystem-vc80-mt-s-1_58.lib. That's because BOOST_VERSION has been updated to 1.59 in boost/version.hpp, but is still 1.58 in Jamroot.

2 1

[type_traits] A bug in has_nothrow_default_constructor
by Andrzej Krzemienski 20 May '15

20 May '15

Hi All, I have submitted a new ticket: https://svn.boost.org/trac/boost/ticket/11324 Given the information floating around that Boost.TypeTraits are unmaintained and that they are to be replaced with the rewrite, is there any chance that this is fixed, or at least the test case added to regression matrix? BTW, does type_traits v2 handle this case correctly? Regards, &rzej

2 2

[Testing] Android clang tests
by John Maddock 20 May '15

20 May '15

Since all the Android/clang tests which use PCH are failing, can we either: * Change the build options to disable PCH, or better, * Fix the clang toolset? Someone who understands clang on Android would have to do the latter. See http://www.boost.org/development/tests/develop/developer/output/CrystaX-NET… for an example fail. Many thanks, John.

3 4

crash in boost/date_time/microsec_time_clock.hpp:70 v1.55
by George Georgiev 20 May '15

20 May '15

Hi, I am having crash in in local_time () at boost155_lin32_gcc480//include/boost/date_time/microsec_time_clock.hpp:70 I can call this in isolation and there is no issues, but in the production calls it crashes 100% reproducible with Program terminated with signal SIGABRT, Aborted. The only difference I could think about it is that the call is made from a dynamically loaded library. Is there any known issue about this? Thanks, George

4 3

Getting a trac id
by Steven Ross 19 May '15

19 May '15

I have a bug filed against my library, but with no trac ID I can't modify the bug. How do I get a trac ID?

2 1

RemoteCall framework for RPC
by Alex Marmer 19 May '15

19 May '15

Hello, I created a C++ framework RemoteCall which allows to use RPC the same way as local C++ calls are used. For declaration, implementation and call used macros: DECLARE_REMOTE, IMPLEMENT_REMOTE, CALL_REMOTE.Return and parameters (In and In/Out) can be any type except pointers. For instance: std::tuple<in, bool> DECLARE_REMOTE(Test)(std::vector<std::string>& vInOut, const std::wstring& sIn). Implementation is on https://github.com/amarmer/RemoteCall Would it be useful to add this framework in Boost? Sincerely,Alex

4 8

[all][testing] Regression summary upgrades
by Adam Wulkiewicz 18 May '15

18 May '15

Hi, Recently the regression summary was upgraded. The cells corresponding to the failing tests can have names comp, link, run or fail. This way we can see what's the nature of the failure without going into details. See, e.g. the tests for Math: http://www.boost.org/development/tests/develop/developer/math.html The last category of failures (generic "fail") is for the others or unknown. Currently the "Lib" errors are falling into this category. There are some in Math, e.g.: http://www.boost.org/development/tests/develop/developer/output/CrystaX-NET… So we could mark them explicitly as "lib" failures and then the other/unknown failures could be marked as "unkn" or left as it is now - "fail". This has sense if there can be other "types" of failures, e.g. caused by some error in the testing scripts, Build or Regression, for which the reason is somehow unknown. Though I haven't seen them. I propose to go further with this and to mark the compilation failures for which we know the reason of the failure in a special way: - "file" - file too big (reported on Windows, e.g. http://www.boost.org/development/tests/develop/developer/output/MinGW-w64-4…) - "time" - time limit exceeded (e.g. http://www.boost.org/development/tests/develop/developer/output/teeks99-03b…) I saw them in many libraries and I think it would be very useful for libraries having many tests like Math or Geometry. The other types of failures I could think of aren't that important for me personally but maybe someone could appreciate them, e.g. the compilers developers: - "ierr" or "cerr" - internal compiler error or segmentation fault during compilation (e.g. http://www.boost.org/development/tests/develop/developer/output/PNNL-RHEL6_… or http://www.boost.org/development/tests/develop/developer/output/teeks99-03h…) - "segf" - segmentation fault during run (http://www.boost.org/development/tests/develop/developer/output/BenPope%20x…) Furthermore I propose to use various colors for different failure reasons. You can see the examples here: https://github.com/awulkiew/summary-enhancer https://github.com/awulkiew/summary-enhancer/tree/master/example/pages Of course the colors could be changed. We should be able to modify them in the master.css file. In the examples above they are varying much to make a clear distinction between them. But if you like the yelow collor then all of the new failures could be yelowish with a slight accent of another color, e.g. compilation errors could be yellow with orange accent and "time"/"file" errors with green accent. Regards, Adam

11 27

Spirit 3.0.0
by Joel de Guzman 18 May '15

18 May '15

Hello! C++ Now 2015. Today is the official release of Spirit X3, aka Spirit 3.0.0. X3 will be in beta, coexisting side by side with Qi, Karma, Lex and Classic. If you are a Qi user. The best place to start are the examples, especially rexpr and x3 fun. Remember to use a compiler with c++14 capabilities: clang 3.4 or greater gcc 4.9 or greater Follow this link for more: http://boost-spirit.com/home/2015/05/16/spirit-3-0-0/ Cheers! -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/

4 5

[type_traits] Time to upgrade to "version 2" ?
by John Maddock 17 May '15

17 May '15

Now that the release is out it's decision time: I'd like to merge the "Version2" branch of type_traits to develop, it passes all the tests, and I've been using it exclusively for testing and development locally for a few months now without issues. But.... it's a big change with the potential to break a lot of folks stuff if things go wrong given that this is such a core component. To recap the main advantages are: * Removed all the redundant cruft that's no longer required for old/broken compilers we don't support anymore anyway. * Very nearly dependency free (other than Config), there's just comon_type which still has dependencies elsewhere - and even that disappears for a C++11 compiler. * Much cleaner, easier to understand code, now that the horrid obfuscating macros introduced by MPL have gone. * Fewer template instantiations than before as much of the indirection / forwarding templates have been removed. * As a result code using these headers should be somewhat faster to compile - both with fewer template instantiations, and a much lighter #include load. Note that as a result of this change, a number of undocumented headers which were none the less being used in Boost have been deprecated. The headers still exist, but warn loud and clear about their deprecated status, so folks will get a lot of warnings to begin with. I know Edward Diener has submitted some PR's to fix these, but I plan to make a concerted attack on any remaining once the new version is in develop. So here's the question, how do we proceed? My thoughts are to basically go ahead and merge, but not merge to master until after the next release at the earliest to give everything a chance to bed down, and the required changes in other libraries to filter through. Or we could have some sort of mini-review either formally or informally to check things out before the merge - of course folks are most welcome to do this anyway! Let me know what you think, best, John.

9 14

[type_traits] difference in decay semantic between boost and standard library
by Anton Bikineev 17 May '15

17 May '15

Hi Boost, Is it expected semantic of boost::decay not to strip top-level constness? Thanks.

1 0