Live data from Hacker News

Orthodox C++ (2016)

bkaradzic.github.io

31–40 of 238 posts

Re: Orthodox C++ (2016)

#31
I've been doing embedded systems in C++ since rocks were young, and this is a great summary of what to avoid.

I would sure love a good coroutine runtime, and first-class support for defer. You can do these manually, but language/toolchain/debugger support is nice to have.

(Pragmatically, I will be retired by the time they would be useful)

Re: Orthodox C++ (2016)

#32
post #7

I've developed a style that I legitimately call Heterodox C++ (mainly due to the popularity of Orthodox C++), it is effectively a purely functional & metaprogramming heavy style of C++. Quite the opposite of this, not everyones cup of tea, and it won't fit into every codebase but it is incredibly powerful. The template metaprogramming C++ offers is the most powerful of any imperative language, and (subjective opinion…

The problem with metaprogramming-heavy C++ codebases is always compilation times and obtuse error messages...

Template metaprogramming is sometimes very useful to get around C++'s language restrictions, but I tend to use it sparingly.

Re: Orthodox C++ (2016)

#33
Nothing surprising here. People who view C++ as just a better C always outnumbered those who view it as another language.

That's exactly how democratic governments make their decisions… you might think it's stupid, and you'd be right, but that's democracy. It's the majority that counts, not what's right. At least you can have a little fun with their arguments, they're pretty inventive you know.

Re: Orthodox C++ (2016)

#34
post #31

I've been doing embedded systems in C++ since rocks were young, and this is a great summary of what to avoid. I would sure love a good coroutine runtime, and first-class support for defer. You can do these manually, but language/toolchain/debugger support is nice to have. (Pragmatically, I will be retired by the time they would be useful)

A defer is just a dozen lines of code nowadays, if you really need it, but in most cases you don't if you're doing RAII

Re: Orthodox C++ (2016)

#35
Man, all of the confusion and gnashing of teeth in the C++ world really makes me grateful for my job. Smaller company, I solo develop a central module on the product stack, and I was able to evaluate languages for the project.

Nim became the obvious choice, and I wasn't a fanboy before. Simple semantics, in a very functional style oriented around data's value. References and identity have to be trapdoored. Everything is single-owner unique lifetimes by default, no annotations or best-practices required. You end up writing extraordinarily functional/procedural code that produces very fast and memory-safe binaries, it fits right into C++'s niche.

The only objection I could steel man was that the standard library and most packages are composed of relatively pure functions that return new values, so allocations are happening there. But when types as complex as data frames can be semantically used as just values, and you know they have scoped lifetimes by default, the benefits are obvious.

With all of C++'s insanely specific, subtle, implicit, compiler- and platform-dependent behaviors, I've often wondered when the industry will finally consider its dominance an artifact of first-mover inertia and simply move on. There are vastly better ways to do all of the things it does, while easily exposing levers for the the things it's considered to do exceptionally well.

Re: Orthodox C++ (2016)

#37

Orthodox C++, to me, is C plus the one good feature of C++: you don't have to type struct all the time.

How about one of the C unorthodoxies that use typedef everywhere? (Namespaces seem suitable, too.)

Re: Orthodox C++ (2016)

#38
post #37

Orthodox C++, to me, is C plus the one good feature of C++: you don't have to type struct all the time.

How about one of the C unorthodoxies that use typedef everywhere? (Namespaces seem suitable, too.)

typedef is a little bit of a hassle but you can do it, even in a very strict mechanical way if writing plain C. But it's a hassle.

And namespaces suck too, so much noise for little gain. You know what, a big part of programming is naming. You just have to come up with good names. Namespaces don't magically make names better, if anything, they make them worse. And they add a lot of syntax noise.

Re: Orthodox C++ (2016)

#39

If you're in a market that requires using C++, many of these decisions are made for you by the platform above you, and you're screwed. Turn on RTTI, build a fort to deflect the random exceptions they'll throw at you, and may the gods allow you to recoup your R&D before some well-intentioned yokel in some media or game vertical changes everything and requires you to change everything. On the other hand, if you control…

> build a fort to deflect the random exceptions they'll throw at you Sounds like you hate exceptions, right? In which case why do you handle them at all? Just leave them all unhandled and suddenly every exception is a crash. Which is really no different from someone choosing to terminate. Which you have to worry about even without exceptions. > if you have a C++ code base yet somehow have enough time and energy to wr…

[flagged]

Re: Orthodox C++ (2016)

#40

You can take for (auto const & ess : esses) { ... } from my cold dead hands. Also, you can fight me if you want to take dynamic_cast (base_ptr) and force me to implement my own typing system every time I need to upcast. Basically, stick with C and leave C++ programmers alone. I haven't seen a less useful article about C++ in a long time, and as an HN reader, that's really saying something.

Implementing STL iterators are a bloody PITA
Post reply on HN