Articles & Books

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...

Quick Q: Why can I return a unique_ptr by value? -- StackOverflow

Quick A: Because return local_obj; automatically treats it as an rvalue. After all, you won't be using it any more.

When this FAQ came up again recently on SO, the answer was to refer to this previous Q&A:

Returning unique_ptr from functions

unique_ptr<T> does not allow copy construction, instead it supports move semantics. Yet, I can return a unique_ptr<T> from a function and assign the returned value to a variable...

unique_ptr<int> foo()
{
  unique_ptr<int> p( new int(10) );

  return p;                   // 1
  //return move( p );         // 2
}

The code above compiles and works as intended. So how is it that line 1 doesn't invoke the copy constructor and result in compiler errors? If I had to use line 2 instead it'd make sense (using line 2 works as well, but we're not required to do so)....

Destructors: Two Use Cases -- Andrzej KrzemieĊ„ski

Freshly pressed from Andrzej:

Destructors: Two Use Cases

by Andrzej Krzemieński

From the article:

In this post I want to describe an interesting observation: programmers generally use destructors for two purposes. One is fairly obvious: releasing resources; the other — not necessarily so...

Exceptions, error codes, and assertions in C++ -- Joseph Mansfield

mansfield.pngOne reasoned take on the various error reporting mechanisms in C++ and a policy for deciding when each is appropriate:

Exceptions, error codes, and assertions in C++

by Joseph Mansfield

From the article:

It can often be difficult to decide between the various methods of error reporting in C++. For example, some common advice is that exceptions should only be thrown in exceptional circumstances. Needless to say, this isn't particularly helpful. What exactly is an exceptional circumstance? An exception to what? If we throw assertions into the mix, this can become even more complicated.

In general, functions express a contract to the calling code...

First community planning session was a full success

Yesterday I held the first planning session for local C++ communities at the #meetingcpp chat at freenode.My plan is to make this a monthly online meeting, where new user groups can be planned and existing user groups can exchange and connect.

First community planning session was a full success

by Jens Weller

From the article:

Yesterday I held the first planning session for local C++ communities at the #meetingcpp chat at freenode.My plan is to make this a monthly online meeting, where new user groups can be planned and existing user groups can exchange and connect. As this was the first time, and I just returned from CppCon, so I only could announce it a day before. Yet it was a good start, especially the contact to the brazilian C++ User Group is great to have.

Trip Report: My Trip to CppCon -- Jens Weller

From the organizer of Meeting C++:

My Trip to CppCon

by Jens Weller

From the article:

I just returned yesterday from my trip to Bellevue/WA for CppCon. Its been 10 awesome days, and a ton of fun. It was an honor to support this idea from day one as a community sponsor. I already posted some images of CppCon 2014 at facebook and G+.

... And then from Monday till Friday there was the awesome content. I had often a hard time to choose which talk to see next, as with 6 Tracks there often was a scheduling conflict. All the keynotes delivered good content and Mike Acton really gave us something to talk about. One of the highlights in the talks was for me the talk about using boost fusion for wire protocols, ...

Marking as Deprecated in C++14 -- Joseph Mansfield

Now that C++14 is preparing for publication, get the details on the new [[deprecated]] attribute.

Marking as Deprecated in C++14

by Joseph Mansfield

From the article:

It is common for entities in source code (functions, classes, etc.) to become obsolete or unsafe as a project undergoes development. It's usually a bad idea to remove those entities without any warning, as it'll break any code that interfaces with those entities. Instead, a good practice is to mark them as deprecated in an attempt to discourage their use.

The upcoming C++ release, C++14, introduces the deprecated attribute for specifying that an entity is deprecated.

Embedding Lisp in C++: A Recipe -- Chris Kohlhepp

Look at this image again: That's C++ in Lisp. And that's just for starters...

Embedding Lisp in C++ -- A Recipe

by Chris Kohlhepp

As a teaser, consider this from midway through the article:

Just to recap, so far we have seen C++ calling in-line Lisp; Lisp calling C++; a Lisp REPL inside of a C++ process; a full symbolic Lisp debugger inside of C++; byte compiled and interpreted mode of execution; as well as trivial Live-Programming.

We are yet to see full integration with Lisp’s package management system and fully compiled Lisp code inside of C++...

When Size Does Matter -- K-Ballo

Recently on Tales of C++:

When Size Does Matter

by K-ballo

In the C++ lands every object has mass; for any complete type T, sizeof(T) is greater than zero. This keeps array indexing and pointer arithmetics from collapsing, but it also means that empty objects occupy space. Furthermore, when an empty object is placed in a class next to a bigger member, padding may — and in all likeliness will — be added due to alignment requirements, resulting in an empty member taking more than just one byte of storage.

Certainly something has to be done about this...