5 ms·

I always avoid C++ exceptions, and also try to avoid dynamic memory allocations, smart pointers and RTTI etc whenever possible. This is pretty common in latency

I always avoid C++ exceptions, and also try to avoid dynamic memory allocations, smart pointers and RTTI etc whenever possible. This is pretty common in latency and (pseudo) real-time performance critical work, such as robotics control and 3d gaming.

worik 5y ago
Why do you use C++ in those domains? Curious as to the decision criteria.
- cyber_kinetist 5y ago
  If you need any sort of numerical programming, C++ is basically unmatched. It's fast and efficient (have total control over memory and heap allocations), while able to create complex math abstractions thanks to its template system and operator overloading. For example, Eigen is the only library (not in C++, but in the entire programming space) that can optimize your math expressions at compile-time. You can also perform techniques like auto-differentiation by using templates. Meanwhile, Rust still doesn't have full const generics, which are needed to create a math library that's both efficient and easy to use (nalgebra still depends on typenum, which is much uglier than even the most esoteric C++ template stuff you can find!)
  - mhh__ 5y ago
    The D library "Mir GLAS" also does the eigen style optimizations, IIRC. It's not unique to C++ but yes Eigen is by far and away the most mature option in that space. D templates are significantly better than C++ ones in basically every way, but the work is already done in C++ so I can't be too boastful
  - erwincoumans 5y ago
    Agreed. Eigen can be relatively slow: in our Tiny Differentiable Simulator, with C++ templatized code, we generate C code using CppAdCodegen (by tracing a sim step) which is easily 5 times faster than the original Eigen code. And together with openmp it runs very fast: Ant OpenAI gym simulation at 2 million steps per second on an AMD Ryzen 3900x at 12 cores/24 threads). See the (unreadable) generated code from Eigen+CppAd Codegen here: https://github.com/google-research/tiny-differentiable-simulator/blob/master/examples/environments/omp_model_ant_forward_zero.h https://github.com/google-research/tiny-differentiable-simul...
- addaon 5y ago
  I work in the same domains, plus hard embedded real-time. Some projects end up choosing C, some C++. C has the advantage of simplicity and more mature tooling, C++ has the advantage of a stronger type system (able to move some things from correct-by-testing to correct-by-construction) and a medium-weight code generation system in the form of templates.
- DoctorDabadedoo 5y ago
  Ecosystem and performance. There are other as performant languages out there that have a "small" footprint (C, Rust, Zig, etc.), but the combo with the libraries heavily used in robotics, mostly for image and mathematics computation, makes it hard to look away from it: C++ standard library, OpenCV, Eigen, Boost, PCL, ROS. There may come a day when there is enough momentum and support to look elsewhere, but right now C++ is king in this domain. There is a lot of Python going on too, but usually not for the same type of things.
- erwincoumans 5y ago
  C is fine too. I pick a C++ subset that is closer to C than to full modern C++17. Full control over memory access, hardware access and execution. I haven't learned enough Rust yet, that could be fine too, but Rust lacks still many libraries in Robotics and Game development. What else do you suggest?
  - ncmncm 5y ago
    In other words, you pick exclusively the worst features of C++, and ignore all the actually useful, helpful features that enable you to write better code. If you just want C, use C.
    - Koshkin 5y ago
      Well, with a C++ compiler there's always hope that they will pick up the good parts, eventually.
    - TillE 5y ago
      "Modern C++ bad" is such a weird HN meme, fortunately it's not an opinion I see a lot elsewhere. Old C++ was awful, the new stuff makes it actually usable. Personally I like how even in embedded code where you don't want to include the standard library, you can still efficiently use language constructs like constexpr, lambdas, etc.
      - Koshkin 5y ago
        Careful with lambdas, they are not without an overhead.
        zozbot234 5y ago
        Lambda is designed to be a zero-overhead feature. In the worst case, it's the same as passing an additional void* ctx argument to a plain old function, which is the most common pattern in C/pre-lambda C++.
        5y ago
CyberRabbi 5y ago
> (pseudo) real-time performance critical work, such as robotics control and 3d gaming. In reality all interactive applications are real-time performance critical. Any normal user would say that an unresponsive application is unacceptable. Sadly the entire stack of our contemporary desktop runtime environments grew out of background batch processing systems. This means that an application becoming unresponsive can be a sign of normal system operation. Even if you avoid malloc, any memory access can trigger swapping which can block your main thread indeterminately. Or if you are running a high enough amount of CPU-hungry processes concurrently, your main thread can block indeterminately. Millions of programmers carry on building applications for these systems blissfully unaware of these fundamental flaws. Application runtimes like Electron flourish, riddled with thousands of unbounded operations on every mouse click.
- com2kid 5y ago
  > Even if you avoid malloc, Way too many people believe the difference between malloc/new+free/delete vs a GC is that one is deterministic and the other isn't. (It doesn't help that textbooks still teach this!) Both are subject to the whims of the system's memory and, if swap is enabled, IO systems. And unless you understand your call graph very well, constructing an object that constructs other objects is not something you are likely to be capable of calculating the performance of in a non-GC language. Same goes for destructors. The actual difference is that in language without GC's typically have explicit syntax for dynamic memory allocation (though it can happen by surprise in C++ from time to time!), which means if you are writing latency sensitive code, you can just avoid dynamic allocation altogether. But there is no reason why GC languages can't do the same! In fact, newer GC languages sometimes do, and nowadays C# give you more control over stack allocation, so careful C# coding can also avoid using dynamic memory.
