Strong types Archives - Fluent C++

Strong Types for Safe Indexing in Collections – Part 2

Jonathan Boccara — Thu, 04 Nov 2021 01:00:24 +0000

In the previous article on strong types, we set out to find how to use strong types for safe indexing in collections.

More precisely, if we have two vectors with two indices to access them, how can we use strong types to make sure we use the right index for the right vector, and that we don’t swap them by mistake?

In other terms, if we have two collections:

std::vector foos = {1, 2, 3};
std::vector bars = {10, 20};

And we create two separate indices by using strong types:

using FooIndex = NamedType;
using BarIndex = NamedType;

Those are two different types wrapping a size_t and that can be incremented and compared.

How can we make this first piece of code compile:

for (FooIndex fooIndex = FooIndex{0}; fooIndex < FooIndex{foos.size()}; ++fooIndex)
{
    for (BarIndex barIndex = BarIndex{0}; barIndex < BarIndex{bars.size()}; ++barIndex)
    {
        std::cout << foos[fooIndex] << '-' << bars[barIndex] << '\n'; // ok, correct indices
    }
}

And how to make this one trigger a compilation error?

for (FooIndex fooIndex = FooIndex{0}; fooIndex < FooIndex{foos.size()}; ++fooIndex)
{
    for (BarIndex barIndex = BarIndex{0}; barIndex < BarIndex{bars.size()}; ++barIndex)
    {
        std::cout << foos[barIndex] << '-' << bars[fooIndex] << '\n'; // oops, wrong indices!
    }
}

In the previous article we saw how to reuse the code of std::vector to implement a new data structure with a custom operator[]. We’ll see now another approach: how to use a proxy of a standard std::vector with a custom operator[].

Using a proxy: the simple case

Using a proxy consists in storing a reference to the vector, and providing an operator[] with a custom interface that calls the normal operator[] of std::vector:

template
class StrongIndexAccess
{
public:
    explicit StrongIndexAccess(std::vector const& vector) : vector_(vector){}

    typename std::vector::const_reference operator[](Index pos) const
    {
        return vector_[pos.get()];
    }

private:
    std::vector vector_;
};

We can then create two different StrongIndexAccess by using the two strongly typed indices:

auto indexedFoos = StrongIndexAccess(foos);
auto indexedBars = StrongIndexAccess(bars);

Then the following piece of code compiles:

for (FooIndex fooIndex = FooIndex{0}; fooIndex < FooIndex{foos.size()}; ++fooIndex)
{
    for (BarIndex barIndex = BarIndex{0}; barIndex < BarIndex{bars.size()}; ++barIndex)
    {
        std::cout << indexedFoos[fooIndex] << '-' << indexedBars[barIndex] << '\n';
    }
}

And this one doesn’t:

for (FooIndex fooIndex = FooIndex{0}; fooIndex < FooIndex{foos.size()}; ++fooIndex)
{
    for (BarIndex barIndex = BarIndex{0}; barIndex < BarIndex{bars.size()}; ++barIndex)
    {
        std::cout << indexedFoos[barIndex] << '-' << indexedBars[fooIndex] << '\n';
    }
}

This is exactly what we wanted. Are we done then?

The above code works well for const references, which don’t allow modifying the values inside of the vector. To allow it we need to support non const references.

Also, our above code doesn’t support taking a reference on an incoming temporary vector:

auto indexedFoos = StrongIndexAccess(std::vector{1, 2, 3});
auto indexedBars = StrongIndexAccess(std::vector{10, 20});

The code as we wrote it will compile, but as soon as we try to access the values through StrongIndexAccess, we get to undefined behaviour, typically with the application crashing, because we’re accessing a destroyed object.

We need to make our StrongIndexAccess support those two additional cases, and this is where the fun begins.

Handling non const, lvalue and rvalue references

Before writing code, let’s decide on how to handle the tree cases of incoming values:

const lvalue reference: std::vector const& vector
non const lvalue reference: std::vector& vector
non const rvalue reference: std::vector&& vector

We don’t include const rvalue references because they are virtually never used.

In the first two cases, with a lvalue reference, we can use the same idea as in the initial code. The source value being an lvalue, we know it’s going to stick around for some time before being destroyed, so we can just keep a reference to it. The reference has to be const or non const depending on the incoming value.

In the case of the rvalue though, we can’t just keep a reference: the incoming value is about to be destroyed, or is being moved from, which means in either case that we don’t want to access afterwards.

Another way then is to keep the whole value inside of our StrongIndexAccess, only for rvalues. Indeed an rvalue, especially of type std::vector, is made to be moved inside of our class.

In summary, here is what we want to do based on the type of the incoming value:

const lvalue reference: keep a const lvalue reference
non const lvalue reference: keep a non const lvalue reference
non const rvalue reference: keep the whole value

The implementation

This implies that the type of our data member depends on the incoming type to the constructor of StrongIndexAccess. C++ doesn’t allow to do that, but we can get away with something equivalent by using std::variant.

So we want a std::variant as a member, or something like that, and be able to get a const or non const reference on this when we need it in operator[].

This is not something straightforward to implement (although not very difficult) especially since std::variant does not accept reference types.

Luckily, we’ve already done all the work when we saw How to Store an lvalue or an rvalue in the Same Object.

Let’s reuse our code from back then, with the Storage type and its accessors getReference and getConstReference. We can just initialise the data member of type Storage depending on the incoming value in the constructor:

template
class StrongIndexAccess
{
public:
    explicit StrongIndexAccess(std::vector& vector) : vector_(NonConstReference(vector)){}
    explicit StrongIndexAccess(std::vector const& vector) : vector_(ConstReference(vector)){}
    explicit StrongIndexAccess(std::vector&& vector) : vector_(Value(std::move(vector))){}

    typename std::vector::reference operator[](Index pos)
    {
        auto& vector = getReference(vector_);
        return vector[pos.get()];
    }

    typename std::vector::const_reference operator[](Index pos) const
    {
        auto const& vector = getConstReference(vector_);
        return vector[pos.get()];
    }

private:
    Storage> vector_;
};

If you’re curious about how Storage works exactly, have a look at this preview article.

Where to put the custom code

In the previous article we saw how to introduce another data structure than std::vector to achieve our purpose of customising operator[]. And in this article we’ve just seen how to introduce a proxy to support the custom operator[] without changing the data structure.

The drawback of the proxy is that you have two objects in the client code: the data structure and the proxy. Whereas by customising the data structure there is only the data structure to manipulate. But the advantage of the proxy is that it is a more modular solution.

All in all, I prefer the solution of the proxy. Which one do you prefer? Would you have solved the problem of strong indexing differently? Let me know in a comment!

You will also like

Don't want to miss out ? Follow:
Share this post!

The post Strong Types for Safe Indexing in Collections – Part 2 appeared first on Fluent C++.

Strong Types for Safe Indexing in Collections – Part 1

Jonathan Boccara — Sun, 31 Oct 2021 01:00:22 +0000

Strong types make code safer and more expressive by using the type system to identify individual objects.

For example, to instantiate a class Rectangle with a certain width and height, we could write this:

Rectangle myRectangle{4, 5};

But then it isn’t clear for a reader of the code which of the two parameters is the width and which one is the height. Which one is 4? Which one is 5?

This makes code difficult to understand, and difficult to get right too. Indeed, swapping the parameters by mistake is a common source of bugs.

An alternative is to introduce new types, Width and Height, and make the constructor accept them instead of primitive types:

Rectangle myRectangle{Width{4}, Height{5}};

This makes the code much more expressive and safer.

Strong typing is a very rich topic (you can find dozens of articles on strong types on Fluent C++) and helps make code more expressive in many ways.

Let’s focus on one of those ways: using strong types for safe indexing in collections.

Using the right index

The need for “strong indexing” came from an issue raised in the NamedType library (an implementation of strong types for C++): how can we use strong types to make sure to use the correct index when working with several collections?

Let’s use std::vector to represent the collections here. We have two vectors:

std::vector foos = {1, 2, 3};
std::vector bars = {10, 20};

And we’d like to have an index for each vector, that can only be used for that vector. This way, we make sure not to use an index with the wrong vector.

Let’s create two separate indices by using strong types:

using FooIndex = NamedType;
using BarIndex = NamedType;

Those are two different types wrapping a size_t and that can be incremented and compared.

Then we’d like this code to compile:

for (FooIndex fooIndex = FooIndex{0}; fooIndex < FooIndex{foos.size()}; ++fooIndex)
{
    for (BarIndex barIndex = BarIndex{0}; barIndex < BarIndex{bars.size()}; ++barIndex)
    {
        std::cout << foos[fooIndex] << '-' << bars[barIndex] << '\n'; // ok, correct indices
    }
}

And we would like the following code to fail to compile:

for (FooIndex fooIndex = FooIndex{0}; fooIndex < FooIndex{foos.size()}; ++fooIndex)
{
    for (BarIndex barIndex = BarIndex{0}; barIndex < BarIndex{bars.size()}; ++barIndex)
    {
        std::cout << foos[barIndex] << '-' << bars[fooIndex] << '\n'; // oops, wrong indices!
    }
}

How do we do this?

Unless we change the code of the implementation of a standard library, we can’t write the exact above pieces of code. Indeed, std::vector‘s operator[] doesn’t take a FooIndex or a BarIndex, to begin with.

But we can adapt the code a little to make it valid. We’ll see two different ways:

introducing a strongly indexed vector (this post),
creating a strongly indexed reference an a normal std::vector (the next post).

A strongly indexed vector

What prevents us from writing the above code is that std::vector doesn’t have the interface we need: it doesn’t accept FooIndex and BarIndex. Let’s not use vector then, but introduce a new container instead!

On the other hand, it would be a shame to give up on everything vector provides, and code it up from scratch ourselves, just for the purpose of tweaking the operator[].

