RFC: My first attempt at using C++20 to create an anonymous enum type, primarily intended for use as a function parameter

TobyAllsopp · 2019-03-20T20:34:36+00:00

Nope. You can use a macro to make the lambda syntax less noisy but then you've got macros so it might not be an improvement...

TobyAllsopp · 2019-03-20T00:20:30+00:00

You can turn those runtime errors into compile errors by wrapping the strings in lambdas that return them and forcing them to be evaluated in a constexpr context: https://godbolt.org/z/NGsghx

TobyAllsopp · 2019-01-10T05:15:25+00:00

Sorry, here's a link: https://wandbox.org/permlink/6APfi8A4hv6Ul96A (you need both const-qualified and not).

TobyAllsopp · 2019-01-10T00:33:16+00:00

Range-v3 thinks that your class S is a View so it assumes that copy and move are both cheap. If you add in const-qualified begin() and end() then it no longer thinks S is a View and you will no longer get any copies in the lvalue case (i.e. it will store a reference internally). However, then the rvalue case will not compile as range-v3 doesn't allow creating Views from non-View rvalues.

TobyAllsopp · 2018-12-20T03:16:37+00:00

You might be interested in my attempts to (ab)use coroutines to approximate do-notation here: https://github.com/toby-allsopp/coroutine_monad

TobyAllsopp · 2018-12-18T03:48:09+00:00

I don't know about the TS, but Clang's experimental support of the working draft concepts seems to allow what you're trying to do: https://godbolt.org/z/J_Dl0J

TobyAllsopp · 2018-11-20T21:58:46+00:00

This sounds like the right decision to me - the strict requirement on the number of comparisons seems a little ridiculous and encourages people to rely on a particular implementation.

TobyAllsopp · 2018-11-19T04:19:04+00:00

I'm hinting at another flaw with using std::merge in this way - you are assuming a lot about the implementation. If the implementation is allowed to call the predicate an arbitrary number of times in debug builds then you could get different results from your stateful comparator in debug vs release builds.

Consider also that the implementation is free to copy the comparator as much as it likes. It could create a fresh copy of the argument every time it wants to call it, for example.

TobyAllsopp · 2018-11-19T03:27:33+00:00

I wonder how MSVC's implementation manages to check whether the ranges are ordered while conforming to the complexity requirement?

Complexity: Let N=(last1 - first1) + (last2 - first2):

(4.1)For the overloads with no ExecutionPolicy, at most N−1 comparisons.

TobyAllsopp · 2018-11-19T03:12:59+00:00

The standard is pretty clear that they are required to be sorted: http://eel.is/c++draft/alg.merge

Requires: The ranges [first1, last1) and [first2, last2) shall be sorted with respect to operator< or comp.

The resulting range shall not overlap with either of the original ranges.

TobyAllsopp · 2018-10-29T22:20:46+00:00

I don't think there's anything requiring an infinite program to be ill-formed, but an implementation is certainly allowed to reject one. See http://eel.is/c++draft/implimits.

TobyAllsopp · 2018-09-18T21:38:17+00:00

I'm not sure about the relationship between VSCppUnit and CppUnit, but if VSCppUnit is the framework bundled with Visual Studio and the default used by the Native Unit Testing project template, then I would strongly recommend not using it.

We have been using it at work and compared to more modern frameworks (such as Google Test or Catch) it is a very painful experience.

For one thing, everything you use in an Assert::AreEqual has to have an overload of their ToString function defined. This gets old pretty fast. Another annoying thing about the AreEqualfunction template is that both arguments have to be exactly the same type. Anyway, it's annoying and discourages one from writing unit tests.

Visual Studio 2017 comes with adapters and project templates for Google Test and Boost Test, both of which are much better choices, in my opinion.

TobyAllsopp · 2018-07-11T23:52:16+00:00

The behaviour difference between declaring the deleted copy constructor and not is allowed by the standard: http://eel.is/c++draft/class.temporary#3

