Tag: C++

Adventures in returning value-dependent type

krzaq 1 Comment

A few nights ago a friend asked me if I had any idea how to make his magic macro work. The general idea behind it was simple: for strings known at the compile time, return type parametrized on the string hash; otherwise return a runtime type. He even provided the type trait he uses to determine if we’re dealing with a string literal. It works well for his case and its potential wrongness is not the point of this article.

Code

The point was something else: let us define a macro NAME and classes Const<size_t> and Runtime, such that the following is valid code:

std::string runtime;
std::cin >> runtime;
 
auto c = NAME("KrzaQ");
auto r = NAME(runtime);
 
// 9546715638267443724UL is fnv1a64("KrzaQ");
static_assert(std::is_same<decltype(c), Const<9546715638267443724UL>>{});
static_assert(std::is_same<decltype(r), Runtime<std::string>>{});

Always willing to help, I sat down to show him how the C++20 solution would like, then how to do a simple tag-dispatch, and to see if the macro could be replaced with a function call.

Or so I thought.

Proper digit separators in C++

krzaq 5 Comments

Have you ever hoped that C++ would have digit separators? That you wouldn’t have to strain your eyes when reading 2147483647 (is it std::numeric_limits<int32_t>::max(), or is it just similar)? That you wouldn’t have to count the zeros 5 times when typing 1000000000?

Well, the C++ Standards Committee doesn’t have your back. Oh, sure, they have introduced a digit separator, – ‘, but it’s completely unusable in production code! Here’s why.

Code doodles #5 – quite surprising parse

krzaq 2 Comments

I came upon a similar piece of code during an IRC discussion. While I am certain that some may consider this example trivial, I admit that the correct answer eluded me even after I verified the result with the compiler – it wasn’t until I checked the standard that it became clear.

Consider the following class:

struct foo
{
    foo()
    {
        cout << __PRETTY_FUNCTION__ << endl;
    }
 
    foo(int)
    {
        cout << __PRETTY_FUNCTION__ << endl;
    }
};

And now, consider the following code:

int global;
int main()
{
    foo();
    foo(42);
    foo(global);
}

Would you care to guess what will be printed?

You don’t need a stateful deleter in your unique_ptr (usually)

krzaq 4 Comments

With the increasing probability of your average project using at least C++11, std::unique_ptr is one of the most popular solutions1 to dynamically managing memory in C++.

It usually goes like this: if your object can’t be a scoped object, that is one with automatic lifetime (colloquially: on the stack, or a class’s member), wrap it in std::unique_ptr. This will ensure it’s freed when it finally goes out of scope. Herb Sutter goes more in-depth into this topic in his last C++Con talk:

Herb Sutter: Leak-Freedom in C++… By Default.

This advice is sound and deserves being spread.