--- In [email protected], "peternilsson42" <peternilsso...@...> wrote: > > I have used 8MB implementations where int was still only > 16-bit. I dare say there are some embedded environments > where this is still the case.
Yep. > You could argue that size_t may have performance issues > because it is often wider than int. But I've yet to encounter > an implementation where the performance actually warranted > a smaller/faster type. > > True, on some systems wider types can be fractionally slower, > but you're not likely to encounter an implementation where > size_t is particularly slow. All true, but sometimes when you've got real-time constraints and you've optimised everything else, you're left with 2 choices, neither of them particularly pleasant: 1. Do stuff like use 8 bit counters instead of 16 bit counters (and rearrange the order of fields in structures, don't always make logically static functions physically static, avoid post-increment, etc.). 2. Code it in assembler. Having said that, in the environment I work in (gcc-based front end with proprietary CPU), sometimes 16 bits are faster than 8 bits.
