2009/2/27 Jonathan S. Shapiro <[email protected]>: > Yes. Unfortunately this solution won't scale. There are a depressing > number of types like this in the world. size_t, off_t, ssize_t, > off64_t...
Agreed, I didn't consider that they would be hard to implement. And yes, size_t should act like all other *_t types in order to follow the principle of least surprise. Even the primitive C types may very well be just aliases; they're used only in special circumstances, anyway. The important thing is that BitC itself has "portability-safe" types. In short, it would seem to me that 1) and 2) are about equally good choices. 2009/2/27 Jonathan S. Shapiro <[email protected]>: > Quite the contrary. It is the C approach that hinders portability, > because whenever the representable range actually matters there isn't > any good choice. BitC has instead followed the approach taken by Java, > C#, and other more recent languages in this regard. The only > difference between BitC int32 and Java int is that we put the size > into the type name. Yes, I can see the underlying philosophy, and it suits systems programming well. Excellent explanation, thank you. I'm not yet entirely convinced that C wouldn't be more portable - or portably performant - in extreme cases, but it is certainly simpler to achieve portability the Java way. Personally I've always found good choices in C's repertoire of integer types and typedefs, and I still believe that abstractions for fast integer types may be required to achieve maximum performance on multiple architectures, but this applies only to a very limited set of applications. * Mapping C types to BitC exact-width types portably may be cumbersome due to their mismatch. The C integer converts to what? Theoretically bignum is the only portable solution, unless there are additional assumptions or checks for machines with unexpectedly high/small integer range. Of course, in practice, the number of different possible target architectures is very limited. However, it's important that the programmer can achieve true portability without thinking about it too much. "What if the C function can't handle int32 as input on a 16-bit machine? On a 64-bit machine, could it return an integer that is greater than int32? If it could, should I use int64, bignum or just keep the c_int?" I guess there's no easy way around binding decisions like these, but at some point someone must make a choice, whether it is the user or the developer of the C interface. Aleksi Nurmi _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
