Hacker News Reader

Comment by longcommonname | Hacker News Reader

As someone who is on a personal journey to transition from c with classes thinking to modern c++ I can see why there's so much hate from non-cpp developers about how these features look ugly.

But, as a developer, who has dealt with an absurd amount of bugs that can be prevented from these modern c++ features I really like this.

View on HN

I went the other way, started writing C++ in 95 and digging into C properly around 2005.

Just make sure that the cure isn't worse than the disease. It's all to easy to slip into identifying with C++ because of the substantial effort it takes to master.

Should you, like me and many others; eventually find yourself spending more time and effort on taming C++, don't hesitate to let go. It's a tool.

The solution is easy, managed languages for 90% of the code and C++ for the remaining no-excuses full throtle execution speed, while offering reasonable safety for arrays, strings, out parameters, enumerations, lifetimes.

Not everyone is running Solaris on an ADI enabled SPARC.

I have a somewhat different perspective to offer: C or C++ for components (effectively 90% of all code), a managed or scripted code (10%) for the glue.

The reason is that the modern C++ is perfectly suitable for high-level programming -- on par with Java, C# or Visual Basic. No "taming" is needed.

Taming is necessary, because regardless of what you and me think about modern C++, there is a large crowd that still writes C with C++ compiler with total disregard for any kind of security validation tools.

So the only way to prevent such security exploits is by preventing copy-paste compatibility with C, which C++ sadly cannot do without breaking backwards compatibility.

You can see this happening across all desktop and mobile oriented OSes, where both C and C++ have been reduced to high performace low level OS layers, with userspace migrating to something else.

Microsoft is the only vendor left on OSes for the consumer space that still cares enough to support C++ on their UI toolkits.

Apple supports Objective-C, which is arguably just as bad as C++.

It does, due to its NeXTSTEP legacy, but the roadmap is quite clear.

"Swift is intended as a replacement for C-based languages (C, C++, and Objective-C)."

Taken from https://swift.org/about/

"Swift is a successor to both the C and Objective-C languages."

Taken from https://developer.apple.com/swift/

I would be very surprised if Apple’s frameworks ended up becoming Swift-only any time in the next decade. While Swift is the spiritual sucessor to Objective-C, there is far too much Objective-C already written that would be costly to obsolete, even if Swift had the facilities to do everything Objective-C can (and, as I’m sure you’re aware, it is not at that point yet).

Sure, but that will eventually happen, even if they do just a couple of components per OS release.

Launchd, dock were announced as rewritten at WWDC 2017, the new XCode build system and instrumentation at WWDC 2018, and it will continue little by little.

Naturally it won't happen overnight, but Apple isn't known to endure Python 2/3 scenarios for that long.

Those are not frameworks, those are apps that ship as part of the system. Apple has not and seemingly will not deprecate Objective-C for third party developers. They haven’t even rewritten any significant code in Swift, IIRC. Maybe parts of launchd?

Timac analysed several MacOS and iOS versions for swift usage, and its growing through the system surprisingly rapidly for a language awaiting a stable ABI. Here’s the most recent analysis, which also links to others: https://blog.timac.org/2018/0924-state-of-swift-ios12/

Yup, I’ve read those and that’s what I based my statement on. Apple doesn’t seem to have rewritten any code in Swift “just for the sake of it”; they have slowly introduced it the in places they could to add new features.

They need to start somewhere.

At WWDC 2017 they mentioned that launchd was fully ported. The video is available.

> C++ is perfectly suitable for high-level programming -- on par with Java, C# or Visual Basic. No "taming" is needed.

This is completely untrue.

This is the "right" approach - speaking from experience after having tried both ways (10-90 vs 90-10). The general structure is that your application is built as a DAG with the nodes representing C++ functions (not methods on classes), with edges representing arbitrary datastructures (not objects), with the graph being constructed and hooked up in python and executed using a library like TBB

This just doesn't work for making fast software in my experience. It's very rare that 90% of your execution time is in 10% of your code because that code is obvious low hanging fruit and will have already been optimised.

Selective optimisation of hot code will always lead to execution time being spread evenly through your code.

My experience replacing software 100% written in C++ by a mix of JVM/.NET + C++ shows otherwise.

Most of the time, the C++ help isn't even necessary anymore, unless the systems were doing some GPGPU stuff, real time audio or high performance graphics.

That's just because Java and C# (or whatever) are fast languages. C++ is only a little faster. Try it with Python or Ruby.

From my point of view Python and Ruby are only worthy of shell scripts, and scenarios where performance isn't even part of the requirements list.

Using them in scenarios where performance matters is the typical everything looks like a nail.

Feel free to disagree, my experience during the early 2000 with Tcl has taught me to never use languages without native support for JIT/AOT toolchains ever again when performance matters.

Anything related to distributed computing, performance does matter.

I prefer embedding scripting languages [0] in C. Which is another path to the same kind of compromise, with the added advantage of controlling the world for the scripting language.

[0] https://gitlab.com/sifoo/snigl

I work in both C and C++ code bases so I get to dive deep into both sets. Only find solutions and language idioms when an actual problem arises.

I'm just thinking what are all these letters on my screen. The first code example in the blogpost look like Javascript callback chains.

These new right left-values, special rightvalues etc make my head hurt. Template programming makes my head hurt. I can't look into fancy cpp code and understand it anymore.

I'm wondering have new programmers are supposed to catch up too all the things in cpp even now and the mountain is getting ever bigger.

in early 2017 we started a project in c++17 (the compilers we cared about, g++ and clang++, by that time supported basically all of C++17 and everything in the library we needed except std::variant). It was a "start with an empty emacs buffer" project so we could start straight there.

The trick was to treat it as a brand new language that happened to have some resemblances to other languages some of us already knew (i.e. C, C++, etc). C++17 is actually a pretty expressive language and pretty fun to program in.

I recognize most people don't have this luxury. Interfacing to the small number of external packages we used involved making modern "cutout" connections to the legacy packages, which actually was worthwhile.

Hi Gumby --

K. was just asking how your new project has gone.

Reading the post, I thought, "hey, that sounds like Gumby", and then looked at the byline.

I am running C++ on an Arduino now, and prepping to teach my son to run it on a Blyst Nano. He wants to make his own smart watch. He will end up doing a lot of very educational yak-shaving on the way.

Hope to see you again sometime soon.

I’ll send you a note.

Reply on news.ycombinator.com