
Look at This Modern (C++) Sausage - KAHFrookie
http://www.vitorian.com/x1/archives/393
======
easytiger
_> Surprise! It is calling clock_gettime(), which has been in the libc since
SUSv2, POSIX.1-2001. On clang 3.9.0/src/chrono.cpp it looks like a straight
copy of it:_

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.

~~~
clishem
Exactly my thoughts. These are not meant as better new implementations but as
high-level abstractions.

------
blt
I don't get why the author is surprised that the c++ stdlib calls into the
libc to get the current time, or opens /dev/urandom to seed the PRNG on unix,
or uses pthreads. It seems that the author doesn't understand the relationship
between language libraries/runtimes and operating systems.

~~~
krona
Exactly! the stdlib is just doing the _least surprising thing_ , which is
exactly what it should be doing.

------
SamReidHughes
Iostreams? A mere wrapper around the POSIX functionality of read(2) and
write(2). Get it together, C++!

~~~
AstralStorm
Not quite, it handles locales too.

------
overgard
So basically, the standard library is implemented.. exactly as youd expect it
to be.

------
biglionking
I'm not sure what the author is complaining about to be honest. Does he not
understand the difference between a language and its implementation?

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.

------
prashnts
> I want to show the new standards are all wrappers. Some lazy wrappers, some
> better implemented.

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

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

------
frahs
All these things are exactly what's I'd do 99% of the time with the underlying
calls, and I'm glad c++11 does them for me. It's like... Well duh, this is
exactly the concept of abstraction.

------
imode
wow. that's incredible.

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.

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

You _do_ realize that the C++ runtime library is always a system or compiler
supplied non-portable library?

Just like the C library is also highly non-portable. It uses system-specific
syscalls _all over the place_.

