February 2018 - Boost - lists.boost.org

[CppCMS] What can be contributed to Boost?
by Artyom Beilis 02 Feb '18

02 Feb '18

Hello Dear Boost Developers, Recently I had released CppCMS - C++ Web Framework 1.2 under MIT license instead of LGPLv3 See: http://cppcms.com Since CppCMS project had already contributed some of its parts for Boost: Boost.Locale - in Boost for long time Boost.Nowide (passed review still need some my time to integrate to release) I wanted to renew the discussions of what parts may interest the community Boost outside CppCMS. Some samples I thought of: -------------------------------------------- Once I can think of is cppcms::json http://cppcms.com/wikipp/en/page/cppcms_1x_json http://cppcms.com/cppcms_ref/latest/classcppcms_1_1json_1_1value.html Also it should be updated to C++11 and probably do some small features updates. it is one of the fastest JSON parsers around (and yes it is way faster and convenient than one in property tree) What do you think? -------------------------------------- Another one that was already discussed once is CppDB: http://cppcms.com/sql/cppdb/ It also needs C++11 updates in general and is already under dual Boost/MIT License. It was discussed before but nothing moved further. ---------------------------------- Some smart pointers I find very useful especially for Pimpl implementation: hold_ptr -> similar to scope ptr but object constness is same as the pointer copy_ptr-> copies underlying object upon copy (very useful for pimpl) clone_ptr->clones objects. Regards, Artyom Beilis

2 1

[serialization] uuid test_serialization ubsan error
by James E. King, III 02 Feb '18

02 Feb '18

I'm getting a ubsan test error in uuid/test/test_serialization - is the code in that test using archive the right way? testing.capture-output ../../../bin.v2/libs/uuid/test/test_serialization.test/gcc-7/debug/link-static/threadapi-pthread/test_serialization.run ====== BEGIN OUTPUT ====== ../../../boost/archive/detail/interface_oarchive.hpp:47:16: runtime error: downcast of address 0x7ffca0c6fe30 which does not point to an object of type 'text_oarchive' 0x7ffca0c6fe30: note: object is of type 'boost::archive::text_oarchive_impl<boost::archive::text_oarchive>' 00 00 00 00 e0 2f 78 8f 48 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^~~~~~~~~~~~~~~~~~~~~~~ vptr for 'boost::archive::text_oarchive_impl<boost::archive::text_oarchive>' EXIT STATUS: 1 ====== END OUTPUT ====== Thanks, Jim

3 3

Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
by Andrzej Krzemienski 01 Feb '18

01 Feb '18

2018-02-01 19:13 GMT+01:00 Emil Dotchevski <emildotchevski(a)gmail.com>: > On Thu, Feb 1, 2018 at 2:51 AM, Andrzej Krzemienski <akrzemi1(a)gmail.com> > wrote: > >> Boost.Outcome solves the problem decently: you get a compiler error or a >> compiler warning >> > > Do you? What if you have: > > result<void> foo(); > > void bar() > { > foo(); > } > > What compile error will that generate? > "ignoring returned value of type 'outcome_v2_f1696316::result<void>', declared with attribute nodiscard [-Werror=unused-result]" online example: https://wandbox.org/permlink/5vICxckvVG6QO0n1 > Now, in Boost.Noexcept, if the programmer forgets to test for the failure >> (with `try_`), the subsequent function is still executed with the default >> value of type `T` returned from the funciton that failed. Because in >> Boost.Noexcept when function fails it returns a default-constructed `T`. >> > > The idea in Noexcept is that since the function _must_ return something if > there is an error, it returns throw_return<T>() but that is not automatic; > the user still has to say e.g. return throw_(error()). > I understand the constraints you are under. I also acknowledge that this is the best one can do. Nonetheless, I still see the limitation of the solution. If a third party function is returning a type representing a resource, and this type does not provide a default constructor, there is no way to "throw_". You cannot even customize `throw_return<T>()` because what value would you return? You are reporting failure because you cannot acquire the resource. And because it is a third-party interface, you cannot adapt the type. So, in the end, there will be functions where you cannot apply Boost.Noexcept. > > >> And when you check it systematically it is all ok, but then you forget >> (and this is a tedious task), you violate the contracts. No compile-time >> check, no run-time check. >> > > In Noexcept there _is_ run-time check: if noexcept_::has_current_error() > is true at the time a thread terminates, it invokes std::terminate(). Not > ideal, and won't take action if the thread never terminates -- and it may > never terminate because, like in Outcome, if the caller doesn't check at > every function call, the program keeps going. > I was imprecise. you do have a run-time check, but it comes too late: it does not prevent functions to be called with failed preconditions. > > >> I consider this a serious issue. >> > > It is, programmers forget to check for errors all the time. > And Boost.Outcome helps detect these situations at compile-time (of course, at the expense of controlling the return type). > >> And taking into consideration the advantages of Boost.Noexcept you >> mention, I can only conclude that Boost.Noexcept is superior to >> Boost.Outcome in one aspect but inferior in another. >> > > The two libraries solve different problems. > Indeed. > Outcome helps you avoiding exception handling, so it assumes you can > freely use result<T,E> throughout your interfaces. > Well, it can help you avoid exceptions. But it also helps you deal with the lack of exception handling. As you say, the trade-off is that you use `result` in return type. > Noexcept helps you deal with a lack of exception handling, so it assumes > that at least some of the interfaces are beyond your control, and doesn't > impose a return type. > Yes, here the trade-off is, no altering of the return type, but unsafe consequences when you forget to check for "thrown" exceptions. And there must exist a "spare" value in the returned type. There are benefits to using a special return type (to protect against using > an invalid value), but Noexcept leaves that to the user because return > values don't transport errors, just the T; you could e.g. use > std::optional<T>. > And user may not be able to make this decision because he may not be in control of the return type. Regards, &rzej;

1 0