In article <drabgr$uae$1@digitaldaemon.com>, Deewiant says...
>And the result can be assigned to Speed, because that's also an integer. But it makes no physical sense to apply Volume to Speed. Did I misunderstand or did you just describe the alias keyword?

imho you should just use a plain old "int". I see no reason to have a billion different typedefs all for different units. Yes its OO, but to me it just looks like unnecessary abstraction. I mean the chances of messing up density = mass/volume are too slim in my opinion to be worth the extra effort (I'm having trouble thinking up more complex examples that are really so desparately in need of compile time arithmetic checking that its worth creating a huge hierarchy of variants on int)

"Ben Phillips" <Ben_member@pathlink.com> wrote in message news:drc0v4$la$1@digitaldaemon.com...
> In article <drabgr$uae$1@digitaldaemon.com>, Deewiant says...
>>And the result can be assigned to Speed, because that's also an integer.
>>But it
>>makes no physical sense to apply Volume to Speed. Did I misunderstand or
>>did you
>>just describe the alias keyword?
>
> imho you should just use a plain old "int". I see no reason to have a
> billion
> different typedefs all for different units. Yes its OO, but to me it just
> looks
> like unnecessary abstraction. I mean the chances of messing up density =
> mass/volume are too slim in my opinion to be worth the extra effort (I'm
> having
> trouble thinking up more complex examples that are really so desparately
> in need
> of compile time arithmetic checking that its worth creating a huge
> hierarchy of
> variants on int)

My friend, you have no idea how many problems are caused by units miscalculations.  All the smart people at NASA can't even get it right! That's why features that provide safety for the programmer such as bounds checking and garbage collection are so popular.  If we can provide more safe units conversion utilities it will definitely be worth the effort.  However, I do believe that the approach that he proposes is not the right approach. Again, for a good example of a C++ library that already tackles this problem, see SIUnits.

-Craig

Craig Black wrote:
> "BCS" <BCS_member@pathlink.com> wrote in message news:drbgor$21oo$1@digitaldaemon.com...
>> I have sketched some template code to see what it would take to do prity mutch exactly what you all are talking about. I thin that all that would be needed is implicet specilization of a function and allowing the return type of sutch a function to be determoned by the type of it's aruments.

<snip>

>> this has been brought up a number of times and I would rely like to see this kind of capacity added to D.
> 
> I agree.  This would be a worthwhile addition to D's template capabilities. Why do you think Oskar suggested that assignment operator overloading would be required?

I apologize for that statement. It was made too hasty. Assignment operator overloading would not be necessary for a pure dimensional library that only does compile time checking of dimensional correctness. Assignment overloading would only affect a runtime behavior that in this case is meant to remain unchanged.

For a library that deals with units on the other hand, assignment overloading would probably be necessary to handle conversions between different units / unit prefixes.

---
Off Topic, regarding assignment overloading:

I do not propose that assignment overloading should be implemented for classes. Classes are after all reference types. Structs, on the other hand, are value based and assigning one struct to another means today that a memcpy is being made. Assignment of structs is already a potentially expensive operation. Making this user definable makes sense.  This would among other things make it possible to create an efficient BigInt-like type that would behave as a primitive type. Ideally, structs should also have the possibility of defining a destructor that gets called when it goes out of scope. This would allow the implementation of ref-counted data and more. I.e. the following should work:

	T a,b;
	a = 17;
	b = a;
	a++;
	assert(a != b);

for a custom type T, without the implementation of a++ needing to do defensive .dup-ing of the contained data. (For a BigInt, a++ is on average a very inexpensive operation but is unfortunately impossible to implement like that if the data may be shared and you have no way of knowing.)

/Oskar