It would be great to reuse std::vector for everything except operator[].

There are at least three ways to do that: public inheritance, private inheritance and composition. Let’s start with public inheritance, that require the least code to write.

Public inheritance

To reuse all the interface of std::vector, we can inherit from it. Here is the code, we’ll explain it bit by bit just after:

template
class StrongIndexVector : public std::vector
{
public:
    StrongIndexVector() = default;
    explicit StrongIndexVector(typename std::vector::size_type count, const T& value = T()) : std::vector(count, value) {}
    template< class InputIt >
    StrongIndexVector(InputIt first, InputIt last) : std::vector(first, last) {}
    StrongIndexVector(std::initializer_list init) : std::vector(std::move(init)) {}

    typename std::vector::reference operator[]( Index pos )
    {
        return std::vector::operator[](pos.get());
    }

    typename std::vector::const_reference operator[]( Index pos ) const
    {
        return std::vector::operator[](pos.get());
    }
};

Let’s start with the first line:

template

Like std::vector, our class can store values of any type T. It also has a specific Index type, that would be in our initial example FooIndex or BarIndex.

Let’s skip to the end of the class:

    typename std::vector::reference operator[]( Index pos )
    {
        return std::vector::operator[](pos.get());
    }

    typename std::vector::const_reference operator[]( Index pos ) const
    {
        return std::vector::operator[](pos.get());
    }
};

We use this index to achieve our purpose and have an operator[] that only works with the specific index. This operator[] hides the one of the base class std::vector (read Item 33 of Effective C++ to learn more about this mechanism).

The rest of the code allows to reuse everything else from std::vector:

class StrongIndexVector : public std::vector
{
public:
    StrongIndexVector() = default;
    explicit StrongIndexVector(typename std::vector::size_type count, const T& value = T()) : std::vector(count, value) {}
    template< class InputIt >
    StrongIndexVector(InputIt first, InputIt last) : std::vector(first, last) {}
    StrongIndexVector(std::initializer_list init) : std::vector(std::move(init)) {}

The call site then looks like this:

using FooIndex = fluent::NamedType;
using BarIndex = fluent::NamedType;

StrongIndexVector foos = {1, 2, 3};
StrongIndexVector bars = {10, 20};

for (FooIndex fooIndex = FooIndex{0}; fooIndex < FooIndex{foos.size()}; ++fooIndex)
{
    for (BarIndex barIndex = BarIndex{0}; barIndex < BarIndex{bars.size()}; ++barIndex)
    {
        std::cout << foos[fooIndex] << '-' << bars[barIndex] << '\n';
    }
}

The first two lines create two strong types over a size_t, in order to have two different types of indices.

Although using public inheritance works here, it’s arguably not the optimal solution, because it has several drawbacks. If a StrongIndexVector is (implicitly) cast into a std::vector, then the native operator[] of std::vector is available again and we’re back to square one.

Also, this is less likely to happen but if a StrongIndexVector is dynamically allocated, then deleted through a pointer to its base class std::vector, then we get to undefined behaviour.

Advantages:

Little code

Drawbacks:

Not ideal when cast to base class

Let’s explore the alternative of private inheritance then.

Private inheritance

As Federico demonstrates in his post on restricting interfaces, private inheritance provides an interesting trade-off to reuse code in an expressive way.

By default, private inheritance doesn’t expose anything from the interface of the base class. We have to add back whatever we want to reuse from the base class with using declarations. In our case, we want to reuse everything except operator[]. And then we write our own operator[](highlighted):

template
class StrongIndexVector : private std::vector
{
public:
    StrongIndexVector() = default;
    explicit StrongIndexVector(typename std::vector::size_type count, const T& value = T()) : std::vector(count, value) {}
    template< class InputIt >
    StrongIndexVector(InputIt first, InputIt last) : std::vector(first, last) {}
    StrongIndexVector(std::initializer_list init) : std::vector(std::move(init)) {}
    StrongIndexVector(StrongIndexVector const& other) = default;
    StrongIndexVector(StrongIndexVector&& other) = default;

    typename std::vector::reference operator[]( Index pos )
    {
        return std::vector::operator[](pos.get());
    }

    typename std::vector::const_reference operator[]( Index pos ) const
    {
        return std::vector::operator[](pos.get());
    }

    using typename std::vector::value_type;
    using typename std::vector::allocator_type;
    using typename std::vector::size_type;
    using typename std::vector::difference_type;
    using typename std::vector::reference;
    using typename std::vector::const_reference;
    using typename std::vector::pointer;
    using typename std::vector::const_pointer;
    using typename std::vector::iterator;
    using typename std::vector::const_iterator;
    using typename std::vector::reverse_iterator;
    using typename std::vector::const_reverse_iterator;

    StrongIndexVector& operator=(StrongIndexVector const& other) = default;
    StrongIndexVector& operator=(StrongIndexVector&& other) = default;
    using std::vector::operator=;

    using std::vector::assign;
    using std::vector::get_allocator;
    using std::vector::at;
    using std::vector::front;
    using std::vector::back;
    using std::vector::data;
    using std::vector::begin;
    using std::vector::cbegin;
    using std::vector::end;
    using std::vector::cend;
    using std::vector::rbegin;
    using std::vector::crbegin;
    using std::vector::rend;
    using std::vector::crend;
    using std::vector::empty;
    using std::vector::size;
    using std::vector::max_size;
    using std::vector::reserve;
    using std::vector::capacity;
    using std::vector::shrink_to_fit;
    using std::vector::clear;
    using std::vector::insert;
    using std::vector::emplace;
    using std::vector::erase;
    using std::vector::push_back;
    using std::vector::emplace_back;
    using std::vector::pop_back;
    using std::vector::resize;
    using std::vector::swap;
};

This can be a little unsettling as private inheritance is not so common in production code. But I don’t think this is a real drawback, since as we saw in the The Common Vocabulary of Software Developers, we should level up to the standard coding techniques, and not the other way round.

Advantages:

Not castable to base class

Drawbacks:

A bit long to write (but feel free to copy-paste!)

Composition

Composition is the solution that is commonly seen as the most reasonable, because it doesn’t use inheritance and inheritance is generally frowned upon in design when it’s not absolutely necessary.

Composition consists in storing a std::vector as a data member of StrongIndexVector, and wrap each function of its interface. For example, for push_back, we’d write:

template
class StrongIndexVector
{
public:

    // ...

    void push_back(T const& value)
    {
        vector_.push_back(value);
    }

    void push_back(T&& value)
    {
        vector_.push_back(std::move(value));
    }

    // ...
    
private:
    std::vector vector_;
};

And we would also write our own version of operator[] as in the previous code using inheritance.

This represents loads of code, and I think it brings little more than private inheritance.

Advantages:

More conventional

Disadvantages:

Loads of code

A strongly indexed reference

So far we’ve seen how to design a container with a special operator[]. But there is another approach: using a proxy on a regular std::vector, and implement our operator[] on the proxy.

We’ve seen a lot today, and we’ll keep this for the next post. In the meantime I suggest that you implement that proxy idea on your own, because it’s a good C++ exercise. Don’t forget that the incoming vector could be const or not const, and that it can be an lvalue or an rvalue!

More on that in the next article. Stay tuned!

You will also like

Don't want to miss out ? Follow:
Share this post!

The post Strong Types for Safe Indexing in Collections – Part 1 appeared first on Fluent C++.

Strong Types on Collections

Jonathan Boccara — Fri, 26 Jul 2019 01:00:42 +0000

Do we need a special strong type library for collections? Or can we strongly type collections like we do for any object?

If you’re joining us right now and haven’t read the previous articles on strong types, long story short, a strong type is a type used instead of another one in order to add meaning via its name.

Long story a little less short: check out this way to define a strong type in C++ with a library and that way to define one with native C++ features.

And long story long: here is the ever-growing series on strong types on Fluent C++:

Strong typing on a collection: motivating example

As a motivating example to strongly type collections, consider the following class:

class Team
{
public:
    template
    Team(TEmployee&&... teamMembers) : teamMembers_{std::forward(teamMembers)...} {}
    
    std::vector const& get() const { return teamMembers_; }
private:
    std::vector teamMembers_;
};

It represents a team of people, which is not much more than a vector of Employees, but than we’d like to see tagged as “team” in the code that uses it.

This code is inspired (quite largely) from a piece of code I came across recently. It wasn’t about teams and employees, but that was the general gist of it.

Its purpose is to allow the nice following syntax:

auto team1 = Team(Alice, Bob, Tom);
auto team2 = Team(Arthur, Trillian);

Also, Team is a type that is different from std::vector, and if there were another concept of grouping employees together, it would be yet another type, different from Team.

Granted, maybe there isn’t so many ways to group employees together. But if you replace Employee with int, then there are many more possible meanings to give to std::vector, and it could be useful to make sure we don’t mix them up, by giving each one its specific type. A typical example of mixup is to pass several of them in the wrong order to a function.

All this works well for teams and for ints, but we can imagine that it would equally apply to other groups of stuff. It would be nice to make this code generic, and have a facility to strongly type collections.

We already have a library that performs strong typing on C++ objects: NamedType. Can it spare us from re-implementing the Team class?

Strong typing on collections

Let’s make an attempt to use NamedType here:

using Team = NamedType, struct TeamTag>;

That’s a terser declaration. Now let’s have a look at the call site:

auto team1 = Team(std::vector{Alice, Bob, Tom});
auto team2 = Team(std::vector{Arthur, Trillian});

Ouch. It doesn’t look as nice as before, because of the std::vector sticking out.

But before we thing of a way of chopping it off, let’s pause and reflect on whether it is good or bad to make the std::vector show after all.

Clearly, it wasn’t the intent of the initial code. Indeed, the purpose of Team was to encapsulate the raw collection behind a meaningful type. But on the other hand, maybe we do care that it’s a vector. Indeed, as advocated in Effective STL Item 2: “Beware the illusion of container-independent code.” So maybe showing that it’s a vector isn’t such a bad thing.

But on the other other hand, what else would you want it to be? Indeed, Herb Sutter and Andrei Alexandrescu advise to “Use vector by default”, in Item 76 of their popular C++ Coding Standards.

So there are pros and cons to make the vector show, but let’s assume that we would like to hide it. Is there a way to do it and have generic code?

A `NamedVector`?

One idea is to design a new class alongside NamedType, that would be dedicated to handling vectors:

template 
class NamedVector
{
public:
    template
    explicit NamedVector(TElement&&... elements) : collection_({std::forward(elements)...}) {}

