Home » Blog » Tags » experimental

experimental

Trip Report: C++ Standards Meeting in Issaquah, November 2016--Botond Ballo

By Adrien Hamelin | Nov 29, 2016 02:14 PM | Tags: experimental community

C++17 makes a new step.

Trip Report: C++ Standards Meeting in Issaquah, November 2016

by Botond Ballo

From the article:

Last week I attended a meeting of the ISO C++ Standards Committee (also known as WG21) in Issaquah, Washington (near Seattle). This was the third and final committee meeting in 2016; you can find my reports on previous meetings here (February 2016, Jacksonville) and here (June 2016, Oulu), and earlier ones linked from those. These reports, particularly the Oulu one, provide useful context for this post...

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...