On Monday, 27 November 2017 at 16:44:41 UTC, Neia Neutuladh wrote:
I last used C++ professionally in 2015, and we were still
rolling out C++11. std::string_view is part of C++17. You're
calling me stupid for not having already known about it. (Yes,
yes, you were sufficiently indirect to have a fig leaf of
deniability.)
I'n not talking about you obviously. I am talking about using
languages stupidly... You could use GSL string_span or the array
version span, or write your own in 20 minutes. These are not
language constructs, but library constructs, so they dont speak
to the efficiency of the language...
An efficient text parser doesn't seem like a sufficiently
unusual task that it should require you to create your own
string type. A large swath of programs will use at least one
text parser.
C++ requires you to write basically most things from scratch or
use external libraries... What ships with it is very rudimentary.
There are many parser libraries available.
C++ is very much batteries not included... Which is good for low
level programming.
It is often useful to talk about real-world workloads when
discussing performance.
Well, in that case Java was sufficiently fast, so all languages
came out the same...
If we talk about language performance the we need use a different
approach. If we do a direct translation from lang A to B, then we
essentially give A an advantage.
So that methodology is flawed.
Assuming that your CPU can execute 20 billion instuctions per
second. That means 1 billion per 50 ms, so your budget is 1
million instructions on 400 bytes? Doesnt that suggest that the
program is far from optimal or that most of the time is spent on
something else?
Anyway benchmarking different languages isnt easy, so failing at
doing it well is usual... It is basically very difficult to do
convincingly.