3 ms·

Provided that by "extremely well" you mean being able to give up control over allocations, making it easier to spew vectors, and worse, maps, all around the pla

Provided that by "extremely well" you mean being able to give up control over allocations, making it easier to spew vectors, and worse, maps, all around the place. I think it was ryg who said on twitter that these abstractions are not really "zero cost". C++ abstractions get you in a mindset that might be detrimental to performance. > The problem with the “write like C” approach is that it forces you to write low-level code No, you have to think in what order to do things. Yes, you have to write low-level code, but not all the time. Ideally you write the low-level code in one place and the high-level code in another place. If you do allocations in your high-level code (which is admittedly what you see in many code bases), you are doing it wrong. (speaking of separation of concerns, for example). This has ramifications on maintainability as well as performance. I'm currently writing a little game engine, where I explore an architecture where these things are neatly separated out. (coincidentally, most allocation is done at compilation time, and much "code" is done by the linker). There is of course still a place for script-style code that lacks an elaborate architecture. And I guess C++ is the right choice to do that if you need "tight loop performance" or need to interface with C code.

klmr 9y ago
> C++ abstractions get you in a mindset that might be detrimental to performance. That certainly depends on the application but having been involved with several high-performance libraries written in C++, I can say confidently that C++ abstractions are largely beneficial. For instance, you can often control and avoid memory allocations (but see below): in particular, if you write algorithms interfaces in the style of the standard library, your code will perform very few, if any, unnecessary allocations, and yet be fairly high-level. > Yes, you have to write low-level code, but not all the time. I was talking specifically in the context of writing low-level C-like code, as discussed by my parent comment. You wouldn’t write “high-level C code” outside of C, there’s no need. > If you do allocations in your high-level code you are doing it wrong. As a blanket statement, I don’t agree with this in C++. If you’re careful you can perform (even dynamic!) allocations in C++. Just make sure that you dispatch to a pool allocator. But of course I agree that this requires care, and lots of code should avoid them.
- jstimpfle 9y ago
  > I was talking specifically in the context of writing low-level C-like code, as discussed by my parent comment. You wouldn’t write “high-level C code” outside of C, there’s no need. Not sure about that - if you want performance you might need to stick to the C way anyway, so maybe you can't take advantage of programming in a scripting language. I've heard of some cases where game programmers ported their game logic back from their script language to C/C++. > For instance, you can often control and avoid memory allocations (but see below): in particular, if you write algorithms interfaces in the style of the standard library, your code will perform very few, if any, unnecessary allocations, and yet be fairly high-level. Another problem with that approach is binary compatibility. Let's take the infamous std::string as an example (not even a templated class). The implementation is much more likely to change than e.g. const char pointer plus optional length, since also memory management and whatnot is needed. If the implementation changes you are in trouble everywhere, including most of the places where a pointer and size would have been just fine (because no allocation is needed there). That just happened to a coworker who now needs to setup a another system and build new binaries on it to support a customer's "old" platform (Ubuntu 14.04)

klmr 9y ago

> C++ abstractions get you in a mindset that might be detrimental to performance. That certainly depends on the application but having been involved with several high-performance libraries written in C++, I can say confidently that C++ abstractions are largely beneficial. For instance, you can often control and avoid memory allocations (but see below): in particular, if you write algorithms interfaces in the style of the standard library, your code will perform very few, if any, unnecessary allocations, and yet be fairly high-level. > Yes, you have to write low-level code, but not all the time. I was talking specifically in the context of writing low-level C-like code, as discussed by my parent comment. You wouldn’t write “high-level C code” outside of C, there’s no need. > If you do allocations in your high-level code you are doing it wrong. As a blanket statement, I don’t agree with this in C++. If you’re careful you can perform (even dynamic!) allocations in C++. Just make sure that you dispatch to a pool allocator. But of course I agree that this requires care, and lots of code should avoid them.

jstimpfle 9y ago
> I was talking specifically in the context of writing low-level C-like code, as discussed by my parent comment. You wouldn’t write “high-level C code” outside of C, there’s no need. Not sure about that - if you want performance you might need to stick to the C way anyway, so maybe you can't take advantage of programming in a scripting language. I've heard of some cases where game programmers ported their game logic back from their script language to C/C++. > For instance, you can often control and avoid memory allocations (but see below): in particular, if you write algorithms interfaces in the style of the standard library, your code will perform very few, if any, unnecessary allocations, and yet be fairly high-level. Another problem with that approach is binary compatibility. Let's take the infamous std::string as an example (not even a templated class). The implementation is much more likely to change than e.g. const char pointer plus optional length, since also memory management and whatnot is needed. If the implementation changes you are in trouble everywhere, including most of the places where a pointer and size would have been just fine (because no allocation is needed there). That just happened to a coworker who now needs to setup a another system and build new binaries on it to support a customer's "old" platform (Ubuntu 14.04)