Look at This Modern (C++) Sausage

So what? That is the preffered unix way to get time, along with gettimeofday() as the code indicates? That is the only way to get the time on unix, unless you have specialist hardware.

I think this guy has a massive failure in understanding how computers work, to be quite frank.

> Here we see gcc is shamelessly opening /dev/urandom, a Linux kernel facility

OK, now you are surely trolling us... you want them to implement their own entropy sources?

> std::threads is in fact, a gift-wrapped pthreads which was defined in POSIX.1c, Threads extensions (IEEE Std 1003.1c-1995).

Because that is the native API for lightweight threads in Linux... the windows impl will use the same native facilities. What giberish is this?

> Again std::thread is pthreads, wrapped. Oh you C++, can’t you do anything by yourself?

I don't even know how to express how much of a joke this article is, at the very best questionable misinformation.

That std::thread uses pthreads on posix platforms is somehow bad? The fact that I can use std::thread on both windows and linux without having to write platform specific code is great.

Old standards are all wrappers to syscalls! Eh. I think I missed a "/s" somewhere in the article.

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.

I worry what else is lurking in libc++ implementations that implies dependencies on things that aren't exactly portable...

the dependence on /dev/urandom as an absolute path is the most jarring to me.