By my reading, the author is not making the point that all of the commenters here think that xe is making. They think that xe is making some point about how su

By my reading, the author is not making the point that all of the commenters here think that xe is making. They think that xe is making some point about how surprising these implementations are. Reading the article, it appears however that the author's actual point is that the new library features don't give programs anything more than they already had, because pretty much everything is a fairly thin wrapper over an already standard API, like clock_getttime(), that conformant programs can just call. In other words: it's not about surprising implementation; it's not about portability; it's about gain and optimization. Are the new APIs providing any useful gain to programs beyond calling the already-standard library functions that they wrap? Do compilers truly optimize the extra layers entirely out? Is the need for generics that handle all cases preventing the ability to have optimal implementations for common cases? Consider the std::to_string(int) called out there. It marshals everything through the API for snprintf(), parameterizing the as_string() template on the snprintf() format string, running in that loop, and calling all of that code in snprintf() that decodes the string "%d" and constructs and then processes a varargs just to get a single int at the end. None of that gets optimized out. But this is standard library implementation code. One could write std::to_string(int) in terms of the internal magic of the C part of the standard library, which "knows" the maximum possible decimal representation of an int and has internal functions to convert an int to a decimal string that snprintf() ends up calling, once it has done all of the format string parsing and finally worked out that the task at hand is converting one int X using base 10 into buffer B. In the BSD library, for example, one could cut out the middle man and just call straight into __ultoa() with a std::string resized (just once) to size BUF (as defined in libc/stdio/xprintf_int.c). By my reading, the author is making the point that the implementations are poor quality in practice, introducing a whole load of extra layering inside a single standard library, and asking as a consequence what then is the gain of these new layers over just using the already standard APIs that they are in practice simply layered on top of.