mhh__ 5y ago
Memory allocation is the big think that new players often miss. A lot of time I see people saying D is unusable (excitedly) for a certain usecase, and you know what if you use the GC a lot it might be, but then I then see them write code that uses raw malloc and free willy nilly. GC can bite you in the ass, but so will basically all memory allocation if you don't understand the real trends of your program i.e. "Nature is a language, can't you read?"

worik 5y ago

Why do you use C++ in those domains? Curious as to the decision criteria.

cyber_kinetist 5y ago
If you need any sort of numerical programming, C++ is basically unmatched. It's fast and efficient (have total control over memory and heap allocations), while able to create complex math abstractions thanks to its template system and operator overloading. For example, Eigen is the only library (not in C++, but in the entire programming space) that can optimize your math expressions at compile-time. You can also perform techniques like auto-differentiation by using templates. Meanwhile, Rust still doesn't have full const generics, which are needed to create a math library that's both efficient and easy to use (nalgebra still depends on typenum, which is much uglier than even the most esoteric C++ template stuff you can find!)
- mhh__ 5y ago
  The D library "Mir GLAS" also does the eigen style optimizations, IIRC. It's not unique to C++ but yes Eigen is by far and away the most mature option in that space. D templates are significantly better than C++ ones in basically every way, but the work is already done in C++ so I can't be too boastful
- erwincoumans 5y ago
  Agreed. Eigen can be relatively slow: in our Tiny Differentiable Simulator, with C++ templatized code, we generate C code using CppAdCodegen (by tracing a sim step) which is easily 5 times faster than the original Eigen code. And together with openmp it runs very fast: Ant OpenAI gym simulation at 2 million steps per second on an AMD Ryzen 3900x at 12 cores/24 threads). See the (unreadable) generated code from Eigen+CppAd Codegen here: https://github.com/google-research/tiny-differentiable-simulator/blob/master/examples/environments/omp_model_ant_forward_zero.h https://github.com/google-research/tiny-differentiable-simul...
addaon 5y ago
I work in the same domains, plus hard embedded real-time. Some projects end up choosing C, some C++. C has the advantage of simplicity and more mature tooling, C++ has the advantage of a stronger type system (able to move some things from correct-by-testing to correct-by-construction) and a medium-weight code generation system in the form of templates.
DoctorDabadedoo 5y ago
Ecosystem and performance. There are other as performant languages out there that have a "small" footprint (C, Rust, Zig, etc.), but the combo with the libraries heavily used in robotics, mostly for image and mathematics computation, makes it hard to look away from it: C++ standard library, OpenCV, Eigen, Boost, PCL, ROS. There may come a day when there is enough momentum and support to look elsewhere, but right now C++ is king in this domain. There is a lot of Python going on too, but usually not for the same type of things.
erwincoumans 5y ago
C is fine too. I pick a C++ subset that is closer to C than to full modern C++17. Full control over memory access, hardware access and execution. I haven't learned enough Rust yet, that could be fine too, but Rust lacks still many libraries in Robotics and Game development. What else do you suggest?
- ncmncm 5y ago
  In other words, you pick exclusively the worst features of C++, and ignore all the actually useful, helpful features that enable you to write better code. If you just want C, use C.
  - Koshkin 5y ago
    Well, with a C++ compiler there's always hope that they will pick up the good parts, eventually.
  - TillE 5y ago
    "Modern C++ bad" is such a weird HN meme, fortunately it's not an opinion I see a lot elsewhere. Old C++ was awful, the new stuff makes it actually usable. Personally I like how even in embedded code where you don't want to include the standard library, you can still efficiently use language constructs like constexpr, lambdas, etc.
    - Koshkin 5y ago
      Careful with lambdas, they are not without an overhead.
      - zozbot234 5y ago
        Lambda is designed to be a zero-overhead feature. In the worst case, it's the same as passing an additional void* ctx argument to a plain old function, which is the most common pattern in C/pre-lambda C++.
        5y ago

CyberRabbi 5y ago

> (pseudo) real-time performance critical work, such as robotics control and 3d gaming. In reality all interactive applications are real-time performance critical. Any normal user would say that an unresponsive application is unacceptable. Sadly the entire stack of our contemporary desktop runtime environments grew out of background batch processing systems. This means that an application becoming unresponsive can be a sign of normal system operation. Even if you avoid malloc, any memory access can trigger swapping which can block your main thread indeterminately. Or if you are running a high enough amount of CPU-hungry processes concurrently, your main thread can block indeterminately. Millions of programmers carry on building applications for these systems blissfully unaware of these fundamental flaws. Application runtimes like Electron flourish, riddled with thousands of unbounded operations on every mouse click.

com2kid 5y ago
> Even if you avoid malloc, Way too many people believe the difference between malloc/new+free/delete vs a GC is that one is deterministic and the other isn't. (It doesn't help that textbooks still teach this!) Both are subject to the whims of the system's memory and, if swap is enabled, IO systems. And unless you understand your call graph very well, constructing an object that constructs other objects is not something you are likely to be capable of calculating the performance of in a non-GC language. Same goes for destructors. The actual difference is that in language without GC's typically have explicit syntax for dynamic memory allocation (though it can happen by surprise in C++ from time to time!), which means if you are writing latency sensitive code, you can just avoid dynamic allocation altogether. But there is no reason why GC languages can't do the same! In fact, newer GC languages sometimes do, and nowadays C# give you more control over stack allocation, so careful C# coding can also avoid using dynamic memory.

mhh__ 5y ago

Memory allocation is the big think that new players often miss. A lot of time I see people saying D is unusable (excitedly) for a certain usecase, and you know what if you use the GC a lot it might be, but then I then see them write code that uses raw malloc and free willy nilly. GC can bite you in the ass, but so will basically all memory allocation if you don't understand the real trends of your program i.e. "Nature is a language, can't you read?"