Home » Blog » Tags » advanced

advanced

Should Span Be Regular?--Barry Revzin

By Adrien Hamelin | May 23, 2018 12:54 PM | Tags: advanced

Do you have an opinion?

Should Span Be Regular?

by Barry Revzin

From the article:

In my last post, I talked about the concept of Westie types (yes, I am trying to make this happen), what Regular means, and which of them are Regular. I went through an explanation for why means for span is not Regular and potentially why it should be. After lots of resulting conversations with several people (thanks Zach Laine, Nicole Mazzuca, Eric Niebler, John Shaw, Tim Song), I thought it was necessary to write a follow up with more details and more argument...

Rvalues redefined--Andrzej Krzemieński

By Adrien Hamelin | May 22, 2018 01:10 PM | Tags: c++17 advanced

Evolution of semantics.

Rvalues redefined

by Andrzej Krzemieński

From the article:

In this post we will explore what I consider the most significant language change in C++17. I call it the most significant because it changes the way you design your resource-managing types and how you think about initialization. It is often called “guaranteed copy elision”, but I will not use that name (except for this single time) because it does not reflect what this feature is. C++ has completely changed the meaning of rvalue (actually, prvalue)...

How to Make SFINAE Pretty – Part 2: the Hidden Beauty of SFINAE--Jonathan Boccara

By Adrien Hamelin | May 21, 2018 12:17 PM | Tags: advanced

The next part.

How to Make SFINAE Pretty – Part 2: the Hidden Beauty of SFINAE

by Jonathan Boccara

From the article:

As we’ve seen in How to Make SFINAE Pretty – Part 1: What SFINAE Brings to Code, SFINAE in code is as pretty as a windmill in a field. That is, not very pretty.

But like a windmill, it’s useful. SFINAE helps deactivate a piece of template code depending on a condition, and that can be very convenient...

How to Make SFINAE Pretty – Part 1: What SFINAE Brings to Code

By Adrien Hamelin | May 21, 2018 12:16 PM | Tags: advanced

New series!

How to Make SFINAE Pretty – Part 1: What SFINAE Brings to Code

by Jonathan Boccara

From the article:

SFINAE is a bit like a windmill. It sits as a wart in the middle of an interface, BUT it’s useful to create elaborate static polymorphism, in particular before C++17 and if constexpr, and even in some use cases in C++17.

I thought we had to live with this tradeoff, until I watched a talk from Stephen Dewhurst at CppCon. In this inspring talk, Stephen shows how to turn SFINAE around to make it very expressive in an interface. Watching this talk changed my way of coding template interfaces...

Default-constructibility is overrated--Arthur O’Dwyer

By Adrien Hamelin | May 18, 2018 11:19 AM | Tags: community advanced

What do you think?

Default-constructibility is overrated

by Arthur O’Dwyer

From the article:

The Ranges Technical Specification includes very many concept definitions (based on the Concepts TS), including for example Integral and Predicate. It also provides a concept named Regular which implements a variation on the “Regular” concept described by Alexander Stepanov in his paper '’Fundamentals of Generic Programming’’ (1998)...

Quick Q: Undefined behavior and sequence points

By Adrien Hamelin | May 10, 2018 11:48 AM | Tags: advanced

Quick A: No quick A.

Recently on SO:

Undefined behavior and sequence points

What are "sequence points"?

What is the relation between undefined behaviour and sequence points?

I often use funny and convoluted expressions like a[++i] = i;, to make myself feel better. Why should I stop using them?

If you've read this, be sure to visit the follow-up question Undefined behavior and sequence points reloaded.

(Note: This is meant to be an entry to Stack Overflow's C++ FAQ. If you want to critique the idea of providing an FAQ in this form, then the posting on meta that started all this would be the place to do that. Answers to that question are monitored in the C++ chatroom, where the FAQ idea started out in the first place, so your answer is very likely to get read by those who came up with the idea.)

‘Speedy Gonzales’ Serializing (Re)Actors via Allocators--"No Bugs" Hare

By Adrien Hamelin | May 8, 2018 12:33 PM | Tags: advanced

Actors.

‘Speedy Gonzales’ Serializing (Re)Actors via Allocators

by "No Bugs" Hare

From the article:

As we briefly discussed in Part I of this mini-series [NoBugs17a], message-passing technologies such as (Re)Actors (a.k.a. Actors, Reactors, ad hoc FSMs, and event-driven programs) have numerous advantages – ranging from being debuggable (including post-factum production debugging), to providing better overall performance.

In [NoBugs17a] and [NoBugs17b], we discussed an approach to handling allocations for (Re)Actors, and then were able to achieve a safe dialect of C++ (that is, as long as we’re following a set of well-defined local rules). Now, let’s take a look at another task which can be facilitated by per-(Re)Actor allocators – specifically, at the task of serializing (Re)Actors that are later going to be de-serialized by the same executable. While one solution for this task was provided in [Ignatchenko-Ivanchykhin16], the proposed ‘ultra-fast’ serialization is rather cumbersome to maintain, and in most cases it can be beaten performance-wise by serializing at the allocator level...

Without form and void--Barry Revzin

By Adrien Hamelin | May 7, 2018 12:53 PM | Tags: advanced

Did you encounter the problem?

Without form and void

by Barry Revzin

From the article:

In C++, void is a pretty strange thing. We can cast expressions to void, throw-expressions have void type, void* can point to anything, and void functions can actually return back to the caller. But we can’t have objects of type void or even write a type like void&. A function declaration like void f(void) is actually a nullary function. It’s a bit weird — but it’s not something a lot of people lose sleep over.

Until it starts wreaking havoc on your generic code — because it’s like the vector<bool> of the type system...

[[trivial_abi]] 101--Arthur O’Dwyer

By Adrien Hamelin | May 7, 2018 12:41 PM | Tags: community advanced

Interesting!

[[trivial_abi]] 101

by Arthur O’Dwyer

From the article:

Finally, a blog post on [[trivial_abi]]!

This is a brand-new feature in Clang trunk, new as of about February 2018. It is a vendor extension to the C++ language — it is not standard C++, it isn’t supported by GCC trunk, and there is no active WG21 proposal to add it to the standard C++ language, as far as I know...