- Boost - lists.boost.org

Re: [boost] [review] Outcome: internal compiler error
by Vinnie Falco 27 Jan '18

27 Jan '18

On Thu, Jan 18, 2018 at 2:07 PM, charleyb123 . via Boost <boost(a)lists.boost.org> wrote: > GitHub: > *- https://github.com/ned14/boost-outcome > > Please post your comments and review to the boost mailing list > (preferably), or privately to the Review Manager (to me ;-). Here are some > questions you might want to answer in your review: I have put together the following sample program to test integration of Outcome into Boost.Beast: #include <boost/outcome.hpp> int main(int argc, char** argv) { } The result of compilation for this translation unit is shown here: 1>c:\users\vinnie\src\boost\boost\outcome\detail\value_storage.hpp(141): 1>fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1507) Compiler used: MSVC Part of: Microsoft Visual Studio Community 2017 Version 15.5.1 Upon investigation, I discovered a newer version of the compiler and IDE. Updating to "Version 15.5.5" produced the following results when compiling the same translation unit: 1>c:\users\vinnie\src\boost\boost\outcome\detail\value_storage.hpp(141): 1>fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1507) Is this a supported configuration? Thanks

3 4

[review] outcome
by Vinícius dos Santos Oliveira 27 Jan '18

27 Jan '18

That is my review of Boost.Outcome. What is your evaluation of the design? Niall did an excellent job weighting trade-offs and coming up with such an pleasant and convenient interface that not only is convenient, but it has customization points in the appropriate layers to fit not-close-to-trivial use cases. I've read the changes between v1 and v2 and I agree with the rejection reasons of previous version (the v1's null state specially made little sense at all). Version 2 is a very realistic and solid project. It might seem teasing to just port abstractions from functional languages to C++ (e.g. Expected), but C++ is its own beast and we cannot just ignore some features that we have been dragging all along like exceptions if we expect to have any realistic usage in the real world. Niall's intuition on how to weigh trade-offs was outstanding and just proves his C++ familiarity and expertise. In special, default actions/behaviours could only be defined by intuition of some experienced programmer and not "mathematically". What is your evaluation of the implementation? I did not check the implementation. What is your evaluation of the documentation? Very well written. The tutorials are excellent-quality. The use cases and examples were chosen in such a way that it was intuitive to understand why/when Boost.Outcome and not Expected. I noted a few small problems, but they were reported already. The comments on the example codes were seemingly foreseeing ahead enough about "pumping doubts" so that my mind would calm down and actually pay attention to the documentation instead doing mind exercises trying to guess the non-point of the example. I wish I had this skill. What is your evaluation of the potential usefulness of the library? Very useful. Error handling is a core constant in any programming activity. Introduction of Boost.Outcome could potentially remove duplication of throwing and non-throwing APIs. I personally prefer Expected with its monadic operations, but it is unrealistic to ignore exceptions in many code bases and I'd certainly go for Boost.Outcome in these cases. Did you try to use the library? With what compiler? Did you have any problems? Yes. The one-header version of the library made testing incredibly easy. No problems. Clang 5.0.1. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A few hours over a span of a few days. I've tried to examine documentation carefully and end up sending a pull request and a few comments to ask for further changes. I've read all threads that came up during review. I also tested the library when in doubt. Are you knowledgeable about the problem domain? I worked for more than one year under contract using the Rust programming language and Boost.Outcome is pretty much the error system we have in Rust (with some C++-ification and an experienced C++ unique programmer "intuition" to also cover exceptions... and w/o monad ops, of course). Do you think the library should be accepted as a Boost library? Yes. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

2 1

[config] Positive feature macros, r2
by Peter Dimov 26 Jan '18

26 Jan '18

I'd like to revisit the topic of Boost.Config feature macros, specifically that in my opinion, positive feature macros (BOOST_CXX17_FEATURE) make more sense than negative macros (BOOST_NO_CXX17_FEATURE) in the current environment. Negative macros made sense in the past when they signified bugs and deficiencies in the compiler as measured against a static standard. Nowadays, the standard, such as it is, is in constant motion and macros indicate merely a current state of development for both the compiler and the standard. The arguments for positive macros are the same as last time: - adding a new negative macro requires changes to all legacy compilers that do not and will never implement the feature; a positive macro only requires changes to active compilers. - positive macros are a better match for the standard feature macros, which are positive. When we see a standard feature macro being set, we typically would set ours as well. This means that the amount of changes required to add a new macro is further reduced; we only need to touch compiler-specific config files if the compiler either does not implement feature macros, or sets them incorrectly (in our considered opinion.) TL;DR we should switch to positive feature macros in Boost.Config, and delaying this switch just accumulates more unnecessary code in Boost.Config.