    std::vector& get() { return collection_; }
    std::vector const& get() const {return collection_; }

private:
    std::vector collection_;
};

To instantiate the Team type we would do:

using Team = NamedVector;

And we get the nice syntax back:

auto team1 = Team(Alice, Bob, Tom);
auto team2 = Team(Arthur, Trillian);

But a generic class like NamedVector has drawbacks: first, there is already a generic class (NamedType) and it would be simpler if there were only one. And what’s more, we’ve made NamedVector but we would also need NamedMap, NamedSet, NamedArray and NamedList (er, ok, maybe not NamedList).

A convenient constructor of `std::vector`

It turns out that we don’t need NamedVector, because a slight change to the code would make it compile, without showing the underlying std::vector:

using Team = NamedType, struct TeamTag>;

auto team1 = Team({Alice, Bob, Tom});
auto team2 = Team({Arthur, Trillian});

How does this work? It relies on the constructor of std::vector that accepts an std::initializer_list. And this constructor is not explicit, so we don’t need to type std::vector to instantiate it.

An additional pair of braces popped up, but it simplifies a lot the library code.

Have you already encountered the need for a strong vector? Which solution do you prefer: a dedicated Team class, a NamedVector, or a NamedType with std::vector‘s implicit conversion? Do you have another solution?

Getting the Benefits of Strong Typing in C++ at a Fraction of the Cost

Jonathan Boccara — Fri, 06 Apr 2018 01:00:30 +0000

Guest writer Vincent Zalzal talks to us about lightweight strong types. Vincent is a software developer working in the computer vision industry for the last 12 years. He appreciates all the levels of complexity involved in software development, from how to optimize memory cache accesses to devising algorithms and heuristics to solve complex applications, all the way to developing stable and user-friendly frameworks. You can find him online on Twitter or LinkedIn.

Strong types promote safer and more expressive code. I won’t repeat what Jonathan has presented already in his series on strong types.

I suspect some people may find that the NamedType class template has a nice interface but is using a somewhat heavy machinery to achieve the modest goal of strong typing. For those people, I have good news: you can achieve many of the functionalities of NamedType, with a very simple tool. That tool is the humble struct.

Struct as strong type

Let’s look at a simplified version of NamedType, without Skills:

template 
class NamedType
{
public:
    explicit NamedType(T const& value) : value_(value) {}

    template>
    explicit NamedType(T&& value) : value_(std::move(value)) {}

    T& get() { return value_; }
    T const& get() const {return value_; }

private:
    T value_;
};

This class is hiding the underlying value, and giving access to it with get(). There seems to be no set() method, but it is still there, hidden in the get() function. Indeed, since the get() function returns a non-const reference, we can do:

using Width = NamedType;
Width width(42);
width.get() = 1337;

Since the get() method is not enforcing any invariant and the underlying value is accessible, it is essentially public. Let’s make it public then! By doing so, we get rid of the get() functions. Also, since everything in the class is public, and since, semantically, it is not enforcing any invariant, let’s use a struct instead:

template 
struct NamedType
{
    explicit NamedType(T const& value) : value_(value) {}

    template>
    explicit NamedType(T&& value) : value_(std::move(value)) {}

