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

[err] RFC
by Domagoj Saric 11 Jan '16

11 Jan '16

https://github.com/psiha/err README.md copy-paste: --------------------------------------------- err - yet another take on C++ error handling. We have throw and std::error_code, what more could one possibly want? --------------------------------------------- std::error_code&co tried to solve or at least alleviate the problem of overhead of using exceptions (in terms of both source code verbosity and binary code size&speed) with functions which need to report failures that need not be 'exceptional' depending on the context of the call (thereby requiring try-catch blocks that convert exceptions to 'result codes'). Unfortunately, the way it was finally implemented, std::error_code did not quite accomplish what it set out to do: • in terms of runtime efficiency: 'manual'/explicit EH (try-catch blocks) is no longer needed but the compiler still has to insert hidden EH as it has to treat the functions in question as still possibly throwing (in fact the implementation/codegen of functions which use std::error_code for error reporting becomes even fatter because it has to contain both return-on-error paths and handle exceptions) • in terms of source code verbosity: again, try-catch blocks are gone but separate error_code objects have to be declared and passed to the desired function. Enter boost::err: 'result objects' (as opposed to just result or error codes) which can be examined and branched upon (like with traditional result codes) or left unexamined to self-throw if they contain a failure result (i.e. unlike traditional result codes, they cannot be accidentally ignored). Thanks to latest C++ language features (such as r-value member function overloads) incorrect usage (that could otherwise for example lead to a result object destructor throwing during a stack-unwind) can be disallowed/detected at compile time. Discussions where the concept (or a similar one) was first concieved of and/or so far discussed: • http://boost.2283326.n4.nabble.com/system-filesystem-v3-Question-about-erro… • http://cpptips.com/fallible • https://github.com/ptal/std-expected-proposal • https://github.com/ptal/expected • https://github.com/adityaramesh/ccbase/blob/master/include/ccbase/error/exp… • http://stackoverflow.com/questions/14923346/how-would-you-use-alexandrescus… • https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a8.DESIGN:Strong… • http://2013.cppnow.org/session/non-allocating-stdfuturepromise **************************************************************** For starter's, to reduce the length of the first post, I'll assume that everyone as at least somewhat familiar with similar/related proposals from Andrei Alexandrescu (std::expected) and Niall Douglas (std::monad) to which I gave links above. What, primarily, makes (Boost.)Err different from other proposals is the ability to (using latest C++ features) detect/distinguish between temporaries and 'saved' return values by using two different class templates (result wrappers), fallible_result (for rvalues) and result_or_error (for lvalues) and thus minimise or often completely eliminate any extra verbosity: If we had a function foo() that produces bar_t objects but can fail with an err_t, up till now we had two options: * bar_t foo() throw( err_t ); * optional<bar_t> foo( err_t & ); Err enables the library writer to write a single API and a single implementation: err::fallible_result<bar_t, err_t> foo(); where fallible_result is the class template that wraps temporaries/rvalues returned from functions and its member functions are all declared with && (i.e. callable only on rvalues) so you get a compiler error if you save it to an auto value and try to do anything with it. The two exceptions are the implicit conversion operators to: - bar_t, which will either return bar_t or throw err_t and which is used for the 'EH code path' bar_t my_bar( foo() ); - err::result_or_error<bar_t, err_t> which is used for the 'oldsk00l nothrow error code path' err::result_or_error<bar_t, err_t> maybe_bar( foo ); if ( maybe_bar ) { print( *maybe_bar ); } else { log( maybe_bar.error() ); } Also, if the fallible_result rvalue is left uninspected and contains an error its destructor will throw (which AFAICT should be safe considering it is an rvalue and no other exception can possibly be active at the same time) - this makes code that uses Err enabled libraries/APIs but relies on EH almost indistinguishable from 'classic EH' APIs (almost because the one difference that remains is with the immediate use of the return value: because of the wrapper class one can no longer write foo().do_something() but has to implicitly use the -> operator and write foo()->do_something() where the -> operator will check-and-throw if foo() did not succeed). To wrap up, this approach gives the user the immediate and fine grained control over which error handling mechanism he/she wants to use while allowing the developer to write a single API and implementation - AFAICT it is a no brainer replacement for <system_error>, it is less verbose and much more efficient ;-) ps. the small library @ https://github.com/psiha/err is by no means a finished product, it contains no tests or documentation but 'it works' (i.e. it is used in the, also upcoming, https://github.com/psiha/mmap)...I'm bringing it to public view for scrutiny, discussion and guidance lest I steer in the wrong direction ;) -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

4 20

[regression] Summary for develop is unavailable
by Antony Polukhin 08 Jan '16

08 Jan '16

Hi, At http://www.boost.org/development/tests/develop/developer/summary.html you'll find "Error extracting file: Error code 3 - A severe error in the zipfile format was detected." Please, could someone fix that? -- Best regards, Antony Polukhin

1 1

[Locale] MSVC 2015 facets issue
by Artyom Beilis 04 Jan '16

04 Jan '16

Hello, Today I had a discussion on this ticket https://svn.boost.org/trac/boost/ticket/11878 There was a basic issue with Boost.Locale that couldn't format numbers at all properly, after back and forth it was discovered an issue with MSVC library. https://svn.boost.org/trac/boost/ticket/11878#comment:10 What is the best way to address this issue (open a bug there is no github issue tracker on this :-) ... Thank You, Artyom Beilis

3 3

Problems building Boost libraries for Windows Store when C++/CX is involved
by Mikael Olenfalk 04 Jan '16

04 Jan '16

