On Friday 15 Jul 2005 11:35, William wrote: > Guillaume Laurent wrote: > > Yes, but in practice they are very close to one another. > > 1=> The point is, > > > strongly enforcing the distinction between two types which are, > > in essence, very close (like a char and a int, or an int and an > > unsigned int) isn't always good. The only thing Stephen's UInt > > property brings is a somewhat stronger type checking at > > compile-time. > > 2=> My point is that it's just not worth it. > > 1 and 2 are new, unrelated points.
I didn't mean to get into this, because it's consuming a lot of email bandwidth for something I don't think is terribly important, but I'll pop up for long enough to say that I'm inclined to agree with Guillaume that an arbitrary distinction between two types that in practice might as well be interchangeable is not always helpful, as well as to agree with you that char vs int is not a good example. 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. 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
