From: Oleg Abrosimov (beholder_at_[hidden])
Date: 2006-06-17 12:21:21
Andy Little wrote:
> "Oleg Abrosimov" wrote
>> 1) Can anyone provide a really useful example of quantities with units
>> encoded? I mean all these "length::m" things in PQS. There were requests
>> to disable it and reduce to simple "length" and treat with units only in
>> I/O with help of manipulators. Note that historical units can be handled
>> in the same way:
>> length l;
>> cin >> l; // in meters by default
>> cout << hyst_unit_manip << l;
> The genesis of PQS was the need in my own work to remember which unit a floating
> point variable was expressed in.
> In this particular application the user had various data entry boxes where the
> entry unit was millimeters. In my internal calculations I had to convert these
> lengths to meters. Again I had to convert them back for output. I found I spent
> a huge amount of time going back and forth between source files trying to
> remember whether a particular variable was in meters or millimeters. You could
> argue that the design of the application was poor but it was one of those
> applications that grow from very simple beginnings by gradual additions into a
> huge creaking monster.
Yes, I would ;-)
Actually, my question is:
Can you provide good reasons to follow current PQS style (length::m
etc.) instead of simply Length, as me and others have proposed?
In this letter you only said that it was not a rational decision, but a
historical one. It doesn't convince me. It is not a good reason for
library that pretends to be in boost IMO.
Moreover, I have a strong feeling that the solution with simple Length
would be better. In particular, it'll simplify your code that uses PQS.
You've said that PQS helps you to remember in what units a variable is.
In a scheme with Length you simply have no need to remember it nor think
about it anymore.
Of course, I can be completely wrong. If so, I would like to see a
complete example were current scheme is beneficial. In C++, please.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk