Implicit conversions considered harmful.

Okay, this might be a little harsh:

Potentially dangerous and/or expensive implicit conversions considered harmful.

Better.

Implicit conversions will happen “accidentally” by their very nature, so if they happen, they should always do the right thing.

And how to prevent implicit conversions? Simple: use an explicit constructor.

But that’s only half of the problem: What about assignment? Is there explicit assignment? If so, when do I use it?

C++11 introduced move semantics. With it, you can encode transfer of ownership and allow to put types in a container where you can’t copy them.

This clearly is powerful.

But the current move system isn’t perfect, there are a couple of issues. There is an arguably cleaner approach: destructive move.

In this post we’ll explore a purely theoretical alternative C++ with destructive move.

A discussion on Twitter got me thinking about operator precedence. It is a crucial part of most programming languages as it dictates the meaning of expressions.

Interestingly enough, it is practically the same in almost all programming languages, even ones that radical try to be a better alternative for an established language. So apparently operator precedence is a solved problem, right?

Well, I don’t think so. I think operator precedence is fundamentally flawed and could easily be improved.

Sometimes you’re lazy. You know you need to do something, but don’t want to do it yet. You don’t need to do it right now, only at some later point. And maybe later it turns out that you don’t need to do the entire work, just a part of it or nothing at all! So if you’re eager and do it right now, you might do more work than needed.

The same applies to your code. Sometimes you do things even though it is not necessary. You call a function passing it some arguments that were expensive to calculate and then the function don’t need all of them due to some other arguments. Wouldn’t it be great to only calculate the arguments when they are actually needed?

This is called lazy evaluation of function arguments and this blog post presents how it can be done in C++.

How many member functions does std::string have?

As of C++17 the answer is 153, assuming I counted correctly.

One Hundred Fifty Three.

That is a lot. And as Herb Sutter has pointed out, most of those members could easily be implemented as non-members without loss of performance.

And they should be implemented as nonmembers according to an old guideline from the C++ coding standards: Prefer nonmember, nonfriends. Write free functions whenever possible, not members.

But how true is that advice really?