Re: Announcement of new C++11 library to handle measures
=D6=F6 Tiib wrote:
On Sunday, 5 October 2014 19:44:45 UTC+3, Wouter van Ooijen wrote:
=D6=F6 Tiib schreef op 05-Oct-14 5:38 PM:
I suggest you consider there a bit ... might be that you can get rid
of needless dynamic units or might be you can move them to I/O layer
or might be that you have some more reasons why these are needed
in math.
But as far as I understand, as a user, those dynamic units cost me
nothing when I don't use them. If that is correct the cost of having
them is small (= skipping the (ir)relevant parts of the documentation=
),
so even a rare use case for them might be enough for them to be
worthwhile.
AFAIK all compilers are in difficulty to optimize out any sort of
dynamic polymorphism even if it is not used. If the efficiency drop
is of any significance then it may be is an unneeded choice that
will be made one way as rule by experienced users. Author has still
to maintain code and documentation (useless work). So better idea
is to consider it beforehand.
As I wrote elsewhere, such dynamic units are much less efficient, by at lea=
st 6 times, according a rough benchmark.
My idea was to avoid any impact on performance when they are not needed.
But actually, with current implementation, they have a small impact, as the=
y allocate and fill some small collections at program start-up. Therefore t=
hey require some memory for data and some memory for the machine code of "v=
ector", "unordered_set", and the required default memory allocator and exce=
ption handling mechanism.
For those who want absolutely zero-overhead, implementation has to be rewor=
ked.
I will work on that.
But I wonder if such kind of measures are really needed by anyone.
I mean, if an application must let the user choose between inches or millim=
etres, or between degrees and radians, it is reasonable to force the applic=
ation programmer to write machine code for just one unit per magnitude, and=
convert the input value from the unit required by user and to such unit at=
output, or alternatively, it is better to force the application programmer=
to generate machine code for all the supported units (possibly using templ=
ates)?
Here is some sample code that gets from the user the desired unit of measur=
ement, a value in such unit, does some computation (computes the triple of =
such value), and prints the result in the same unit of the input value.
With no library:
int unit = get_desired_unit();
double value = get_desired_value();
double result = value * 3; // fast computation
print_value_and_unit(result, unit);
With dynamically-defined unit measures:
int unit = get_desired_unit();
double value = get_desired_value();
dyn_vect1<Space> value(unit, value); // encapsulate
dyn_vect1<Space> result = value * 3; // slow computation
print_value_and_unit(result); // decapsulate
With several cases of statically-defined unit measures:
int unit = get_desired_unit();
double value = get_desired_value();
switch (unit)
{
case inches_id:
vect1<inches> value_inches(value);
vect1<inches> result_inches
= value_inches * 3; // fast computation
print_value_and_unit(result_inches); // overload
break;
case millimetres_id:
vect1<millimetres> value_millimetres(value);
vect1<millimetres> result_millimetres
= value_millimetres * 3; // fast computation
print_value_and_unit(result_millimetres); // overload
break;
}
With single case of statically-defined unit measures:
int unit = get_desired_unit();
double value = get_desired_value();
// The value is always converted
// from the specified unit to inches.
vect1<inches> value_inches(
convert_from_to(unit, inches_id, value));
// Computation is done always in inches.
// fast computation
vect1<inches> result_inches = v_inches * 3;
// The value of the result is always converted
// from inches to the specified unit.
double result = convert_from_to(inches_id, unit,
result_inches.value());
print_value_and_unit(result); // Unique output routine
Which solution is better?
--
Carlo Milanesi