    T value_;
};

But wait: do we really need those explicit constructors? If we remove them, we can use aggregate initialization, which performs exactly the same thing. We end up with:

template 
struct NamedType
{
    T value_;
};

That struct is not reusing code anymore. So the last simplification is to use a non-template struct directly to define the strong type.

struct Width { double v; };

There you have it: a strong type, without heavy machinery. Want to see it in action?

struct Width { double v; };
struct Height { double v; };

class Rectangle { /* ... */ };
Rectangle make_rect(Width width, Height height) { return Rectangle(/* ... */); }
Rectangle make_square(Width width) { return Rectangle(/* ... */); }

void foo()
{
    // Aggregate initialization copies lvalues and moves rvalues.
    Width width {42.0};

    // constexpr also works.
    constexpr Width piWidth {3.1416};

    // get() and set() are free.
    // set() copies lvalues and moves rvalues.
    double d = width.v;
    width.v = 1337.0;

    // Copy and move constructors are free.
    Width w1 {width};
    Width w2 {std::move(w1)};

    // Copy and move assignment operators are free.
    w1 = width;
    w2 = std::move(w1);

    // Call site is expressive and type-safe.
    auto rect = make_rect(Width{1.618}, Height{1.0});
    // make_rect(Height{1.0}, Width{1.618}); does not compile

    // Implicit conversions are disabled by default.
    // make_rect(1.618, 1.0); does not compile
    // double d1 = w1; does not compile

    // Call site can also be terse, if desired (not as type-safe though).
    auto square = make_square( {2.718} );
}

This code looks a lot like the one you would get using NamedType (except for the last line that would be prevented by the explicit constructor). Here are some added benefits of using structs as strong types:

more readable stack traces (NamedType can generate pretty verbose names)
code easier to understand for novice C++ developers and thus easier to adopt in a company
one fewer external dependency

I like the convention of using v for the underlying value, because it mimics what the standard uses for variable templates, like std::is_arithmetic_v or std::is_const_v. Naturally, you can use whatever you find best, like val or value. Another nice convention is to use the underlying type as name:

struct Width { double asDouble; };

void foo()
{
    Width width {42};
    auto d = width.asDouble;
}

Skills

Using the struct as presented above requires accessing the underlying member directly. Often, few operations on the struct are necessary, and direct access to the underlying member can be hidden in member functions of the class using the strong type. However, in other cases where arithmetic operations are necessary, for example, in the case of a width, then skills are needed to avoid having to implement operators again and again.

The inheritance approach used by NamedType or boost::operators works well. I do not claim that the method I will present here is elegant, but it is an alternative to using inheritance that has advantages, notably simplicity.

Operator Overloading

First, note that almost all operators in C++ can be implemented as non-member functions. Here are the operators that cannot be implemented as non-member functions:

assignment, i.e. operator= (in our case, the implicitly-generated version is okay)
function call, i.e. operator()
subscripting, i.e. operator[]
class member access, i.e. operator->
conversion functions, e.g. operator int()
allocation and deallocation functions (new, new[], delete, delete[])

All other overloadable operators can be implemented as non-member functions. As a refresher, here they are:
– unary: + - * & ~ ! ++ (pre and post) -- (pre and post)
– binary: + - * / % ^ & | < > += -= *= /= %= ^= &= |= << >> >>= <<= == != <= >= && || , ->*

As an example, for the Width type above, the less-than operator would look like this:

inline bool operator<(Width lhs, Width rhs)
{
    return lhs.v < rhs.v;
}

As a side note, I chose to pass the widths by value in the code above for performance reasons. Given their small size, those structs are typically passed in directly in registers, like arithmetic types. The optimizer will also optimize the copy away since it is working mostly on arithmetic types here. Finally, for binary operations, further optimizations are sometimes possible because the compiler knows for certain there is no aliasing, i.e. the two operands do not share the same memory. For bigger structs (my personal threshold is more than 8 bytes) or structs with non-trivial constructors, I would pass the parameters by const lvalue reference.

All other relational operators would have to be defined similarly. To avoid repeating that code over and over again for each strong type, we must find a way to generate that code.

The Inheritance Approach

NamedType uses inheritance and CRTP as code generator. It has the advantage of being part of the language. However, it pollutes the type name, especially when looking at a call stack. For example, the function:

using NT_Int32 = fluent::NamedType;
void vectorAddNT(NT_Int32* dst, const NT_Int32* src1, const NT_Int32* src2, int N);

results in the following line in the call stack:

vectorAddNT(fluent::NamedType * dst, const fluent::NamedType * src1, const fluent::NamedType * src2, int N)

This is for one skill; the problem gets worse the more skills are added.

The Preprocessor Approach

The oldest code generator would be the preprocessor. Macros could be used to generate the operator code. But code in macros is rarely a good option, because macros can’t be stepped into while debugging.

Another way to use the preprocessor as code generator is to use include files. Breakpoints can be set in included files without problem, and they can be stepped into. Unfortunately, to pass parameters to the code generator, we must resort to using define directives, but it is a small price to pay.

struct Width { double v; };

#define UTIL_OP_TYPE_T_ Width
#include 
#undef UTIL_OP_TYPE_T_

The file less_than_comparable.hxx would look like this:

inline bool operator<(UTIL_OP_TYPE_T_ lhs, UTIL_OP_TYPE_T_ rhs)
{
    return lhs.v < rhs.v;
}
inline bool operator>(UTIL_OP_TYPE_T_ lhs, UTIL_OP_TYPE_T_ rhs)
{
    return lhs.v > rhs.v;
}
// ...

It is a good idea to use a different extension than usual for files included in this way. These are not normal headers; for example, header guards must absolutely not be used in them. The extension .hxx is less frequently used, but it is recognized as C++ code by most editors, so it can be a good choice.

To support other operators, you simply include multiple files. It is possible (and desirable) to create a hierarchy of operators, as is done in boost::operators (where the name less_than_comparable comes from). For example, the skills addable and subtractable could be grouped under the name additive.

struct Width { double v; };

#define UTIL_OP_TYPE_T_ Width
#include 
#include 
// ...
#undef UTIL_OP_TYPE_T_

// util/operators/additive.hxx

#include 
#include 

// util/operators/addable.hxx

inline UTIL_OP_TYPE_T_ operator+(UTIL_OP_TYPE_T_ lhs, UTIL_OP_TYPE_T_ rhs)
{
    return {lhs.v + rhs.v};
}
inline UTIL_OP_TYPE_T_& operator+=(UTIL_OP_TYPE_T_& lhs, UTIL_OP_TYPE_T_ rhs)
{
    lhs.v += rhs.v;
    return lhs;
}

// etc

It may come as a surprise that operator+= can be implemented as a non-member function. I think it highlights the fact that the struct is seen as data, not as object. It has no member function in itself. However, as mentioned above, there are a few operators that cannot be implemented as non-member functions, notably, operator->.

I would argue that if you need to overload those operators, the strong type is not semantically a struct anymore, and you would be better off using NamedType.

However, nothing prevents you from including files inside the struct definition, even if a few people may cringe when seeing this:

#define UTIL_OP_TYPE_T_ WidgetPtr
struct WidgetPtr
{
    std::unique_ptr v;
    #include 
};
#undef UTIL_OP_TYPE_T_

The Code Generator Approach

Big companies like Google rely more and more on bots to generate code (see protobuf) and commits (see this presentation). The obvious drawback of the method is that you need an external tool (like Cog for example) integrated into the build system to generate the code. However, once the code is generated, it is very straightforward to read and use (and also to analyze and compile). Since each strong type has its own generated copy, it is also easier to set a breakpoint in a function for a specific type.

Using a tool to generate code can lead to an elegant pseudo-language of keywords added to the language. This is the approach taken by Qt, and they defend it well (see Why Does Qt Use Moc for Signals and Slots?)

Skills for enums

Skills can also be useful on enums to implement bit flags. As a side note, the inheritance approach cannot be applied to enums, since they can’t inherit functionality. However, strategies based on non-member functions can be used in that case. Bit flags are an interesting use-case that deserve an article of their own.

Performance

As Jonathan already stated, NamedType is a zero-cost abstraction: given a sufficient level of optimisation (typically O1 or O2), compilers emit the same code as if arithmetic types were used directly. This also holds for using a struct as strong type. However, I wanted to test if compilers were also able to vectorize the code correctly when using NamedType or a struct instead of arithmetic types.

I compiled the following code on Visual Studio 2017 (version 15.5.7) with default release options in both 32-bit and 64-bit configurations. I used godbolt to test GCC 7.3 and Clang 5.0 in 64-bit, using the -O3 optimization flag.

using NT_Int32 = fluent::NamedType;

struct S_Int32 { int32_t v; };

S_Int32 operator+(S_Int32 lhs, S_Int32 rhs)
{
    return { lhs.v + rhs.v };
}

void vectorAddNT(NT_Int32* dst, const NT_Int32* src1, const NT_Int32* src2, int N)
{
    for (int i = 0; i < N; ++i)
        dst[i] = src1[i] + src2[i];
}

void vectorAddS(S_Int32* dst, const S_Int32* src1, const S_Int32* src2, int N)
{
    for (int i = 0; i < N; ++i)
        dst[i] = src1[i] + src2[i];
}

void vectorAddi32(int32_t* dst, const int32_t* src1, const int32_t* src2, int N)
{
    for (int i = 0; i < N; ++i)
        dst[i] = src1[i] + src2[i];
}

Under Clang and GCC, all is well: the generated code is the same for all three functions, and SSE2 instructions are used to load, add and store the integers.

Unfortunately, results under VS2017 are less than stellar. Whereas the generated code for arithmetic types and structs both use SSE2 instructions, NamedType seems to inhibit vectorization. The same behavior can be observed if get() is used directly instead of using the Addable skill. This is something to keep in mind when using NamedType with big arrays of data.

VS2017 also disappoints in an unexpected way. The size of NT_Int32 is 4 bytes on all platforms, with all compilers, as it should be. However, as soon as a second skill is added to the NamedType, for example Subtractable, the size of the type becomes 8 bytes! This is also true for other arithmetic types. Replacing int32_t in the NamedType alias with double yields a size of 8 bytes for one skill, but 16 bytes as soon as a second skill is added.

Is it a missing empty base class optimization in VS2017? Such a pessimization yields memory-inefficient, cache-unfriendly code. Let’s hope future versions of VS2017 will fare better.

EDIT: As redditer fernzeit pointed out, the empty base class optimization is disabled by default when using multiple inheritance on Visual Studio. When using the __declspec(empty_bases) attribute, Visual Studio generates the same class layout as Clang and GCC. The attribute has been added to the NamedType implementation to fix the issue.

Compilation time

A criticism often formulated against templates is that they tend to slow compilation down. Could it affect NamedType? On the other hand, since all the code for NamedType is considered external to a project, it can be added to a precompiled header, which means it will be read from disk and parsed only once.

Using a struct as strong type with include files for skills does not incur the template penalty, but requires reading from disk and parsing the skill files again and again. Precompiled headers cannot be used for the skill files, because they change each time they are included. However, the struct can be forward declared, a nice compilation firewall that NamedType cannot use, since type aliases cannot be forward declared.

To test compilation time, I created a project with 8 strong types, each contained in its own header file, and 8 simple algorithms, each using one strong type and having both a header file and an implementation file. A main file then includes all the algorithm headers, instantiates the strong types and call the functions one at a time.

Compilation time has been measured in Visual Studio 2017 (version 15.5.7) using the very useful VSColorOutput extension (check it out!). Default compilation options for a Windows console application were used. For every configuration, 5 consecutive compilations have been performed and the median time computed. Consequently, these are not “cold” times, caching affects the results.

Two scenarios have been considered: the full rebuild, typical of build machines, and the single-file incremental build, typical of the inner development loop.

32-bit and 64-bit configurations yielded no significant difference in compilation time, so the average of the two is reported below. This is also the case for debug and release configurations (unless otherwise stated). All times are in seconds, with a variability of about ± 0.1s.

Table 1: Compilation time, in seconds, of different strong typing strategies, without precompiled headers.

A first look at the results in Table 1 could lead to hasty conclusions. NamedType appears slower, but its compilation time can be greatly reduced with the use of precompiled headers. Also, the other strategies have an unfair advantage: they don’t include any standard headers. NamedType includes four of them: type_traits, functional, memory and iostream (mostly to implement the various skills). In most real-life projects, those headers would also be included, probably in precompiled headers to avoid slowing down compilation time.

Also it’s worth noting that NamedType currently brings in all skills in the same header. Presumably, including skill headers on demand could decrease compilation time in some applications.

To get a fairer picture, precompiled headers have been used to generate the results in Table 2 below:

Table 2: Compilation time, in seconds, of different strong typing strategies, with precompiled headers.

Ah, much nicer! It is hazardous to extrapolate these results to bigger, real-life projects, but they are encouraging and support the idea that strong typing is a zero-cost abstraction, with negligible impact on compilation time.

Conclusion

My goal is not to convince you that using structs as strong types is better than using NamedType. Rather, strong typing is so useful that you should have alternatives if NamedType doesn’t suit you for some reason, while we wait for an opaque typedef to be part of the C++ standard.

One alternative that is easy to adopt is to use structs as strong types. It offers most of NamedType functionality and type safety, while being easier to understand for novice C++ programmers — and some compilers.

If you have questions or comments, I would enjoy reading them! Post them below, or contact me on Twitter.

Don't want to miss out ? Follow:
Share this post!

The post Getting the Benefits of Strong Typing in C++ at a Fraction of the Cost appeared first on Fluent C++.

Strong Types For Strong Interfaces: my talk at Meeting C++

Jonathan Boccara — Fri, 02 Feb 2018 01:00:26 +0000

A couple of weeks ago I had the opportunity to speak at Meeting C++, in Berlin. This talk has come out on Youtube recently, and I’d like to share it with you.

This presentation sums up the fundamental aspects of strong typing in C++ as I see it. I hope you enjoy it! Of course, any feedback is welcome.

If you want to read about more advanced or exploratory aspects of strong typing, you can also have a look at the Strong types section of the contents of Fluent C++.

Don't want to miss out ? Follow:
Share this post!

The post Strong Types For Strong Interfaces: my talk at Meeting C++ appeared first on Fluent C++.

How to Be Clear About What Your Functions Return

Jonathan Boccara — Tue, 23 Jan 2018 01:00:13 +0000

What’s in a function’s interface?

In most languages, a function’s interface has 3 main parts:

the function’s name: it indicates what the function does,
the function’s parameters: they show what the function takes as input to do its job,
the function’s return type: it indicates the output of the function.

ReturnType functionName(ParameterType1 parameterName1, ParameterType2 parameterName2);

So far, so good.

But when looking at this prototype, we can notice that something isn’t symmetric: the function’s parameters have both a type and a name, while the returned value only has a type. Indeed, the return value doesn’t have a name.

In a function declaration, one could choose to also omit the names of the parameters. But still, the return type doesn’t have a choice. It can only be… a type.

Why is that? My take is that it’s because we expect the the function’s name to be clear enough to express what it returns, plus the returned value has a visible type. So a name for the returned value itself would be superfluous.

But is this the case 100% of the time?

A use case that should not exist, but that does

No. In theory it works fine but, realistically, it’s not always the case that a function’s name informs you exactly of what to expect as a return value.

Let’s take the example of a function that performs a side effect, like saving a piece of information in a database:

void save(PieceOfData const& preciousData);

And say that this operation could potentially fail. How does the function lets it caller know whether or not the operation succeeded?

One way to go about that is to make the save function throw an exception. It works, but not everyone uses exceptions (exceptions need exception-safe code surrounding them, they may impact performance, some teams ban them from their coding conventions…). There have been hot debates and suggested alternatives about this.

We already come across a clear way to indicate that a function could potentially fail to return its result: using optionals. That is to say, return an optional, conveying the message that we expect to return a T, but this could potentially fail, and the function caller is supposed to check whether that returned optional is full or empty.

But here we’re talking about a function that returns nothing. It merely saves piece of data in a database. Should it return an optional then? This would read that it is supposed to return void but it may return something that isn’t really a void, but an empty box instead. An empty void. Weird. And std::optional doesn’t compile anyway!

Another possibility is to return a boolean indicating whether or not the function succeeded:

bool save(PieceOfData const& preciousData);

But this is less than ideal. First, the returned value could be ignored at call site. Though this could be prevented by adding the [[nodiscard]] attribute in C++17:

[[nodiscard]] bool save(PieceOfData const& preciousData);

Second, just by looking at the function’s prototype, we don’t know if that bool means success or failure. Or something else totally unrelated, for that matter. We could look it up in the documentation of the function, but it takes more time and introduces a risk of getting it wrong anyway.

Since the function is only called “save“, its name doesn’t say what the return type represents. We could call it something like saveAndReturnsIfSuceeded but… we don’t really want to see that sort of name in code, do we?

Meta information

It is interesting to realize that this is a more general use case that just failure or success. Indeed, sometimes the only way to retrieve a piece of information about a certain operation is to actually perform it.

For instance, say we have a function that takes an Input and uses it to add and to remove entries from a existing Entries collection:

void updateEntries(Input const& input, Entries& entries);

And we’d like to retrieve some data about this operation. Say an int that represents the number of entries removed, for example. We could make the function output that int via its return type:

int updateEntries(Input const& input, Entries& entries);

But the return type doesn’t tell what it represents here, only that it’s implemented as an int. We’ve lost information here.

In this particular case, we could have added an int& entriesRemoved function parameter, but I don’t like this pattern because it forces the caller to initialize a variable before calling the functions, which doesn’t work for all types, and a non-const reference means input-output and not output, so it’s not exactly the message we’d like to convey here.

What to do then?

Named return types: strong return types?

So in summary, we have return types that lack a meaningful name. This sounds like a job for strong types: indeed, strong types help put meaningful names over types!

Spoiler alert: strong types won’t be the option that we’ll retain for most cases of return types in the end. Read on to see why and what to use instead.

Let’s use NamedType as an implementation of strong types, and create return types with a name that make sense in each of our functions’ contexts.

So our save function returns a bool that is true if the operation was a success. Let’s stick a name over that bool:

using HasSucceeded = NamedType;

The second parameter of NamedType is a “phantom type”, that is to say that it’s there only for differentiating HasSucceeded from another NamedType over a bool.

Let’s use HasSucceeded in our function’s interface:

HasSucceeded save(PieceOfData const& preciousData);

The function now expresses that it returns the information about whether the operation succeeded or not.

The implementation of the function would build a HasSucceeded and return it:

HasSucceeded save(PieceOfData const& preciousData)
{
    // attempt to save...
    // if it failed
    return HasSucceeded(false);
    // else, if all goes well
    return HasSucceeded(true);
}

And at call site:

HasSucceeded hasSucceeded = save(myData); // or auto hasSucceeded = ...

if(!hasSucceeded.get())
{
    // deal with failure...

Note that we can choose to get rid of the call to .get() by making HasSucceeded use the FunctionCallable skill.

For the sake of the example, let’s apply the same technique to our updateEntries function:

using NumberOfEntriesRemoved = NamedType;

NumberOfEntriesRemoved updateEntries(Input const& input, Entries& entries);

By looking at the interface, we now know that it outputs the number of entries removed via the return type.

Just a weak type will do here

The above works, but it’s needlessly sophisticated. In this case, the only thing we need is a name for other human beings to understand the interface. We don’t need to create a specific type used only in the context of the return type to also let the compiler know what we mean by it.

Why is that? Contrast our example with the case of input parameters of a function:

void setPosition(int row, int column);

// Call site
setPosition(36, 42);

Since there are several parameters that could be mixed up (and the program would still compile), introducing strong types such as Row and Column are useful to make sure we pass the parameters in the right order:

void setPosition(Row row, Column column);

// Call site:
setPosition(Row(36), Column(42));

But in the return type, what is there to mix up? There is only one value returned anyway!

So a simple alias does the job just well:

using HasSucceeded = bool;
HasSucceeded save(PieceOfData const& preciousData);

This is the most adapted solution in this case, in my opinion.

The case where strong types are useful in return types

However there are at least two specific cases where strong types are helpful to clarify a returned value.

One is to use strong types to return multiple values.

The other is when you already have a strong type that represents the return value, and that you already use at other places in the codeline. For instance, if you have a strong type SerialNumber that strengthen a std::string, and you use it at various places, it makes perfect sense to return it from a function.

The point I want to make is not to create a strong type for the sole purpose of returning it from a function and immediately retrieving the value inside it afterwards. Indeed, in this case a classical alias will do.

What’s in a expressive function’s interface?

This technique helps us be more explicit about what it is that a function is returning.

This is part of a more general objective, which is to leverage on every element of the function to express useful information:

a clear function name: by using good naming,
well-designed function parameters (a 3-post series coming soon),
an explicit output: either by returning the output directly (thus making functions functional), or by using an optional or, if it comes to that, returning something else, like we saw today. But always, by being the clearest possible about it.

Strong Optionals

Jonathan Boccara — Tue, 16 Jan 2018 01:00:47 +0000

Both strong types and optionals are useful tools to make our interfaces more expressive. Could they be used in synergy to make one benefit from each other?

The contents of this post are at an experimental stage. They are laid out here to expose a problem and a possible solution, and as a basis for discussion. So your feedback will be welcome on this article (as it is welcome on any post, really).

All optionals are grey in the dark

Optional can be useful to execute partial queries.

For instance, let’s consider this interface that retrieves a collection of Employees that have a given first name and last name:

std::vector findEmployees(std::string const& firstName, std::string const& lastName);

The following call:

findEmployees("John", "Doe")

returns the collection of the employees that are called John Doe.

Now say that we want to add a new functionality: searching all the employees that have a given first name, like “John”. Or a given last name, like “Doe”.

To achieve this, we can make this interface accept optionals instead of hard strings:

std::vector findEmployees(std::optional const& firstName, std::optional const& lastName);

optional is available in the standard library in C++17, and has been in Boost for a long time before that.

To retrieve all the employees that have the first name “John”, we can pass it as a first parameter and pass an empty optional as a second parameter:

findEmployees("John", std::nullopt)

And similarly, to get all the employees that belong to the Doe family:

findEmployees(std::nullopt, "Doe")

This interface gets the job done, but has at least two problems, which are related:

Problem #1: the parameter std::nullopt express that we pass “no” parameter. But at call site, it hides what role this parameter should have had in the function. It’s no parameter, but no what? No first name? No last name? No something else?

Problem #2: with the meaning of this parameter hidden, it becomes arguably even easier to mix up the order of parameters: findEmployees(std::nullopt, "Doe") looks very much like findEmployees("Doe", std::nullopt), since both have only one “real” parameter.
And it gets more confusing if there are more parameters: findEmployees(std::nullopt, "Doe", std::nullopt), with the third parameter representing, say, the department of the employee. It then becomes harder to see if “Doe” really is at the correct position between the std::nullopts.

Strong optionals

Clarifying the role of each parameter of an interface sounds like a job for strong types. Would it be possible to have a “strong optional”, that doesn’t use std::nullopt as a default parameter, but something more specific to its meaning instead?

Let’s design a class around that constraint.

This class would be essentially like an optional, but with an additional type NoValue that represents an empty value. It would have a is-implemented-in-terms-of relationship with optional, so we model this by containing an optional inside the class (see Effective C++ items 32 and 38 for more about how to express the various relationship between entities in C++):

template
class NamedOptional
{
private:
    std::optional o_;
};

Its interface would resemble the one of std::optional except that it could be constructible from its NoValue type:

    NamedOptional(NoValue) noexcept : o_(){}

Now here is all the code put together. The interface of std::optional is richer than meets the eye so if you don’t like to look at tedious code, don’t look at this thorough forwarding to the interface of std::optional:

template
class NamedOptional
{
public:
    NamedOptional() noexcept : o_() {}
    NamedOptional(NoValue) noexcept : o_(){}
    constexpr NamedOptional(const NamedOptional& other) : o_(other.o_) {}
    constexpr NamedOptional( NamedOptional&& other ) noexcept : o_(std::move(other.o_)){}
    template < class U >
    NamedOptional( const NamedOptional& other ) : o_(other.o_) {}
    template < class U >
    NamedOptional( NamedOptional&& other ) : o_(std::move(other.o_)){}
    template< class... Args > 
    constexpr explicit NamedOptional( std::in_place_t, Args&&... args ) : o_(std::in_place, std::forward(args...)){}
    template< class U, class... Args >
    constexpr explicit NamedOptional( std::in_place_t,
                                 std::initializer_list ilist, 
                                 Args&&... args ) : o_(std::in_place, ilist, std::forward(args...)){}
    template
    NamedOptional(U&& x) : o_(std::forward(x)){}
    NamedOptional& operator=( NoValue ) noexcept { o_ = std::nullopt; }
    NamedOptional& operator=( const NamedOptional& other ) { o_ = other.o_; }
    NamedOptional& operator=( NamedOptional&& other ) noexcept(std::is_nothrow_move_assignable::value && std::is_nothrow_move_constructible::value) { o_ = std::move(other.o_); }
    template< class U = T > 
    NamedOptional& operator=( U&& value ) { o_ = std::forward(value); }
    template< class U >
    NamedOptional& operator=( const NamedOptional& other ) { o_ = other.o_; }
    template< class U >
    NamedOptional& operator=( NamedOptional&& other ) { o_ = std::forward(value); }
    constexpr std::optional const& operator->() const { return o_; }
    constexpr std::optional& operator->() { return o_; }
    constexpr const T& operator*() const& { return *o_; }
    constexpr T& operator*() & { return *o_; }
    constexpr const T&& operator*() const&& { return *std::move(o_); }
    constexpr T&& operator*() && { return *std::move(o_); }
    explicit operator bool () const { return static_cast(o_); }
    constexpr bool has_value() const noexcept { return o_.has_value(); }
    constexpr T& value() & { return o_.value(); }
    constexpr const T & value() const &  { return o_.value(); }
    constexpr T&& value() &&  { return std::move(o_).value(); }
    constexpr const T&& value() const && { return std::move(o_).value(); }
    template< class U > 
    constexpr T value_or( U&& default_value ) const& { return o_.value_or(std::forward(default_value)); }
    template< class U > 
    constexpr T value_or( U&& default_value ) && { return std::move(o_).value_or(std::forward(default_value)); }
    void swap( NamedOptional& other ) noexcept { return o_.swap(other.o_); }
    void reset() noexcept { o_.reset(); }
    template< class... Args > 
    T& emplace( Args&&... args ) { return o_.emplace(std::forward(args...)); }
    template< class U, class... Args > 
    T& emplace( std::initializer_list ilist, Args&&... args ) { return o_.emplace(ilist, std::forward(args...)); }

    template< class U > friend constexpr bool operator==( const NamedOptional& lhs, const NamedOptional& rhs ) { return lhs.o_ == rhs.o_; }
    template< class U > friend constexpr bool operator!=( const NamedOptional& lhs, const NamedOptional& rhs ) { return lhs.o_ != rhs.o_; }
    template< class U > friend constexpr bool operator<( const NamedOptional& lhs, const NamedOptional& rhs ) { return lhs.o_ < rhs.o_; }
    template< class U > friend constexpr bool operator<=( const NamedOptional& lhs, const NamedOptional& rhs ) { return lhs.o_ <= rhs.o_; }
    template< class U > friend constexpr bool operator>( const NamedOptional& lhs, const NamedOptional& rhs ) { return lhs.o_ > rhs.o_; }
    template< class U > friend constexpr bool operator>=( const NamedOptional& lhs, const NamedOptional& rhs ) { return lhs.o_ >= rhs.o_; }

    friend constexpr bool operator==( const NamedOptional& lhs, NoValue) { return lhs.o_ == std::nullopt; }
    friend constexpr bool operator!=( const NamedOptional& lhs, NoValue) { return lhs.o_ != std::nullopt; }
    friend constexpr bool operator< ( const NamedOptional& lhs, NoValue) { return lhs.o_ <  std::nullopt; }
    friend constexpr bool operator<=( const NamedOptional& lhs, NoValue) { return lhs.o_ <= std::nullopt; }
    friend constexpr bool operator> ( const NamedOptional& lhs, NoValue) { return lhs.o_ >  std::nullopt; }
    friend constexpr bool operator>=( const NamedOptional& lhs, NoValue) { return lhs.o_ >= std::nullopt; }
    friend constexpr bool operator==( NoValue, const NamedOptional& rhs) { return std::nullopt == rhs.o_; }
    friend constexpr bool operator!=( NoValue, const NamedOptional& rhs) { return std::nullopt != rhs.o_; }
    friend constexpr bool operator< ( NoValue, const NamedOptional& rhs) { return std::nullopt <  rhs.o_; }
    friend constexpr bool operator<=( NoValue, const NamedOptional& rhs) { return std::nullopt <= rhs.o_; }
    friend constexpr bool operator> ( NoValue, const NamedOptional& rhs) { return std::nullopt >  rhs.o_; }
    friend constexpr bool operator>=( NoValue, const NamedOptional& rhs) { return std::nullopt >= rhs.o_; }

    template< class U > friend constexpr bool operator==( const NamedOptional& lhs, const U& value) { return lhs.o_ == value; }
    template< class U > friend constexpr bool operator!=( const NamedOptional& lhs, const U& value) { return lhs.o_ != value; }
    template< class U > friend constexpr bool operator< ( const NamedOptional& lhs, const U& value) { return lhs.o_ <  value; }
    template< class U > friend constexpr bool operator<=( const NamedOptional& lhs, const U& value) { return lhs.o_ <= value; }
    template< class U > friend constexpr bool operator> ( const NamedOptional& lhs, const U& value) { return lhs.o_ >  value; }
    template< class U > friend constexpr bool operator>=( const NamedOptional& lhs, const U& value) { return lhs.o_ >= value; }
    template< class U > friend constexpr bool operator==( const U& value, const NamedOptional& rhs) { return value == rhs.o_; }
    template< class U > friend constexpr bool operator!=( const U& value, const NamedOptional& rhs) { return value != rhs.o_; }
    template< class U > friend constexpr bool operator< ( const U& value, const NamedOptional& rhs) { return value <  rhs.o_; }
    template< class U > friend constexpr bool operator<=( const U& value, const NamedOptional& rhs) { return value <= rhs.o_; }
    template< class U > friend constexpr bool operator> ( const U& value, const NamedOptional& rhs) { return value >  rhs.o_; }
    template< class U > friend constexpr bool operator>=( const U& value, const NamedOptional& rhs) { return value >= rhs.o_; }

    friend size_t std::hash>::operator()(NamedOptional const& x) const;
private:
    std::optional o_;
};

namespace std
{
template< typename T, typename NoValue >
void swap( NamedOptional& lhs, NamedOptional& rhs ) noexcept(noexcept(lhs.swap(rhs))) { return lhs.swap(rhs); }

template
struct hash>
{
    size_t operator()(NamedOptional const& x) const
    {
        return std::hash()(x.o_);
    }
};
}

Isn’t it like Boost Outcome / `std::expected`?

This NamedOptional component represents a value that could be there or not, and has an additional template parameter. From afar, this can look a bit like Outcome that is in Boost, or to its yet-to-be standard counterpart std::expected.

But when we get closer, we can see NamedOptional doesn’t represent the same thing as those two. Indeed, Outcome and expected represent a piece of data that could be empty, but accompanied with a piece of information that gives details about why it is empty. This is more powerful that optional or NamedOptional in this regard, as they only contain the binary information that the value is empty or not.

In our case we don’t need to know why it isn’t there. It is a partial query, so it is expected that some parameters are not specified. So optional and expected can serve different purposes, and NamedOptional is closer to optional and adds a more explicit names to the empty values.

Strong types + strong optionals

Let’s now use this strong optional to express that an empty parameter can mean “no first name” or “no last name”, and that those two mean a different thing:

struct NoFirstName{};
using OptionalFirstName = NamedOptional;

struct NoLastName{};
using OptionalLastName = NamedOptional;

EDIT: after discussing this with Ivan Čukić, we realized that “AnyFirstName” was better expressing the intention of “we don’t specify a first name because it could be any first name” than “NoFirstName”:

struct AnyFirstName{};
using OptionalFirstName = NamedOptional;

struct AnyLastName{};
using OptionalLastName = NamedOptional;

Note that, contrary to the usual definitions of NamedTypes, we can’t declare AnyFirstName inside the using declaration, because since we are going to instantiate it, we need a definition and not just a declaration.

To get all the employees of the Doe family we now have to write:

findEmployees(AnyFirstName(), "Doe");

which provides a solution to problems #1 and #2 above: we know what the empty argument stand for, and mixing up the arguments would not compile:

findEmployees("Doe", AnyFirstName()); // compilation error

because the second parameter, an OptionalLastName, cannot be constructed from a AnyFirstName.

To go further in clarifying the meaning of those function parameters, we can combine strong optionals with strong types:

using FirstName = NamedType;
struct AnyFirstName{};
using OptionalFirstName = NamedOptional;

using LastName = NamedType;
struct AnyLastName{};
using OptionalLastName = NamedOptional;

which leads to this type of call site:

findEmployees(AnyFirstName(), LastName("Doe"));

The purpose of this development was to clarify the role of each of the (possibly empty) parameters of the function.

Now that you’ve seen the problem and a possible solution, it’s your turn to express your opinion on this!

Do you think there is a need for strong optionals? Do you see another way to go about this issue?

You may also like:

Don't want to miss out ? Follow:
Share this post!

The post Strong Optionals appeared first on Fluent C++.

Strong Templates

Jonathan Boccara — Tue, 09 Jan 2018 01:00:49 +0000

Strong typing consists in creating a new type that stands for another type and adds meaning through its name. What would it look like to apply this idea to template interfaces?

Disclaimer: What you’ll see in this post is experimental, and it’d be great to have your feedback on it at the end.

Strong types for strong interfaces

We’ve talked a lot about how strong types can help clarify interfaces. Here is a quick example, that you can safely skip if you’re already familiar with strong types.

Consider a case where we want to represent in code the concept of rows and columns.

We could use ints to represent both, but doing this doesn’t carry any information about what those int represents, and that can even get confusing in an interface:

void setPosition(int row, int column);

Indeed, this interface expects a row first and then a column, but you can’t see that at call site:

setPosition(12, 14);

When writing that code, there is a risk of mixing up the row and the column. And when someone reads it, they can’t know whether 12 represents the row, the column, or even something completely unrelated.

Well, in theory, they can. They can go look up the definition of setPosition and check which parameters means what. But we don’t want the people that read our code to go look up the definition of every function we use, do we?

So we can define two dedicated types: Row and Column. Let’s do this by using the NamedType library:

using Row = NamedType;
using Column = NamedType;

This reads: “Row is like an int, but it’s a different type with a name stuck on it that says it’s a row, and not just any int“. And same for Column.

Using them clarifies the intent of the interface:

void setPosition(Row row, Column column);

which leads to both a more expressive code at call site:

setPosition(Row(12), Column(14));

and more safety against the risk of mixing up the parameters. Indeed, the following would not compile since Row and Column are two different types:

setPosition(Column(14), Row(12)); // compilation error!

This example was a function interface, but this idea can be also applied to template interfaces.

Template interface

By template interface, I mean a template instantiation out of which we can get a result.

Here is a simple one in the standard library since C++11 (but that could be replicated even in C++98):

template< typename Base, typename Derived >
struct is_base_of;

is_base_of “returns” a boolean that indicates whether or not the first template parameter is a base class of the second template parameter.

Such a template interface has several ways of “returning” something that depends on its template parameters. In this particular case it returns a value, and the convention for it is that this value is stored in a static public constant member of the class, called value.

So, if Derived derives from Base then is_base_of::value is true. Otherwise, it is false.

And in C++14 appear template variables, which let us store the result into a variable, encapsulating the ::value:

template
constexpr bool is_base_of_v = std::is_base_of::value;

(despite being technically doable in C++14, is_base_of_v becomes standard in C++17).

This looks OK. But what if, like it is in reality, our types are not called Base and Derived? What if they’re called A and B (which are not realistic names either, hopefully, but this is to illustrate the case where the name don’t show which is the base and which is the derived)?

is_base_of_v

What does the above mean? Should this read “A is the base of B“, or rather “B is the base of A“? I suppose the first one is more likely, but the interface doesn’t express it explicitly.

To quote Andrei Alexandrescu in Modern C++ Design:

Why use SUPERSUBCLASS and not the cuter BASE_OF or INHERITS? For a very practical reason. Initially Loki used INHERITS. But with INHERITS(T, U) it was a constant struggle to say which way the test worked—did it tell whether T inherited U or vice versa?

Let’s try to apply the ideas of strong typing that we saw above to this template interface.

Strong templates

So, just like we had Row(12) and Column(14), the purpose is to have something resembling Base(A) and Derived(B).

Since these are template types, let’s create a template Base and a template Derived, which exist just for the sake of being there and don’t contain anything:

template
struct Base{};

template
struct Derived{};

We can then use those two templates to wrap the parameters of the is_base_of interface. Just for fun, let’s call that strong_is_base_of:

template
constexpr bool strong_is_base_of_v;

template
constexpr bool strong_is_base_of_v, Derived> = is_base_of_v;

Note that, contrary to the usual strong typing we do on types, we don’t need an equivalent of the .get() method here. This is because templates use pattern matching of types (this is why there is a primary template that is declared but not defined, and a secondary template with a specific pattern containing Base and Derived that is fully defined).

The above uses C++14 template variables (that can be partially specialized).

Here is what it looks like before C++14 without variable templates:

template
struct strong_is_base_of{};

template
struct strong_is_base_of, Derived> : std::is_base_of {};

It is designed along the same lines of the C++14 solution, but uses inheritance of is_base_of to bring in the value member instead of a variable template.

Usage

Let’s now see what this looks like at call site, which was the point of all this implementation!

Let’s use a type A that is the base class of a type B:

class A
{
    // ...
};

class B : public A
{
    // ...
};

Here is how to check that A is indeed a base class of B, as the following compiles:

static_assert( strong_is_base_of_v, Derived>, "A is a base of B");

The point of this is to make it explicit in code that we’re determining whether A is the Base and B is the Derived, and not the opposite.

We now check that B is not a base class of A:

static_assert( !strong_is_base_of_v, Derived>, "B is not the base of A");

And if we accidentally mix up the arguments, by passing in the derived class first:

strong_is_base_of_v, Base>

It does not compile. What is happening is that this expression calls the primary template of strong_is_base_of_v, that has no definition.

NamedTemplate

In the above code, the two definitions of the Base and Derived templates don’t mention that they exist for the purpose of strong typing:

template struct Base{}; template struct Derived{};

Maybe it’s ok. But if we compare that to the usual definition of a strong type:

using Row = NamedType;

We see that the latter definition shows that it is a strong type. Can we have a similar definition for a strong template?

To achieve that, we can define a NamedTemplate template;

template class NamedTemplate {};

Which we can use to define our strong templates Base and Derived:

template using Base = NamedTemplate; template using Derived = NamedTemplate;

Which has the advantage of expressing that Base and Derived are “strong templates”, but also has the drawback of adding more code to figure out.

As this technique is experimental, I’m writing it as a basis for discussion rather than a finished product. So if you have an opinion on this, it’s the moment to chip in!

More specifically:

1) Do you think that the concept of strong typing makes sense in a template interface, like it does in a normal interface?

2) What do you think of the resulting code calling the strong is_base_of?