7 13

[gsoc18][ublas] Proposal to add advanced matrix operations
by SHIKHAR SRIVASTAVA 26 Jan '18

26 Jan '18

Hi everyone, I am a 4th year undergraduate student pursuing a degree in Computer Science and Engineering. I have strong programming experience in C++ through internships, self projects and programming events. I wish to be a part of gsoc18 under boost and am particularly interested in the linear algebra library Boost.ublas. The ublas library can be made more useful for Machine Learning applications like recommendation systems, clustering and classification, pattern recognition by adding some operations required in those. I propose to add advanced matrix operations to ublas including - 1. Triangular Factorisation (LU and Cholesky) 2. Orthogonal Factorisation (QR and QL) 3. Operations to find Singular Value lists 4. Eigenvalue algorithms 5. Singular Value Decomposition (SVD) 6. Jordan Decomposition 7. Schur Decomposition 8. Hessenberg Decomposition This is a very brief description of what I would like to propose. Any suggestions that help in refining the requirements before making a draft proposal would be great. Regards Shikhar Srivastava Github: https://github.com/shikharsrivastava

7 12

[outcome] success-or-failure objects
by Vinícius dos Santos Oliveira 26 Jan '18

26 Jan '18

I'm liking what I saw so far. Just a small comment on the documentation. I'm curious what the following sentence does even mean? Is it supposed to confuse the user or something? It's a sign of bad taste really. >Outcome’s default is to not provide value-or-error objects. It provides success-or-failure objects. What does that even mean? value-or-error... well, if it is non-error, I assume it is success. Both sentences mean just the same. As do their API (encapsulate either A or B). The rest of the paragraph is okay. If you just remove this comment, confusion will go away. No other changes need to be done in this paragraph. Just remove this misleading means-nothing comment. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

7 27

[Root Pointer] Deterministic C++ memory manager (update)
by Phil Bouchard 26 Jan '18

26 Jan '18

Greetings, I wanted to give an update to the community regarding the memory manager I wrote called: Root Pointer. I now have a working template to solve all memory leaks in C++ and C but both requires some meta data generator. The code can be found here; it is working but not polished: https://github.com/philippeb8/root_ptr In this code we can find: - node_ptr: main class of the smart pointer / memory manager. - root_ptr: generic derived class that includes an "iterator" and a pointer to the name of the instance (for debugging purposes). Also I commented some code that logs the exact location of the memory leak. Furthermore I would like to bring some observations that I found in the C and the C++ language: - Pointers and iterators are not the same; i.e. pointers should point to allocated blocks only and shouldn't have arithmetic operators while iterators shouldn't be used to deallocate anything. - C pointers can only point to dynamic arrays (size known at run-time). - C++ pointers can point to both inherited objects and static arrays (size known at compile-time). This creates a problem (see attached: array_inherited_pointer.cpp). - std::array<T> should have constructors with T objects that have no default constructor. Lastly, before I submit anything, I will have to propose a way to apply a template function to all non-static member variables of a class. This will require implicit meta data generation. This idea is not new as other libraries such as Qt is based on meta data and they certainly could make us of this. For the moment I have a parser that does the job correctly by specializing a boost::proxy() template function but eventually this will have to be integrated into the standards. Hopefully this is an important milestone! Regards, Phil Bouchard www.fornux.com

2 5

clang-format file
by Damian Vicino 25 Jan '18

25 Jan '18

Hi, I was wondering if someone has a .clang-format file that works fine to check boost code. I looked into the github repositories, but I couldn't find any. Best regards, Damian

9 11

[outcome] Some documentation suggestions
by Vinícius dos Santos Oliveira 24 Jan '18

24 Jan '18

