intermediate

Design Patterns Revisited—Bob Nystrom

Walk through (with practical examples) a handful of the original patterns the Gang of Four documented in C++.

Design Patterns Revisited

Design Patterns: Elements of Reusable Object-Oriented Software is nearly twenty years old by my watch. Unless you’re looking over my shoulder, there’s a good chance Design Patterns will be old enough to drink by the time you read this. For an industry as quickly moving as software, that’s practically ancient. The enduring popularity of the book says something about how timeless design is compared to many frameworks and methodologies.

While I think Design Patterns is still relevant, we’ve learned a lot in the past couple of decades. In this section, we’ll walk through a handful of the original patterns the Gang of Four documented. For each pattern, I hope to have something useful or interesting to say.

I think some patterns are overused (Singleton), while others are underappreciated (Command). A couple are in here because I want to explore their relevance specifically to games (Flyweight and Observer). Finally, sometimes I just think it’s fun to see how patterns are enmeshed in the larger field of programming (Prototype and State).

Anti-IF idioms in C++—Marco Arena

I'm showing interactive examples of "anti-IF" idioms in C++, inspired by C# snippets which Claudio Pattarello proposed at the Italian Agile Day 2014.

Anti-IF idioms in C++

by Marco Arena

From the article:

In this post I’d like to show you how to rewrite these idioms in C++, starting from a C# snippet. And the resulting code is pretty much identical. [...] I'm not saying "this is the best thing you can do in C++". [...] Sure, we have specific idioms in our favorite language but I think it’s lovely that we are able to reuse the same code from other languages with a little effort. And this is also appealing for other programmers who want to experience C++, maybe by starting coding idioms they know. ...

Where will Evolution lead C++17?

The third part of my series about the proposals for Urbana is about the subgroup evolution:

Where will Evolution lead C++17?

by Jens Weller

From the article:

This is the third part in my series about the proposals for the current C++ committee meeting in Urbana. This time its all about the subgroup Evolution, which has the most papers, so this is only the first part. The previous parts were about concurrency, and Part 2 about core, networking, models and undefined behavior.

Looking for C++17 - Urbana Proposals for Core, Modules, Networking, Reflection and UB

The second part of my series on the C++ Proposals for the next Committee meeting in Urbana:

Looking for C++17 - Urbana Proposals for Core, Modules, Networking, Reflection and UB

by Jens Weller

From the Article:

The second part of my series about the proposals for Urbana, where the next C++ committee meeting will be held. The papers grand us a first view on a distant future - C++17...

C++ and Zombies: a moving question

One of the issues I was thinking about since C++Now: move and move-destruction

C++ and Zombies: a moving question

by Jens Weller

From the article:

This has been on my things to think about since C++Now. At C++Now, I realized, that we've might got zombies in the C++ standard. And that there are two fractions, one of them stating, that it is ok to have well defined zombies, while some people think that you'd better kill them.

Urbana Proposals - C++17 insight?

I've started with my series on the proposals for the next C++ Committee Meeting:

Urbana Proposals - C++17 insight?

by Jens Weller

From the article:

A short series to give you an overview over the Papers submitted in the latest mailing for the C++ Committee Meeting in Urbana-Champaign in Illinois. At the beginning of November the C++ Committee will have its 3rd Meeting this year. As C++14 is now finished, the focus is clearly on the upcoming C++17 standard.

Quick Q: Should I prefer non-member std::begin and std::end?—StackOverflow

Quick A: Yes.

A classic on SO, just re-asked yesterday:

When to use std::begin and std::end instead of container specific versions

Are there any general preferences or rules that explain when container specific versions of begin and end should be used instead of free functions std::begin and std::end?

It is my understanding that if the function is a template whereby the container type is a template parameter then std::begin and std::end should be used, i.e.:

template<class T> void do_stuff( const T& t )
{
    std::for_each( std::begin(t), std::end(t), /* some stuff */ );
}

What about in other scenarios such as a standard / member function where the type of container is known? Is it still better practice to use std::begin(cont) and std::end(cont) or should the container's member functions cont.begin() and cont.end() be preferred?

Am I correct in assuming that there is no benefit in performance by calling cont.end() over std::end(cont)?

Insights into new and C++

I've written down some basic thinking on new and new standards:

Insights into new and C++

by Jens Weller

From the article:

Every now and then, I've been thinking about this. So this blogpost is also a summary of my thoughts on this topic, dynamic memory allocation and C++. Since I wrote the blog entries on smart pointers, and C++14 giving us make_unique, raw new and delete seem to disappear from C++ in our future code...

Variadic Templates—Feabhas

variadic-templates.PNGRecently on StickyBits, a nice primer on variadics:

Variadic Templates

by feabhas

From the article:

In this article we’re going to look at a new feature of templates in C++11 -- the concept of the variadic template.

Variadic templates allow us to create functions and classes, not only with generic types, but also a variable number of generic types.

If you haven’t been following along with the template articles, I’d suggest you read this article first before continuing.

Quick Q: Can computing the length of a C string really be compile-time constexpr?—StackOverflow

Quick A: Yes, when the string being traversed is itself a constant expression, such as a string literal.

Recently on StackOverflow:

Computing length of a C string at compile time. Is this really a constexpr?

I'm trying to compute the length of a string literal at compile time. To do so I'm using following code:

#include <cstdio>

int constexpr length(const char* str)
{
    return *str ? 1 + length(str + 1) : 0;
}

int main()
{
    printf("%d %d", length("abcd"), length("abcdefgh"));
}

Everything works as expected, the program prints 4 and 8. The assembly code generated by clang shows that the results are computed at compile time:

0x100000f5e:  leaq   0x35(%rip), %rdi          ; "%d %d"
0x100000f65:  movl   $0x4, %esi
0x100000f6a:  movl   $0x8, %edx
0x100000f6f:  xorl   %eax, %eax
0x100000f71:  callq  0x100000f7a               ; symbol stub for: printf

My question: is it guaranteed by the standard that length function will be evaluated compile time?

If this is true the door for compile time string literals computations just opened for me... for example I can compute hashes at compile time and many more...