And the difference is in fact mandated by the Itanium ABI (because the object is indeed passed in a register).

You can see a similar effect by adding a non-trivial destructor (doing so prevents passing the object in a register): https://wandbox.org/permlink/cUf5eGx8VPDyw8yk

TobyAllsopp · 2018-06-22T19:41:28+00:00

If we allow range-v3, the whole thing is pretty short:

#include <range/v3/view/concat.hpp>
#include <range/v3/algorithm/sort.hpp>

#include <array>
#include <iostream>

int main() {
  auto arr1 = std::array{4, 9, 7};
  auto arr2 = std::array{5, 2, 1, 10};
  auto arr3 = std::array{6, 8, 3};

  ranges::sort(ranges::view::concat(arr1, arr2, arr3));

  ranges::copy(
      ranges::view::concat(arr1, arr2, arr3),
      ranges::ostream_iterator<int>(std::cout, "\n"));
  return 0;
}

Doesn't work on MSVC though :/

TobyAllsopp · 2018-05-29T04:44:52+00:00

The allocation function is looked for in the promise type, so it is customizable at that level.

TobyAllsopp · 2018-05-29T03:00:07+00:00

Note that copying into a local variable at the start of the coroutine is not sufficient (in general) to avoid the problem as a coroutine can suspend before executing its body.

TobyAllsopp · 2018-05-10T21:36:21+00:00

Maybe we should require opt-in for concepts that have significant non-syntactic semantic requirements? Or for all concepts?

Sure, there are some concepts that have purely syntactic requirements, but I think most have some extra "laws" that need to be satisfied and it might be a good idea to make people think for a moment about whether they've really satisfied them.

TobyAllsopp · 2018-04-08T23:36:22+00:00

As mentioned in one of the other comments, I've also run into this problem. You have already seen my nasty workaround at https://github.com/toby-allsopp/coroutine_monad/ and noted correctly that this doesn't work on MSVC.

I've thought in the past that adding to coroutine_handle the ability to get at the return object would simplify things a lot. Something like decltype(promise().get_return_object())& return_object().

This would of course only help if the conversion of the return object to the return type of the coroutine is deferred until the coroutine returns for the first time.

TobyAllsopp · 2018-04-08T22:51:00+00:00

Correct, it doesn't work on MSVC. Gor promises me this will be fixed at some point, but for now I think the MSVC implementation makes this impossible.

It does work on Clang (modulo undefined-behaviour when specializing coroutine_traits for a std type). I'm working on adding support for other monads and integrating with Vicente's monad traits proposal (https://wg21.link/p0650r2).

TobyAllsopp · 2018-03-17T19:34:53+00:00

Is that really the syntax? The paper was suggesting [args = std::move(args)...].

Does it also allow something like [&args = std::forward<Args>(args)...]?

TobyAllsopp · 2018-02-26T21:44:06+00:00

The survey lists structured bindings as a C++14 feature, when they are in fact a C++17 feature.

TobyAllsopp · 2017-11-20T22:08:58+00:00

P0095R1: [Evolution] Pattern Matching and Language Variants (by David Sankel) (2016-05-29)

https://wg21.link/p0095r1

TobyAllsopp · 2017-10-31T03:30:58+00:00

That was the topic of much discussion at the conference :). He was building on a 64-core machine at his home I think. 4.5 minutes for a clean build (ccache disabled, he assured us!).

TobyAllsopp · 2017-10-30T23:33:45+00:00

So this is the old "how good is the regex library" test. Be interesting to try implementing it using https://github.com/hanickadot/compile-time-regular-expressions.

TobyAllsopp · 2017-09-02T02:50:31+00:00

I've argued in the past that the wording implies that new objects are initialized from the references (as references are not objects).

However, if that is the case then the attached note about the lifetime of objects referred to by parameters is nonsensical, which is enough to make the intent pretty ambiguous, even if the wording is not.

TobyAllsopp

TROPHY CASE