C++ fun strange facts

The title might be a little bit misleading because, on one hand, you might not find these things funny if you are stumbling upon them and not understanding what is going on, and, on the other hand, they are not really strange when you pay attention to what is going on. However, here is a list of five (randomly picked) C++ features that would probably get you giving a second thought to what’s going on.

Aggregate initialization

Consider the following structure:

struct foo
{
   foo() {}
};

You can write the following:

foo f1;
foo f2{};
foo f3[5];

But should you delete the default constructor as follows:

struct foo
{
   foo() = delete;
};

Then you can still intialize objects of this type but only using brace initialization (foo{}):

foo f1;     // error: attempting to reference a deleted function
foo f2{};
foo f3[5];  // error: attempting to reference a deleted function

foo f; is no longer legal because foo does not have a default constructor anymore. However, foo f{}; is still legal because classes with deleted default constructors can be list initialized via aggregate initialization but not value initialization. For more info see 1578. Value-initialization of aggregates.

Alternative function syntax gotchas

Alternative function syntax refers to putting the type of the return value of a function at the end after the function type, as in auto foo() noexcept -> int. However, it doesn’t always go as smooth as that. Let’s consider the the following base class:

struct B
{
   virtual int foo() const noexcept;
};

How do you write an overriden foo() in a derived class using the trailing return type (aka alternative function syntax)? If you’re tempted to do it like this then you’re wrong.

struct D : B 
{
   virtual auto foo() const noexcept override -> int;
};

This will generate a compiler error (which differes depending on your compiler). The reason is that override is not part of the function type, so it has to be written after the function type. In other words, the correct syntax is as follows:

struct D : B 
{
   virtual auto foo() const noexcept -> int override;
};

For more pros and cons on using the alternative function syntax see this article.

rvalue references and type deduction

rvalue references are specified with && but in type declaration && could mean either rvalue reference of universal reference. The latter one is not a term you can find in the C++ standard but rather one coined by Scott Meyers. It refers to a reference that can be either lvalue or rvalue. However, when you’re using && as parameter in function (templates) the meaning of && depends on whether type deduction is involved or not; if type deduction is involved, then it is an universal reference; otherwise, it is an rvalue reference. Here are some examples:

void foo(int&&);              // rvalue reference

template <typename T>
void foo(T&&);                // universal reference

template <typename T>
void foo(T const &&);         // rvalue reference;

template <typename T>
void foo(std::vector<T>&&);   // rvalue reference

struct bar
{
   template <typename T>
   void foo(T&&);             // universal reference
};

template <typename T>
struct bar
{
   void foo(T&&);             // rvalue reference
};

template <typename T>
struct bar
{
   template <typename U>
   void foo(U&&);             // universal reference
};

When you see something like T&& that means universal reference; however, if anything else is involved, like a const qualifier, such as in const T&&, then you have an rvalue reference. Also, if you have a std::vector<T>&& then you’re dealing with an rvalue reference. In this case, foo exists within the context of std::vector<T>, which means T is already known and does not have to be deduced.

There is actually a long article about this topic by Scott Meyers called Universal References in C++11. You should read it for a detailed look at the differences and caveats of rvalue and universal references.

std::array is not an array

Consider the following snippet:

int main()
{
   std::cout << std::is_array_v<int[5]> << std::endl;
   std::cout << std::is_array_v<std::array<int, 5>> << std::endl;
}

What do you expect this to print? Well, the answer is 1 and 0. If you’re surprised, then remember std::array is not an array, but a standard fixed-length container that has the same semantics as a struct holding a C-style array T[N] as its only non-static data member. And, unlike a C-like array, it doesn’t decay to T* automatically. On the other hand, std::is_array is conceptually defined as follows:

template<class T>
struct is_array : std::false_type {};
 
template<class T>
struct is_array<T[]> : std::true_type {};
 
template<class T, std::size_t N>
struct is_array<T[N]> : std::true_type {};

And that is why std::is_array<std::array<T, N>> is std::false_type.

Indexing arrays

I have to admit I only saw this a couple of times in my whole life, and although I don’t remember exactly where, it was problably some obfuscate code. The following is valid code:

int arr[5]{ 1,2,3,4,5 };
1[arr] = 42;

This changes the second element of arr (at index 1) from 2 to 42. 1[arr] is equivalent to arr[1], which in turn is an alternative syntax for *(arr + 1). Therefore, generally speaking, a[n] and n[a] are equivalent because the compiler would transform that expression in either *(a + n) or *(n + a), which are equivalent. Therefore, all of these are valid and equivalent:

int arr[5]{ 1,2,3,4,5 };

arr[1] = 42;
1[arr] = 42;
*(arr + 1) = 42;

I think it could be possible for the compiler to differentiate and make constructs such as 1[arr] illegal, but then again nobody actually indexes arrays like that, so I suppose it was never an issue.