5 ms·

The problem with C++ is that in addition to generic functionality, it also brings a ton of other baggage that even if you do not use, you still pay for (e.g. pe

by Crinus 7y ago

The problem with C++ is that in addition to generic functionality, it also brings a ton of other baggage that even if you do not use, you still pay for (e.g. personally i really dislike how slow C++ compilers are). Though TBH i wouldn't use OP's preprocessor either as i think that void* and macros are perfectly fine.

klingonopera 7y ago
Exceptions being one of the notable pieces of baggage...
- Crinus 7y ago
  Yeah, though i'm not sure if exceptions really slow down compilation and in some compilers you can disable them anyway. Also you can redefine new to return null on failure, though if you are going to use new, delete, etc might as well bite the bullet and use the entire language anyway (and instead of redefining new, use a template that does the allocation and initialization based on some common convention and a macro that causes an error whenever new is used since you can ensure no exceptions will be thrown... at least from new - but IMO a better way is to just stick with C and avoid the tarpit that is C++).
  - klingonopera 7y ago
    ...my compile times rarely take more than a minute, so I can't really relate to that, but exceptions will slow down execution and add an overhead to the binary's file-size.
    - wvenable 7y ago
      Exceptions don't generally slow down execution -- they usually have zero runtime cost if they're not thrown making them better than error returns for performance. However, the exchange is, as you said, that they do add a lot of overhead to the file-size.
      - klingonopera 7y ago
        Regarding error handling, I agree with this author[0], and find the C-based approach much better than C++'s try/throw/catch methods. Regarding execution times, I don't know from first-hand experience, I did some research and found this[1]. The third sentence in that reply ("The error code is not sensitive to the percentage of occurrence") is AFAIK wrong (because of speculative execution, I believe?), but the rest seems quite solid. [0]: http://250bpm.com/blog:4 http://250bpm.com/blog:4 [1]: https://stackoverflow.com/a/52513707 https://stackoverflow.com/a/52513707
      - vardump 7y ago
        Something that generates extra code that ends up in the instruction cache during execution is not zero cost. There's cost to transfer it through memory and cache hierarchies and there's cost when it causes the CPU to drop some other L1C cache line.
        gpderetta 7y ago
        Well, if the exception is not thrown, no code related to the exceptional path goes into the instruction cache (not even checking for exception propagation). Assuming of course a non-completely dumb compiler that puts exceptional path code and unwinds tables in separate pages than hot code.
        vardump 7y ago
        True. I think I'll test whether use of exceptions can affect optimizations concerning register allocation and spilling, like function prologues and epilogues. Unwinding will also need to call destructors, and for that you'll need to have the object pointer somewhere in (stack frame) memory. But it might be in just a register. Unless, of course, the unwinding engine can look into registers as well. I guess it's not a huge deal either way, especially in 32-bit x86 code. For large register file systems it might be a different story, forcing otherwise unnecessary spills. Regardless, I'll find out when I got some time. Anyways, my point was more generic. So-called zero-cost abstractions are my pet peeve, because they're often not zero cost precisely because of larger generated code size. Typical microbenchmarks don't capture this, because their hot path can usually fit comfortably in L1 code and data caches.
    - Crinus 7y ago
      Heh, this reminds me of the Abrash quote about optimization mentioned a few days ago (from his black book): > We're so used to slow software that when a compile-and-link sequence that took two minutes on a PC takes just ten seconds on a 486 computer, we're ecstatic—when in truth we should be settling for nothing less than instantaneous response. (from https://github.com/jagregory/abrash-black-book/blob/master/src/chapter-01.md https://github.com/jagregory/abrash-black-book/blob/master/s...) Personally i'm annoyed when my compile times take more than a few seconds :-P
wvenable 7y ago
One of the reasons C++ is so complicated is that you don't pay for the features that you don't use. If you wanted generics in C, you can easily use C++ without any of those other features (baggage, if you will) and not pay for it. Heck, you could define a few macros and make it impossible to use any baggage features you don't like. I've used C++ in a pretty tight embedded environment and it was great.
- Crinus 7y ago
  You may not pay for them (generally) in terms of execution time, but you pay for them in terms of compilation time and language complexity.
  - wvenable 7y ago
    If I don't use them then language complexity doesn't matter. Compilation times might be a factor assuming that turning them off doesn't also decrease that (which it might).
- bsder 7y ago
  > I've used C++ in a pretty tight embedded environment and it was great. I'd love to hear some details. I'm always looking for C++ stories that didn't end in disaster and what the people did that worked.
  - com2kid 7y ago
    I've done similar. The Microsoft Band UI was written in C++. No templates or other advanced features, compiler was stuck on 2003 standard. We had templates but used the trick of implementing them in a .cpp file and declaring all the instanciations of them we'd ever use at the bottom of the same file. Had to write our own to guarantee 0 allocs. It is quite do-able. Lots of static declarations, basically write C with classes. V-tables ended up being non-trivial in size, but what can you do, GUIs and all that. Possibly the best (only?) good use of inheritance hierarchies. 256KB memory, the UI only had 60KB or so available for it IIRC. We also had a scratch pad available over a super slow bus of a couple megs, but it couldn't be used too much or we'd drop frames and we loved our 30fps v-sync'd performance.

by Crinus 7y ago

klingonopera 7y ago

Exceptions being one of the notable pieces of baggage...

Crinus 7y ago
Yeah, though i'm not sure if exceptions really slow down compilation and in some compilers you can disable them anyway. Also you can redefine new to return null on failure, though if you are going to use new, delete, etc might as well bite the bullet and use the entire language anyway (and instead of redefining new, use a template that does the allocation and initialization based on some common convention and a macro that causes an error whenever new is used since you can ensure no exceptions will be thrown... at least from new - but IMO a better way is to just stick with C and avoid the tarpit that is C++).
- klingonopera 7y ago
  ...my compile times rarely take more than a minute, so I can't really relate to that, but exceptions will slow down execution and add an overhead to the binary's file-size.
  - wvenable 7y ago
    Exceptions don't generally slow down execution -- they usually have zero runtime cost if they're not thrown making them better than error returns for performance. However, the exchange is, as you said, that they do add a lot of overhead to the file-size.
    - klingonopera 7y ago
      Regarding error handling, I agree with this author[0], and find the C-based approach much better than C++'s try/throw/catch methods. Regarding execution times, I don't know from first-hand experience, I did some research and found this[1]. The third sentence in that reply ("The error code is not sensitive to the percentage of occurrence") is AFAIK wrong (because of speculative execution, I believe?), but the rest seems quite solid. [0]: http://250bpm.com/blog:4 http://250bpm.com/blog:4 [1]: https://stackoverflow.com/a/52513707 https://stackoverflow.com/a/52513707
    - vardump 7y ago
      Something that generates extra code that ends up in the instruction cache during execution is not zero cost. There's cost to transfer it through memory and cache hierarchies and there's cost when it causes the CPU to drop some other L1C cache line.
      - gpderetta 7y ago
        Well, if the exception is not thrown, no code related to the exceptional path goes into the instruction cache (not even checking for exception propagation). Assuming of course a non-completely dumb compiler that puts exceptional path code and unwinds tables in separate pages than hot code.
        vardump 7y ago
        True. I think I'll test whether use of exceptions can affect optimizations concerning register allocation and spilling, like function prologues and epilogues. Unwinding will also need to call destructors, and for that you'll need to have the object pointer somewhere in (stack frame) memory. But it might be in just a register. Unless, of course, the unwinding engine can look into registers as well. I guess it's not a huge deal either way, especially in 32-bit x86 code. For large register file systems it might be a different story, forcing otherwise unnecessary spills. Regardless, I'll find out when I got some time. Anyways, my point was more generic. So-called zero-cost abstractions are my pet peeve, because they're often not zero cost precisely because of larger generated code size. Typical microbenchmarks don't capture this, because their hot path can usually fit comfortably in L1 code and data caches.
  - Crinus 7y ago
    Heh, this reminds me of the Abrash quote about optimization mentioned a few days ago (from his black book): > We're so used to slow software that when a compile-and-link sequence that took two minutes on a PC takes just ten seconds on a 486 computer, we're ecstatic—when in truth we should be settling for nothing less than instantaneous response. (from https://github.com/jagregory/abrash-black-book/blob/master/src/chapter-01.md https://github.com/jagregory/abrash-black-book/blob/master/s...) Personally i'm annoyed when my compile times take more than a few seconds :-P

wvenable 7y ago

One of the reasons C++ is so complicated is that you don't pay for the features that you don't use. If you wanted generics in C, you can easily use C++ without any of those other features (baggage, if you will) and not pay for it. Heck, you could define a few macros and make it impossible to use any baggage features you don't like. I've used C++ in a pretty tight embedded environment and it was great.

Crinus 7y ago
You may not pay for them (generally) in terms of execution time, but you pay for them in terms of compilation time and language complexity.
- wvenable 7y ago
  If I don't use them then language complexity doesn't matter. Compilation times might be a factor assuming that turning them off doesn't also decrease that (which it might).
bsder 7y ago
> I've used C++ in a pretty tight embedded environment and it was great. I'd love to hear some details. I'm always looking for C++ stories that didn't end in disaster and what the people did that worked.
- com2kid 7y ago
  I've done similar. The Microsoft Band UI was written in C++. No templates or other advanced features, compiler was stuck on 2003 standard. We had templates but used the trick of implementing them in a .cpp file and declaring all the instanciations of them we'd ever use at the bottom of the same file. Had to write our own to guarantee 0 allocs. It is quite do-able. Lots of static declarations, basically write C with classes. V-tables ended up being non-trivial in size, but what can you do, GUIs and all that. Possibly the best (only?) good use of inheritance hierarchies. 256KB memory, the UI only had 60KB or so available for it IIRC. We also had a scratch pad available over a super slow bus of a couple megs, but it couldn't be used too much or we'd drop frames and we loved our 30fps v-sync'd performance.