3) Do you think there is a need to express that Base and Derived are strong templates in their definition?
Don't want to miss out ? Follow:
Share this post!
The post Strong Templates appeared first on Fluent C++.

Making Strong Types Implicitly Convertible

Jonathan Boccara — Fri, 05 Jan 2018 01:00:12 +0000

Strong types and implicit conversions, doesn’t this sound like incompatible features ?

It can be argued that they are compatible, in fact. We saw why it could be useful to inherit from the underlying type’s features, and if the underlying type is implicitly convertible to something then you might want to inherit that feature too for your strong type.

In fact, NamedType user Jan Koniarik expressed on Twitter a need for exactly this feature for the NamedType library. I think the need is interesting, and some aspects of the implementation are worth considering too; which is why I’m sharing this with you today.

This article is part of the series on strong types:

Strongly typed constructors

Strong types for strong interfaces

Passing strong types by reference

Strong lambdas: strong typing over generic types

Good news: strong types are (mostly) free in C++

Inheriting functionalities from the underlying type

Making strong types hashable

Converting strong units to one another

Metaclasses, the Ultimate Answer to Strong Typing in C++?

Making strong types implicitly convertible

Adding an ImplicitlyConvertibleTo skill

The functionalities inherited from the underlying type, also named “Skills” in the NamedType library, are grouped into separate classes using the CRTP pattern. For example, to reuse the operator+ of the underlying type the Addable skill looks like this:

