- Boost - lists.boost.org

Deprecation Policy
by Rob Stewart 21 May '15

21 May '15

Some Boost libraries are unmaintained, some are under-maintained, and others have been replaced by newer libraries or by the Standard Library. Boost needs to decide whether to deprecate such libraries, and if so, how and when to do it. Please consider my initial thoughts below and provide ideas on such a policy. I will try to capture your ideas and create a policy statement for later review. It would seem obvious that unmaintained libraries should be deprecated, but a library that works, even if it has some known bugs, doesn't grow worse over time. Thus, if an unmaintained library was included in one Boost release, continuing to include it is no worse than before. That implies that deprecating Unmaintained libraries is not a given. Another issue is deciding when a library is unmaintained. Boost prefers that library authors and maintainers seek a replacement when no longer able to provide maintenance. Unfortunately, that doesn't always happen. Thus, establishing criteria by which to judge a library as unmaintained is warranted. Many continue to use C++03 and benefit from the presence of libraries that only support that language. I think it a non-starter to suggest that a library is unmaintained, or under-maintained, because it hasn't been updated to use C++11/14. Indeed, a replacement library may be the better way forward, while the old library might remain in Boost releases. Some have suggested that libraries with Standard Library equivalents be considered deprecated. Note that such libraries provide equivalent or similar functionality for older compilers, so I think that they should be treated the same as C++03-only libraries. Libraries that have superior replacements in Boost releases seem like obvious candidates for deprecation. There is precedent for that: Boost.Signals was deprecated in favor of Boost.Signals2. There are some likely libraries in this category, such as Boost.Lambda. Once we reach consensus on how to identify libraries to deprecate, we then must decide on the process. How long should a deprecated library be released before it is removed from Boost releases? How do we mark deprecated libraries? What do we do with deprecated libraries that have been removed from Boost releases? ___ Rob (Sent from my portable computation engine)

12 33

[preprocessor] Link to Boostpro site for introduction to preprocessor metaprogramming
by Edward Diener 20 May '15

20 May '15

The preprocessor documentation has a link to the Boostpro site which had an html version of the Appendix A of "C++ Template Metaprogramming" by Abrahams and Gurtovoy. Appendix A is "An Introduction to Preprocessor Metaprogramming", which is all about Boost PP. Alas Boostpro is no more and the link in the preprocessor documentation goes nowhere. I can remove the link and any notice of the introduction. But If either David Abrahams or Aleksey Gurtovoy are still around it would be nice to get the html pages which existed before and incorporate them into the Boost PP docs. Does anyone know how to contact either of them ? I can try their addresses in maintainers.txt but I do not want to directly encroach on their privacy if there is a better way.

2 4

Interest in non-intrusive signal/slot lib?
by Emil Dotchevski 20 May '15

20 May '15

Hello, I realize that Boost has Signals library already, but I've implemented a non-intrusive one which approaches the problem differently, and I'm pretty sure that there is no overlap between the two. It turned out more generic than I originally anticipated, so I thought I'd ask if others would find it useful as well. Specifically I was motivated by wanting to use Qt without MOCing. I asked the Qt community if that was possible which generated several rather annoyed negative responses. :) The issue is that while in Qt it's possible to use any function as a Slot, to define a new Qt signal for an existing Qt type one needs to derive from the Qt type, define the signal (as a member function) and do the MOC dance -- which I wanted to avoid. The result is a small, non-intrusive signals/slots library that allows objects of any type to be used as signal emitters, e.g. one of the included examples shows how signals can be emitted by a Windows HWND object. Documentation and source code released under the Boost license can be found here: http://www.revergestudios.com/boost-synapse/. Thanks, Emil P.S. Thanks to Peter Dimov for his feedback and for coming up with the name Synapse. :)

9 48

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