Maybe I could send some PRs later (I've already sent one a few moments ago). But, for now, I'll have to postpone. Notes: - You put too much focus in "open (error) type hierarchies" (e.g. `error_code`). Not a problem. Also, do not change anything just because this comment. Really, it is not a problem. - The beginning of the documentation gave me the impression that I could only use EC types that were convertible to `std::error_code`[1], “it need in fact to merely satisfy trait::has_error_code_v<EC>”. Later pages corrected my understanding. - “only works when the EC type is the same in the try expression as the calling function”[2] is misleading. `OUTCOME_TRYV(outcome::result<int, err>{err::success})` works inside a function returning `outcome::result<void>` given `err` is convertible to `std::error_code`. [1] https://ned14.github.io/outcome/tutorial/payload/ [2] https://ned14.github.io/outcome/tutorial/default-actions/error-codes/ -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

2 3

[outcome] comments on Regular ops
by Andrzej Krzemienski 24 Jan '18

24 Jan '18

Hi Everyone, This is not my final review (yet), but I wanted to raise some issues with Regular ops: comparisons and swap. 1. Comparisons. Equality comparison for `result` makes a strange choice for `T`s without comparisons: two such `result<T>`s just compare unequal. This is somewhat contradictory to semantics of Regular types. For value-semantic types we expect that a copy of the original object `x` compares equal to `x`: ``` int i = 1; int j = i; assert (i == j); ``` For some types, copy-construction makes a copy with the same value, but there is no way to define operator==. In this case, in order not to confuse anyone operator== is simply not provided: ``` using transformation = std::function<int(int)>; transformation f = [](int i) { return i; }; transformation g = f; // assert (f == g); <-- does not compile ``` And now, when we wrap it into `result`, we get: ``` // continuing previous example: out::result<transformation> of = f, og = g; f == g; // <-- compiles fine, returns false. ``` Now you are just telling lies. Two objects have the same value, yet they compare unequal! Here is a live example: https://wandbox.org/permlink/I hqgXDfHW6WqAXHW My recommendation would be not to provide comparison operators if either `T` or `EC` does not provide them. 2. Swap For non-trivially-copyable types, it looks like (similarly to std::variant) `result` cannot provide the strong exception safety guarantee. You may need to both move-construct `T` and `EC` and both can fail. ``` void swap(result &o) noexcept(detail::is_nothrow_swappable<value_type>::value // &&detail::is_nothrow_ swappable<error_type>::value) { using std::swap; #ifndef BOOST_NO_EXCEPTIONS this->_state.swap(o._state); try { swap(this->_error, o._error); } catch(...) { swap(this->_state, o._state); throw; } #else swap(this->_state, o._state); swap(this->_error, o._error); #endif } ``` The trick with catch-reswap-rethrow assumes that `T` is more likely to throw while swapping/moving than `EC`, but it might be quite the opposite. Also, it is possible that while reswapping, another exception will be thrown. In general, you cannot guarantee the roll-back, so maybe it would be cleaner for everyone if you just declared that upon throw from swap, one cannot rely on the state of `result`: it should be reset or destroyed. Another problem is that in the noexcept() clause you are mentioning is_nothrow_swappable<value_type> and is_nothrow_swappable<error_type>, but in the implementation you might be using move constructors rather than swaps. This means that for types that do not throw in swap but throw in move constructor (like std::list), a throw from move constructor will cause a call to `std::terminate`. See live example here: https://wandbox.org/permlink/8jIyb0fx7U72cZSt The noexcept clause should be extended to include move-constructors. This is the case for `std::optional`. Regards, &rzej;

5 14

yomm2 - open methods
by Jean-Louis Leroy 24 Jan '18

24 Jan '18

Hi, in 2013 I posted a proposal for an "open multi-methods" library, see here: https://lists.boost.org/Archives/boost/2013/07/205383.php Due to insufficient interest, I did not go forward with a formal submission, and I published my work on github, under the name yomm11. I have now completely rewritten the library. The new version - yomm2 - is available here: https://github.com/jll63/yomm2 This iteration is much better because it does not require any modifications to classes involved in method dispatch, yet the speed of a method call with one virtual argument is within 15% of the equivalent virtual function call. Over the years I realized that the value of such a library resides more in the 'open' than in the 'multi' aspect. Open methods are virtual functions that live outside classes, like free functions. They solve several problems, notably the Expression Problem (http://wiki.c2.com/?ExpressionProblem) and Cross-Cutting Concerns (http://wiki.c2.com/?CrossCuttingConcern) They provide an elegant replacement for the Visitor pattern. yomm2 also implement multiple dispatch, which can come (occasionally) handy. Well I am just touching base to see if things have evolved and if there might now be an interest in seeing this in Boost. Jean-Louis Leroy

3 12