Hi, I am working on porting the boost libraries we depend on to winrt, most porting is rather straightforward (basically switch from win32 apis which are 20 years old to apis which are 15 years old :D ). However I have hit a bit of a problem when compiling Boost.Log. Boost.Log depends on Boost.Asio which uses C++/CX to call some of the newer Store APIs (Windows::Networking and friends). When I build I get these errors: compile-c-c++ ..\..\..\bin.v2\libs\log\build\msvc-14.0\debug\log-api-winnt\threading-multi\windows-api-store\dump_ssse3.obj dump_ssse3.cpp ..\..\..\libs\log\src\dump_ssse3.cpp: fatal error C1107: could not find assembly 'platform.winmd': please specify the assembly search path using /AI or by setting the LIBPATH environment variable call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86 store >nul cl /Zm800 /ZW /EHsc -nologo @"..\..\..\bin.v2\libs\log\build\msvc-14.0\debug\log-api-winnt\threading-multi\windows-api-store\dump_ssse3.obj.rsp" (As you can see I have monkey-patched msvc.jam to append the "store" argument to vcvarsall.bat - to no avail :( -- the monkey-patch is here if you want to look at it: https://github.com/mauve/build/commits/universal-windows-boost-1.59.0 ) The @response file looks like this: "..\..\..\libs\log\src\dump_ssse3.cpp" -Fo"..\..\..\bin.v2\libs\log\build\msvc-14.0\debug\log-api-winnt\threading-multi\windows-api-store\dump_ssse3.obj" -TP /Z7 /Od /Ob0 /W3 /GR /MDd /Zc:forScope /Zc:wchar_t /wd4675 /EHs /arch:SSE2 /bigobj /wd4003 /wd4456 /wd4459 /wd4503 -c -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_DATE_TIME_DYN_LINK=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LOG_BUILDING_THE_LIB=1 -DBOOST_LOG_DLL -DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_DONT_USE_CHRONO=1 -DBOOST_THREAD_USE_DLL=1 -DDATE_TIME_INLINE -DWINAPI_FAMILY=WINAPI_FAMILY_APP -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_WIN32_WINNT=0x0603 "-I..\..\.." Regards, Mikael

4 10

Generic type inferencer function?
by Nat Goodspeed 04 Jan '16

04 Jan '16

Our code has any number of instances of this pattern: template <typename T, typename U> class SomeTemplate { SomeTemplate(const T& t, const U& u); ... }; template <typename T, typename U> SomeTemplate<T, U> make_SomeTemplate(const T& t, const U& u) { return SomeTemplate<T, U>(t, u); } Am I overlooking a generic boost::make<something>() of this general form? template <template<typename...> class CLASS_TEMPLATE, typename... ARGS> CLASS_TEMPLATE<ARGS...> make(ARGS && ... args) { return CLASS_TEMPLATE<ARGS...>(std::forward<ARGS>(args)...); } If that doesn't already exist... would it be useful to add (a less naive version) somewhere?

10 18

[multiprecision] uses boost::math::gcd without including the header
by Peter Dimov 04 Jan '16

04 Jan '16

include/boost/multiprecision/cpp_int/misc.hpp uses boost::math::gcd (and lcm), but does not include common_factor_rt.hpp.

2 2

Status of the CMake-ification
by Louis Dionne 02 Jan '16

02 Jan '16

Dear Boost, I'd like to inquire about the status of the CMake-ification of Boost that had been started a while ago. AFAICT, the effort is completely stopped now; is this correct? Also, I'd like to poll the community to gauge interest in the rebirth of such an effort. __I'm not proposing myself to work on such a rebirth__, but I'm just curious to know what the community thinks about it. I, for one, would love to see it happen. Regards, Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Status-of-the-CMake-ification-tp4681599.… Sent from the Boost - Dev mailing list archive at Nabble.com.

14 25

[winapi] [thread] Conflicting declarations on MinGW
by Antony Polukhin 01 Jan '16

01 Jan '16

Hi, Some of the Boost.DLL tests produce following warnings: ../boost/thread/win32/thread_primitives.hpp:175:83: warning: declaration of 'void* boost::detail::win32::GetModuleHandleA(const char*)' with C language linkage ../boost/detail/winapi/dll.hpp:47:1: warning: conflicts with previous declaration 'HINSTANCE__* GetModuleHandleA(boost::detail::winapi::LPCSTR_)' ../boost/thread/win32/thread_primitives.hpp:195:94: warning: declaration of 'int (__attribute__((__stdcall__)) * boost::detail::win32::GetProcAddress(void*, const char*))()' with C language linkage ../boost/detail/winapi/dll.hpp:82:1: warning: conflicts with previous declaration 'int (__attribute__((__stdcall__)) * GetProcAddress(boost::detail::winapi::HMODULE_, boost::detail::winapi::LPCSTR_))()' Andrey, Vicente what's the best way to resolve such issues? -- Best regards, Antony Polukhin

5 12

[qvm] deduce_xx traits wouldn't introduce ODR issues.
by Vicente J. Botet Escriba 31 Dec '15

31 Dec '15

Hi, I wonder if the deduce_xx traits wouldn't introduce ODR issues. Remember the TBoost.Conversion library where conversion between two types was customizable. The fact that deduce_xx traits have two types would promote ODR as there is no one type that is expected to do the customization. I believe that changing the default to something depending on the first argument will be better than using the specific qvm type as result. If this is not enough, you could add symbolic operations taken the result type as parameter, e.g. if a+b is not something specified by A, the user could use sum<C>(a,b) Forget my comment if there is no ODR issue. Best, Vicente

7 33

[dll] ready for master branch. Please merge
by Antony Polukhin 29 Dec '15

29 Dec '15

Hi, Boost.DLL is ready to appear in next release of Boost. Please, merge the DLL related changes into the master branch of boostorg/boost (changes for the develop branch were merged here: https://github.com/boostorg/boost/pull/94) Thanks! -- Best regards, Antony Polukhin

2 2