6 ms·

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 abou

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.

sifoobar 8y ago
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.
- pjmlp 8y ago
  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.
  - Koshkin 8y ago
    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.
    - pjmlp 8y ago
      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.
      - saagarjha 8y ago
        Apple supports Objective-C, which is arguably just as bad as C++.
        pjmlp 8y ago
        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/ https://swift.org/about/ "Swift is a successor to both the C and Objective-C languages." Taken from https://developer.apple.com/swift/ https://developer.apple.com/swift/
        saagarjha 8y ago
        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).
        pjmlp 8y ago
        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.
        saagarjha 8y ago
        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?
    - icholy 8y ago
      > C++ is perfectly suitable for high-level programming -- on par with Java, C# or Visual Basic. No "taming" is needed. This is completely untrue.
    - typon 8y ago
      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
  - IshKebab 8y ago
    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.
    - pjmlp 8y ago
      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.
      - IshKebab 8y ago
        That's just because Java and C# (or whatever) are fast languages. C++ is only a little faster. Try it with Python or Ruby.
        pjmlp 8y ago
        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.
  - sifoobar 8y ago
    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 https://gitlab.com/sifoo/snigl
- longcommonname 8y ago
  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.
rightbyte 8y ago
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.
gumby 8y ago
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.
- ncmncm 8y ago
  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. N
  - gumby 8y ago
    I’ll send you a note.

sifoobar 8y ago

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.

pjmlp 8y ago
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.
- Koshkin 8y ago
  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.
  - pjmlp 8y ago
    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.
    - saagarjha 8y ago
      Apple supports Objective-C, which is arguably just as bad as C++.
      - pjmlp 8y ago
        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/ https://swift.org/about/ "Swift is a successor to both the C and Objective-C languages." Taken from https://developer.apple.com/swift/ https://developer.apple.com/swift/
        saagarjha 8y ago
        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).
        pjmlp 8y ago
        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.
        saagarjha 8y ago
        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?
  - icholy 8y ago
    > C++ is perfectly suitable for high-level programming -- on par with Java, C# or Visual Basic. No "taming" is needed. This is completely untrue.
  - typon 8y ago
    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
- IshKebab 8y ago
  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.
  - pjmlp 8y ago
    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.
    - IshKebab 8y ago
      That's just because Java and C# (or whatever) are fast languages. C++ is only a little faster. Try it with Python or Ruby.
      - pjmlp 8y ago
        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.
- sifoobar 8y ago
  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 https://gitlab.com/sifoo/snigl
longcommonname 8y ago
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.

rightbyte 8y ago

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.

gumby 8y ago

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.

ncmncm 8y ago
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. N
- gumby 8y ago
  I’ll send you a note.