template struct Addable : crtp { T operator+(T const& other) const { return T(this->underlying().get() + other.get()); } };

The crtp class that this skill inherits from is a helper that gives easy access the underlying of the CRTP, that is the class that inherits from it. If you’re curious about this you can check it all out in the post on the CRTP helper.

If the type T that NamedType is strengthening is convertible, say to int, then we can implement a skills that performs an implicit conversion of the strong type to an int:

template struct ImplicitlyConvertibleToInt : crtp { operator int() const { return this->underlying().get(); } };

Fine. But int is a very specific case, our type T could be implicitly convertible to anything. It seems natural to template this class on the destination type of the conversion.

But there is a problem, this class is already a template! How can we template a class that’s already a template?

I suggest you pause for just a moment and try to think about how you would do it.

( musical interlude )

Done?

One way to go about this is to wrap this template class into another template class. This comes from a fairly common metaprogramming technique, whose naming convention is to call the inner template class “templ”. Let’s do this:

template struct ImplicitlyConvertibleTo { template struct templ : crtp { operator Destination() const { return this->underlying().get(); } }; };

Since the underlying type can have implicit conversions, I think it’s right to offer the possibility to the strong type to inherit that feature. It’s just a possibility, your strong type doesn’t have to have an ImplicitlyConvertibleTo skill even if its underlying type supports implicit conversions.

