On Friday 15 Jul 2005 14:06, William wrote: > 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.
Yes! That's certainly part of what I'm arguing -- if a coding practice only works when used by perfect programmers, then it's not a very good practice. Note that I wouldn't be making that argument if the language itself prohibited assigning between signed and unsigned int without some extra work (as with const, the use of which I strongly support). The other part of it (which may have been Guillaume's main point) is that often the distinction is not important anyway. Does it matter if a particular number is never less than zero? Does it matter if it is never less than one? Does it matter if it's always less than ten? Should that be encoded in the type? Sometimes it does matter, and it might be good if it were; sometimes it's just coincidence. In this case, sure, there can't be a fret number -1. There can't be a fret number 4294967295 either, but that's still within the range of the unsigned type. Decrement int(0) and you get -1; decrement unsigned(0) and you get 4294967295, with no opportunity for a compiler warning. Why care about one but not the other? Is the distinction actually important? > 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. That reasoning is bogus -- you can only say that because you know (because I just told you) that LADSPA_Data and jack_sample_t are the same underneath. As far as the APIs are concerned, they're independent types that may have different ranges. And that's just the problem -- it would be more useful for them to be compatible (i.e. publicly the same type). Just as in many cases it's more appropriate for an integral value that may happen never to be negative to be just an int. This will be my last post in this thread. I'll read any reply, but I have nothing more to say about it and I've taken long enough over it already. Chris ------------------------------------------------------- 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
