Notes IV

[Jason House]

Robert Fraser wrote:

> Jason House wrote:
>> I've never been all that happy with the fixed size thing...  I think
>> sizes should be compiler-dependent unless the user is explicit about what
>> they want.  That gives the compiler room for optimization on whatever the
>> hardware happens to be.  I'd actually like to see "int" be variable
>> length and have stuff like int8, int16, int32, int64 have set sizes.  In
>> my mind, it has the added benefit of making code that uses them more
>> readable as requiring a fixed size.
> 
> Ewww no! That's why there's #defines at the top of every big C program
> to ensure the sizes match up. 

> Will there be an overflow here on one 
> processor but not on another? 

If exact overflow behavior is needed, then the developer should require an
exact size.  If overflow behavior is some kind of exceptional corner case
well beyond the range that the code is designed for (some min int size), it
should not matter.

What about size_t and ptr_diff?

> How should this value be serialized? 

That's certainly a fair issue!  

> These  
> are the sort of questions I don't want to have to deal with.
> Furthermore, that would make pointer arithmetic and inline assembly,
> among other low-level things, harder.

Isn't inline assembly platform-specific anyway?

I guess it just seems strange to me to force potentially inefficient code
generation on non-32-bit machines in order to save headache.  My gut says
that this works well for the current dominance of 32-bit machines likely
won't grow with future computer architecture changes.