On Monday, 27 November 2017 at 17:35:53 UTC, Ola Fosheim Grostad wrote:
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 can ask your local HR representative how much better it is to say "your ideas are stupid" than "you are stupid".

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

Only for people who are happy to eschew the standard library, which pretty much just includes C++ users.

C++ is very much batteries not included... Which is good for low level programming.

So you're saying that having a body of well tested code that does what you want already but *might* be making performance tradeoffs that don't work for your use case, is *worse* than not having it.

Well, it's a heterodox opinion to be sure.

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

You might try reading my first post.

Java: 140ms to print "Hello world"

D: 50ms to turn a 400kb subtex document into an epub

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?

Again, you might try reading my first post. In it, I mentioned memory a lot, since allocating memory is relatively slow. I specifically called it out as the reason that the C# version of subtex was so slow. And allocating memory isn't slow simply because it requires executing a large number of instructions.

Reply via email to