- Boost - lists.boost.org

[Boost.DI] Formal review request
by Krzysztof Jusiak 20 Jan '15

20 Jan '15

Dear Boost, I'd like to request a formal review of Boost.DI. Description: Boost.DI is C++14 header only, type safe library providing compile time, macro free constructor dependency injection. - Reduces boilerplate code - Reduces cost of maintenance effort - Reduces testing effort - Gives better control of what and how is created - Gives better understanding about objects hierarchy Source Code: https://github.com/krzysztof-jusiak/di Documentation: http://krzysztof-jusiak.github.io/di/boost/libs/di/doc/html Boost Library Incubator: http://rrsd.com/blincubator.com/bi_library/di-dependency-injection/?gform_p… Interest: http://lists.boost.org/Archives/boost/2014/07/215487.php Thanks, Kris

2 2

Clang 3.4 failing to compile boost 1.57 headers
by Robert Dailey 19 Jan '15

19 Jan '15

I'm including <boost/format.hpp> and getting this error from Clang 3.4 on Ubuntu 12: In file included from /home/fe/frontend/Core/ThirdParty/boost/include/boost/format.hpp:38: In file included from /home/fe/frontend/Core/ThirdParty/boost/include/boost/format/internals.hpp:23: In file included from /home/fe/frontend/Core/ThirdParty/boost/include/boost/format/alt_sstream.hpp:21: In file included from /home/fe/frontend/Core/ThirdParty/boost/include/boost/shared_ptr.hpp:17: In file included from /home/fe/frontend/Core/ThirdParty/boost/include/boost/smart_ptr/shared_ptr.hpp:28: In file included from /home/fe/frontend/Core/ThirdParty/boost/include/boost/smart_ptr/detail/shared_count.hpp:30: /home/fe/frontend/Core/ThirdParty/boost/include/boost/smart_ptr/detail/sp_counted_impl.hpp:229:31: error: no type named 'allocator_traits' in namespace 'std' typedef typename std::allocator_traits<A>::template rebind_alloc< this_type > A2; ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~ Is this a bug or am I missing something? I'm using -std=C++11 flag.

6 20

Testing and toolsets
by Andrzej Krzemienski 19 Jan '15

19 Jan '15

