4 ms·

C++ is used in environments where every byte and cycle counts, regardless of your personal experience, run-time meta data (and going via lookup tables) does hav

by sorbits 15y ago

C++ is used in environments where every byte and cycle counts, regardless of your personal experience, run-time meta data (and going via lookup tables) does have a big measurable overhead that many prefer to avoid. Adding to that, the things a C++ compiler can do at compile time (via static typing and full knowledge of the types) is pretty convenient and impressive, relying on these things to be done at run-time is often complex and/or require more code to be written by the programmer.

leon_ 15y ago
In an environment where every byte and cycle counts I'd be using C. C++ has too much stuff going on behind the scenes. (Like hidden object copies, potentially bloated operators, etc.). If you can live with enabled exception handling (which is a performance toll) then some additional object meta data shouldn't be a problem.
- copper 15y ago
  > C++ has too much stuff going on behind the scenes. (Like hidden object copies, potentially bloated operators, etc.). The thing is, C++ is usually good about not charging you for features you don't use - and with the reasonably good debugging and profiling tools, most of the problems you mention above are fixable to get performance that is close (or equal) to C, with maybe better maintainability. To pick a not-so-random example of something that's difficult to implement in C as safely as in C++, see expression templates[1]. I'd be interested in something similar to what eigen does written in C. (Of course, the last time I did this minibenchmark, so-and-so's lapack library was still slightly faster than eigen :) The bottom-line, perhaps, is that if I'm writing a library, I'd do it in C simply because it's self-contained and has a nicely limited scope, and as a bonus is usable from oh-so-many other languages. If I'm writing an application that really, really requires serious performance, I'd prefer to use C++. [1] http://en.wikipedia.org/wiki/Expression_templates http://en.wikipedia.org/wiki/Expression_templates
- SamReidHughes 15y ago
  It's very easy to avoid at least the problems you've mentioned by not making copyable objects and not defining bloated operators.
  - leon_ 15y ago
    > not defining bloated operators Can you guarantee that for every 3rd party lib you use?
    - SamReidHughes 15y ago
      Who cares about theoretical possibilities? The reality is that hidden object copies and bloated operators are not a real problem.
    - dkersten 15y ago
      Then only use the ones that do guarantee this. You can also make use of C libraries, but still have access to some nice C++ features for your code. Since C++ lets you omit language features until you basically have plain C, you get to choose what level of support you can live with.

by sorbits 15y ago

leon_ 15y ago

In an environment where every byte and cycle counts I'd be using C. C++ has too much stuff going on behind the scenes. (Like hidden object copies, potentially bloated operators, etc.). If you can live with enabled exception handling (which is a performance toll) then some additional object meta data shouldn't be a problem.

copper 15y ago
> C++ has too much stuff going on behind the scenes. (Like hidden object copies, potentially bloated operators, etc.). The thing is, C++ is usually good about not charging you for features you don't use - and with the reasonably good debugging and profiling tools, most of the problems you mention above are fixable to get performance that is close (or equal) to C, with maybe better maintainability. To pick a not-so-random example of something that's difficult to implement in C as safely as in C++, see expression templates[1]. I'd be interested in something similar to what eigen does written in C. (Of course, the last time I did this minibenchmark, so-and-so's lapack library was still slightly faster than eigen :) The bottom-line, perhaps, is that if I'm writing a library, I'd do it in C simply because it's self-contained and has a nicely limited scope, and as a bonus is usable from oh-so-many other languages. If I'm writing an application that really, really requires serious performance, I'd prefer to use C++. [1] http://en.wikipedia.org/wiki/Expression_templates http://en.wikipedia.org/wiki/Expression_templates
SamReidHughes 15y ago
It's very easy to avoid at least the problems you've mentioned by not making copyable objects and not defining bloated operators.
- leon_ 15y ago
  > not defining bloated operators Can you guarantee that for every 3rd party lib you use?
  - SamReidHughes 15y ago
    Who cares about theoretical possibilities? The reality is that hidden object copies and bloated operators are not a real problem.
  - dkersten 15y ago
    Then only use the ones that do guarantee this. You can also make use of C libraries, but still have access to some nice C++ features for your code. Since C++ lets you omit language features until you basically have plain C, you get to choose what level of support you can live with.