The two directions of implicit conversions

We can now use this skill in our instantiation of NamedType. Let’s test it with a type A that is convertible to B because it implements an implicit conversion operator:

struct B { }; struct A { operator B () const { return B(); } };

Then a strong type over A could keep this propriety of being convertible to B:

using StrongA = NamedType::templ>; B b = strongA; // implicit conversion here

There is another way for A to be convertible to B: if B has a constructor taking an A and that is not explicit:

struct A { }; struct B { B(A const& a){} };

The same usage of our ImplicitlyConvertibleTo skill works:

using StrongA = NamedType::templ>; B b = strongA; // another implicit conversion here

You may have noticed the ::templ in the client code. This is really annoying, and I must admit I didn’t find a way to make it disappear. I would have loved to rename the real skill something like ImplicitlyConvertibleTo_impl and declare an alias for the simpler name:

// Imaginary C++ template using ImplicitlyConvertibleTo = ImplicitlyConvertibleTo_Impl::template templ;

But there is no such thing as an alias for template templates in C++. I’m not entirely sure why, but I understand that this feature was considered by the C++ committee, but didn’t make it into the standard (yet?).

So for the moment let’s stick with the trailing ::templ in client code. If you see how to hide this, please, shout!

Not made for calling functions

At first sight, it seems that this sort of implicit conversion could be used to invoke a function that expects an underlying type by passing it a NamedType instead. Indeed, we could declare the NamedType to be implicitly convertible to its underlying type. This way we wouldn’t have to write a call to .get() every time we pass a NamedType to a function that existed before it:

using Label = NamedType::templ>; std::string toUpperCase(std::string const& s); void display(Label const& label) { std::cout << toUpperCase(label) << '\n'; }

Indeed, without this skill we need to pass the underlying type taken from the NamedType explicitly:

using Label = NamedType; std::string toUpperCase(std::string const& s); void display(Label const& label) { std::cout << toUpperCase(label.get()) << '\n'; }

Of course, this stays an opt-in, that is to say you can choose whether or not not activate this conversion feature.

