Home » Blog » Tags » experimental

experimental

Compose and curry as folds--Nick Athanasiou

By Adrien Hamelin | Nov 28, 2016 12:33 PM | Tags: experimental advanced

With the next version of C++.

Compose and curry as folds

by Nick Athanasiou

From the article:

In a previous post we introduced C++17 fold expressions and described a way to extend them for arbitrary callables. Implementation details don’t matter for what we’re elaborating on here but it should be clear that (given the tools we developed) the following is possible:

(Op<F>(args) + ...)
(... + Op<F>(args))

Collaborative Online Compilers

By Meeting C++ | Nov 7, 2016 03:44 AM | Tags: experimental basics

I was doing some research on possible live formats...

Collaborative Online Compilers

by Jens Weller

From the article:

While doing some brainstorming for possible (youtube) live formats with C++ content, the thought of having a shared online IDE/Compiler came into my mind. Think of Google Docs but for C++...

checking expression validity in-place with C++17--Vittorio Romeo

By Adrien Hamelin | Nov 4, 2016 01:09 PM | Tags: experimental advanced

An introduction to the world of C++17.

checking expression validity in-place with C++17

by Vittorio Romeo

From the article:

When writing generic code, it is sometimes useful to check whether or not a particular SFINAE-friendly expression is valid (e.g. to branch at compile-time). Let's assume that we have the following class declarations...

struct Cat
{
    void meow() const { cout << "meow\n"; }
};

struct Dog
{
    void bark() const { cout << "bark\n"; }
};

...and that we would like to write a template function make_noise(x) that calls x.meow() and/or  x.bark() if they are well-formed expressions:

template <typename T>
void make_noise(const T& x)
{
    // Pseudocode:
    /*
        if(`x.meow()` is well-formed)
        {
            execute `x.meow();`
        }
        else if(`x.bark()` is well-formed)
        {
            execute `x.bark();`
        }
        else
        {
            compile-time error
        }
    */
}

In this article I'll show how to implement the pseudocode in:

C++11: using std::void_t and std::enable_if.

C++14: using boost::hana::is_valid and vrm::core::static_if.

C++17: using if constexpr(...), constexpr lambdas, and std::is_callable. This version will allow expression validity to be checked in-place (i.e. directly in the if constexpr predicate). Variadic preprocessor macros will also be used to make the user code easier to read and maintain...

Getting your head around auto’s type-deduction rules--Glennan Carnie

By Adrien Hamelin | Nov 4, 2016 12:53 PM | Tags: intermediate experimental

Are the rules clear to you?

Getting your head around auto’s type-deduction rules

by Glennan Carnie

From the article:

Automatic type-deduction is perhaps one of the more divisive features of Modern C++.  At its core it’s a straightforward concept:  let the compiler deduce the type of an object from its initialiser.   Used in the right way this can improve the readability and maintainability of your code.

However, because auto is based on template type-deduction rules there are some subtleties that can catch the unwary programmer.

In this article we’ll have a look at auto in the context of the template type-deduction rules to see where all these subtleties come from...

The Case for Optional References--Tristan Brindle

By Adrien Hamelin | Sep 30, 2016 08:59 AM | Tags: intermediate experimental boost

And why not simply use a pointer?

The Case for Optional References

by Tristan Brindle

From the article:

I have a confession to make. Whenever I’ve come across code that looks like this:

struct example {
    example() = default;

    example(std::string& s) : str_{s} {}

private:
    boost::optional<std::string&> str_{};
};

there is a little voice inside my head that whispers “why didn’t you just use a pointer?”. Like so, for instance:

struct example {
    example() = default;

    example(std::string& s) : str_{&s} {}

private:
    std::string* str_ = nullptr;
};

This is equivalent to the first example, except that it’s slightly less typing, it doesn’t have any dependencies, and feels in some sense “cleaner”. I personally have always preferred it.

Except, I was wrong. After attending Bjarne Stroustrup’s keynote and this excellent talk at Cppcon this morning, I’m persuaded that optional references are a good thing. In this post I hope to be able to convince you of the same...

Concepts Lite vs enable_if--Andrzej Krzemieński

By Adrien Hamelin | Sep 22, 2016 01:12 PM | Tags: experimental community

Why having concepts?

Concepts Lite vs enable_if

by Andrzej Krzemieński

From the article:

This post contains quite advanced material. I assume you are already familiar with Concepts Lite. For an overview of what Concepts Lite is, I recommend this proposal. Also, I have found this blog very useful regarding the details of and issues with concepts’ mechanics. One could look at Concepts Lite as three features:

  1. A superior alternative to enable_if (or overload hiding).
  2. The subsumption relation that enables the additional control of partial ordering in the overload resolution process.
  3. A convenient tool for building compile-time predicates that check for valid types and expressions.

In this post I will only focus on the first feature, and try to answer the question, “what do we need Concepts Lite for, given that we already have std::enable_if (and SFINAE)?”