5 ms·

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

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.

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.