Hi Everyone, Could anyone give me some information on how regression test matrix is supposed to work? I can see that when testers run their tests they specify a toolset; this toolset is reported in test matrix, and based on this toolset name failures in tests can be labeled as expected. Did I get it right? However, the fact that a tester turns C++11 support or not, is not necessarily reflected in the toolset name (some testers indicate it in the toolset name, others don't). On the other hand C++11 being turned on or off can affect the test results. In that case the toolset name alone is not sufficient to make a decision whether I expect a failure or not. Is there some policy for addressing this problem? Am I the only person to be affected? Regards, &rzej

8 13

How to get tests running for new library
by Steven Ross 19 Jan '15

19 Jan '15

I've added the new Sort library: https://github.com/boostorg/sort How do I get automated tests running and generating results at: http://www.boost.org/development/tests/master/developer/math.html ? Also, how do I add Sort to Trac, so I can get bug reports?

5 6

[math][integer] Moving integer utilities out of the math lib.
by John Maddock 19 Jan '15

19 Jan '15

This does look to me like a good idea, but to remain coherent, all of http://www.boost.org/doc/libs/1_57_0/libs/math/doc/html/gcd_lcm.html should move, which means: common_factor.hpp common_factor_rt.hpp common_factor_ct.hpp Plus docs and tests. Further I'd like to see the headers under boost/integer/*.hpp and the namespace changed to boost::integer. For backwards compatibility the boost/math/*.hpp headers should be present also but merely include the new ones and import the symbols into boost::math via using declarations. One SNAFU I see is that boost.integer is a largely unmaintained ragbag of utilities (though often very useful). It would be nice if someone would take responsibility for this library: any takers? It might be the right time too to move the rest of Boost.Integer into boost::integer rather than dumping everything in namespace boost? And finally to provide a "soft landing" for existing users, the Math lib docs should retain a stub page for these utilities that points to the new docs - Paul and I can take care of that one. Does that look like a plan? Anyone care to take it on? Best, John.

8 18

Warning policy? local variable hides (i.e. shadows) global variable
by Beman Dawes 19 Jan '15

19 Jan '15

GCC and Clang have had a warning for years (-Wshadow): "Warn whenever a local variable or type declaration shadows another variable, parameter, type, class member (in C++), or instance variable (in Objective-C) or whenever a built-in function is shadowed. Note that in C++, the compiler warns if a local variable shadows an explicit typedef, but not if it shadows a struct/class/enum." VC++ 2015 (aka 14.0) Preview has now added a similar warning, C4459. For example, "c:\boost\modular\develop\boost\lexical_cast\detail\converter_lexical_streams.hpp(429): warning C4459: declaration of 'n' hides global declaration". The VC++ warning also provides location info so is easy to view both the declarations involved. In this case, the declaration "bool operator<<(short n)" is shadowing a variable name in the unnamed namespace of the calling translation unit. The process of clearing these shadow warnings occasionally finds bugs that are otherwise difficult to detect. Peter Dimov and I have both found bugs in our code in the process of clearing the new C4459 warning. Even though most of the warnings don't actually signify bugs, I'm finding that clearing them makes code clearer and less confusing, particularly code I haven't looked at in a long while. Should Boost have policy to clear these warnings? A lot of the warnings involve function argument names. Should we have a guideline to prevent shadow warnings? A convention for argument names would make it easier to submit pull requests. Possible guidelines: * Prefix function argument names with "a_". Rationale: The "m_" prefix for member names has been a success. * Suffix function argument names with "_". Rationale: Short and less distracting than "m_" prefix. Thoughts? --Beman

12 29

URGENT: Regression testing repo migration..
by Rene Rivera 19 Jan '15

19 Jan '15

I'm going to remove the outdated regression testing code in the boostorg/boost super-repo the weekend of January 24th. Everyone MUST stop using the old scripts immediately as they will disappear in approximately 7 days. *** All testers please migrate to using this run.py NOW <https://raw.githubusercontent.com/boostorg/regression/develop/src/run.py>. *** All report generation please migrate to using the comprehensive build_results_all.sh script NOW: < https://raw.githubusercontent.com/boostorg/regression/develop/xsl_reports/b… >. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3 2

[iostreams][gzip][zlib] zlib vs gzip, and linking against external libraries
by Aaron Levy 18 Jan '15

18 Jan '15

What is the difference in functionality between gzip and zlib compression? I built Boost iostreams library on Linux after exporting ZLIB_SOURCE and BZIP2_SOURCE environment variables. However when I build a sample program using gzip / bzip2 with IOStreams, I do not need to link to libzlib or libbz2. Is the zlib / bz2 code built into libboost_iostreams in this case? For reference, this is the command line I used to build the iostreams library. ./b2 --with-iostreams --build-dir=../build threading=multi variant=release link=shared runtime-link=shared -- Aaron Levy aaron.levy(a)yandex.com

3 2

Building the entire Boost documentation as Windows HTML help
by Philip Bennefall 18 Jan '15

18 Jan '15

Hi all, Is it possible to build a Windows HTML help file from the Boost documentation? It'd be a nice way of navigating it, and it's a single file so is trivial to move around. Has anyone attempted to do this? Kind regards, Philip Bennefall

1 0

Re: [boost] (correction) Clang 3.4 failing to compile boost 1.57 headers
by Fletcher, John P 18 Jan '15

18 Jan '15

Sorry folks, my value for Clang and gcc 5.0.0 was wrong - it does report 50000 I had a fault in my configuration and it was dropping back to the default 4.6.3 John ________________________________________ From: Boost [boost-bounces(a)lists.boost.org] on behalf of Peter Dimov [lists(a)pdimov.com] Sent: 18 January 2015 18:54 To: boost(a)lists.boost.org Subject: Re: [boost] Clang 3.4 failing to compile boost 1.57 headers Fletcher, John P wrote: > Results are as follows for clang 3.5 > > gcc version gcc reports clang reports > 4.6.3 40603 40700 > 4.8.2 40802 40800 > 4.9.0 40900 40900 > 4.9.2 40902 40900 > 5.0.0 50000 40700 <- actually 50000 > > I can see that there are some serious problems getting the correct > identification with Clang. Looks like unless it recognizes 4.8 or 4.9, it reports 40700 by default, which would make things a bit complicated. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0