Chris Cannam <[EMAIL PROTECTED]> wrote: > > Actually, the best example I can think of is int vs unsigned int! You may > get "stronger type checking" from using unsigned int, but it isn't strong > enough -- you can still assign between these types, creating often very > subtle bugs. Add to that the tendency to use an unsigned in contexts where > it subsequently becomes convenient to have a special value like -1 to > indicate "none of the above", and the ingrained habit (of mine, and I'm sure > of many other programmers) of making loop counters for things like array > indices plain ints, and you end up with a situation in which the code would > almost certainly be better, more reliable, and more easily maintained if > there were no unsigneds in it at all. > > This is a tradeoff of principle (it's an unsigned value, let's force it to > be unsigned) against pragmatism (our programmers will refer to it as signed > anyway, or want to store magic negative numbers in it). The fact that in > principle something may lead to better code does not necessarily mean that > in practice it will, unless you have a good way of enforcing that principle > in reality -- which unsigned lacks. > > Another example in the audio world is libraries that use their own special > names for floating-point types. JACK has jack_sample_t, which is a float. > LADSPA has LADSPA_Data, which is a float. These were almost certainly > introduced "just in case" anyone wanted to change them later or port to a > platform on which a float was a different size without changing the size > of the library's data type. The fact that these types have different names > means you can't in principle use the same variables and buffers for LADSPA > and JACK audio data. In practice, because that would be a big inconvenience, > programmers everywhere cast them to floats all the time and reuse their > buffers all over the place. Some plugins even assert(sizeof(LADSPA_Data) > == sizeof(float))! The advantage of having a new type is lost, and it would > be clearer and easier in the long run to simply use floats.
What you are arguing is essentially that because a subset of programmers have deeply ingrained habits of using signed int for quantities that are intrinsically unsigned, and of using negative values in signed types as condition signals, they either do or would find it too difficult to work with unsigned types correctly and efficiently. I would say that is a weak reason to justify bad habits; there is light at the end of the tunnel of bad habits but one cannot see it is there, let alone reach it without making some effort to get there. I know there is a different subset of programmers who, through their willingness to explore the idea of using maximally specific types, have realised significant practical benefits in reliability and maintainability, particularly in respect of preventing - rather than curing - bugs and security problems, without sacrificing productivity. Your second example concerning the use of special names for existing types in some libraries is not relevant to my point regarding overly general types because a simple renaming does not cause any change in generality of the type. William ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