However, while I this implementation can be appropriate for implicit conversions in general, it isn’t the best solution for the case of calling functions on strong types. Indeed, looking back at our implicit conversion skill, its operator was defined like this:

operator Destination() const { return this->underlying().get(); }

In the above example, Destination is std::string.

Given that this method returns an object inside the class by value, it creates a copy of it. So if we use this to call function, it means that we’ll pass copies of the underlying value as arguments to the function. This has the drawbacks of potentially making a useless copy, and to prevent the function to bind to an argument (which can be useful – std::back_inserter does it for instance).

No, ImplicitlyConvertible works for implicit conversions, but for allowing to call functions we need something different. Something which is detailed in Calling Functions and Methods on Strong Types.

Related articles:

Strongly typed constructors

What the Curiously Recurring Template Pattern can bring to your code

Strong types for strong interfaces

Passing strong types by reference

Strong lambdas: strong typing over generic types

Good news: strong types are (mostly) free in C++

Inheriting functionalities from the underlying type

Making strong types hashable

Converting strong units to one another

Metaclasses, the Ultimate Answer to Strong Typing in C++?

Don't want to miss out ? Follow:
Share this post!
The post Making Strong Types Implicitly Convertible appeared first on Fluent C++.

Using Strong Types to Return Multiple Values

Jonathan Boccara — Fri, 10 Nov 2017 01:00:47 +0000

We’ve seen how strong types helped clarifying function interfaces by being explicit about what input parameters the function expected. Now let’s examine how strong types help clarifying functions that return several outputs.

We’ll start by describing the various ways to return several outputs from a function in C++, and then see how strong types offer an interesting alternative.

Multiple return values in C++

Even though, strictly speaking, C++ doesn’t let functions return several values, some techniques to circumvent this have appeared over time. And some even made their way into becoming native features of the language.

Let’s take the example of function f that takes an Input, and we would like it to return two outputs: an output1 and an output2, which are both of type Output.

Returning a struct

This is the oldest way, but that still works the best in some cases. It consists in creating a struct, which represents a bundle of data, that contains an Output1 and an Output2:

struct Outputs { Output output1; Output output2; Outputs(Output const& output1, Output const& output2) : output1(output1), output2(output2){} };

In C++03, adding a constructor makes it syntactically easier to set its values:

Outputs f(Input const& input) { // working out the values // of output1 and output2... return Outputs(output1, output2); }

Note that in C++11 we can omit the struct‘s constructor and use extended initializer lists to fill the struct:

Outputs f(Input const& input) { // working out the values // of output1 and output2... return {output1, output2}; }

Anyway, to retrieve the outputs at call site we simply get the members out of the struct:

auto outputs = f(input); auto output1 = outputs.output1; auto output2 = outputs.output2;

Advantages of the struct:

the results coming out of the function appear with their names at call site,

exists in all versions of C++.

Drawbacks of the struct:

needs to define it (and, in C++03, its constructor) for the purpose of the function.

std::tieing to a tuple

Another way to output several values is to return a std::tuple, which can be perceived as an on-the-fly struct. So we throw away our Outputs struct, and our function becomes:

std::tuple f(Input const& input) { // working out the values // of output1 and output2... return {output1, output2}; }

At call site there are several ways to retrieve the results. One way is to use the accessors of std::tuple: the std::get template functions:

auto output = f(input); auto output1 = std::get<0>(output); auto output2 = std::get<1>(output);

But there is a problem here: we have lost track of the order of the values returned by the function.

We’re assuming that output1 comes first and output2 second, but if we get that order wrong (especially in production code where they are hopefully not called output 1 and 2) or if it comes to change, even by mistake, the compiler won’t stop us.

So we’re receiving data from a function but can’t really see that data. It’s a bit like catching a ball with your eyes closed: you need to be very, very confident towards the person who throws it at you.

This problem is mitigated if the outputs are of different types. Indeed, mixing them up would probably lead to a compilation error further down the codeline. But if they are of the same type, like in this example, there is a real risk of mixing them up.

There is another syntax for this technique, using std::tie, that is more pleasant to the eye but has the same risk of mixing up the values:

Output output1; Output output2; std::tie(output1, output2) = f(input);

std::tie creates a tuple of references bound to output1 and output2. So copying the tuple coming out of f into this tuple of references actually copies the value inside the tuple into output1 and output2.

std::tie also has the drawback of needing the outputs to be instantiated before calling the function. This can be more or less practical depending on the type of the outputs, and adds visual noise (er- actually, is there such a thing as visual noise? noise is something you’re supposed to hear isn’t it?).

Advantages of std::tie:

no need for a struct.

Drawbacks of std::tie:

the meaning of each returned value is hidden at call site,

needs to instantiate output values before calling the function,

visual noise,

needs C++11 (not everyone has it yet in production).

Structured bindings

Structured bindings are part of the spearhead of C++17 features. They have a lot in common with std::tie, except they’re easier to use in that they don’t need the outputs to be previously instantiated:

auto [output1, output2] = f(input);

Which makes for a beautiful syntax. But if the outputs are of the same type, we still have the issue of not knowing if the order of the return values is the right one!

Advantages of structured bindings:

no need for a struct

no need to instantiate output values before calling the function,

beautiful syntax

Drawbacks of structured bindings:

the meaning of each returned value is hidden at call site,

needs C++17 (really not everyone has it yet in production)

Multiple Strong return types

This need of disambiguating several return values of the same type sounds very similar to the one of clarifying the meaning of a function’s parameters, which we solved with strong types.

So let’s use strong types to add specific meaning to each of the return value of our function, by using the NamedType library:

using Output1 = NamedType; using Output2 = NamedType;

Our function can then return those strong types instead of just Outputs:

std::tuple f(Input const& input) { // working out the values // of output1 and output2... return {Output1(output1), Output2(output2)}; }

Note that the function’s prototype now shows exactly what outputs the function returns.

At call site, we get an explicit syntax thanks to an overload of std::get that takes a template type, and not a number, that works when every type inside the tuple is unique. Which is our case here, because our purpose is to differentiate every value that the function is returning, by using the type system:

auto outputs = f(input); auto output1 = std::get(outputs); auto output2 = std::get(outputs);

Advantages of strong types:

the results coming out of the function appear with their names at call site,

the function’s prototype shows the meaning of each of the returned values,

no need for a struct,

no need to initialize the outputs before calling the function.

Drawbacks of strong types:

needs to define strong types for the returned types,

not everything in one line at call site,

not standard.

Closing up on struct versus strong types

The solution using strong types has some things in common with the solution that uses structs. Indeed, both create dedicated types and allow a call site to identify each of the values returned from a function.

What’s the difference between them? I believe it lies in the function’s prototype:

With structs:

Outputs f(Input const& input);

With strong types:

std::tuple f(Input const& input);

The strong types show every returned value, while the struct has one name to designate them collectively.

Which one is better? It depends.

If there is a name that represents the concept of all that assembled data, then it makes sense to use that name with a struct, and even consider if this isn’t the opportunity to hide them in a class.

On the other hand, if the returned values are not related to each other (other than by the fact they come out of our function) it’s probably better to use strong types and avoid an awkward name to group unrelated concepts.

Also, the strong types could be arguably more reusable than the struct, as another neighbouring function that returns just a subset of them could also use their definition.

Your feedback on all this is welcome. If you want to use strong types, you’ll find the NamedType library in its GitHub repository.

Related articles:

Strongly typed constructors

Strong types for strong interfaces

Passing strong types by reference

Strong lambdas: strong typing over generic types

Good news: strong types are (mostly) free in C++

Inheriting functionalities from the underlying type

Making strong types hashable

Converting strong units to one another

Metaclasses, the Ultimate Answer to Strong Typing in C++?

Calling Functions and Methods on Strong Types

Don't want to miss out ? Follow:
Share this post!
The post Using Strong Types to Return Multiple Values appeared first on Fluent C++.

Strong types Archives - Fluent C++

Strong Types for Safe Indexing in Collections – Part 2

Using a proxy: the simple case

Handling non const, lvalue and rvalue references

The implementation

Where to put the custom code

You will also like

Strong Types for Safe Indexing in Collections – Part 1

Using the right index

A strongly indexed vector

Public inheritance

Private inheritance

Composition

A strongly indexed reference

You will also like

Strong Types on Collections

Strong typing on a collection: motivating example

Strong typing on collections

A NamedVector?

A convenient constructor of std::vector

You may also like

Getting the Benefits of Strong Typing in C++ at a Fraction of the Cost

Struct as strong type

Skills

Operator Overloading

The Inheritance Approach

The Preprocessor Approach

The Code Generator Approach

Skills for enums

Performance

Compilation time

Conclusion

Strong Types For Strong Interfaces: my talk at Meeting C++

How to Be Clear About What Your Functions Return

A use case that should not exist, but that does

Meta information

Named return types: strong return types?

Just a weak type will do here

The case where strong types are useful in return types

What’s in a expressive function’s interface?

Strong Optionals

All optionals are grey in the dark

Strong optionals

Isn’t it like Boost Outcome / std::expected?

Strong types + strong optionals

Strong Templates

Strong types for strong interfaces

Template interface

Strong templates

Usage

NamedTemplate

Making Strong Types Implicitly Convertible

Adding an ImplicitlyConvertibleTo skill

The two directions of implicit conversions

Not made for calling functions

Using Strong Types to Return Multiple Values

Multiple return values in C++

Returning a struct

std::tieing to a tuple

Structured bindings

Multiple Strong return types

Closing up on struct versus strong types

A `NamedVector`?

A convenient constructor of `std::vector`

Isn’t it like Boost Outcome / `std::expected`?

`NamedTemplate`

Adding an `ImplicitlyConvertibleTo` skill

`std::tie`ing to a tuple

Closing up on `struct` versus strong types