Re: Announcement of new C++11 library to handle measures
On Sunday, 5 October 2014 15:46:01 UTC+3, c.mila...@gmail.com wrote:
=D6=F6 Tiib wrote:
Boost contains some hacky workarounds and poor man substitutes
that can be used conditionally when real language features are not
available and that is actually large benefit of Boost.
I cannot imagine how to to the following with C++98.
typename <typename T1, typename T2, typename T3>
T3 add(T1 a1, T2 a2) { return a1 + a2; }
Given that T1, T2, and T3 are floating-point number types, which is
the type of T3?
Impossible in C++98 but Boost uses pre-C++11 extensions that
majority of compilers had (like 'typeof' or '__typeof').
Using C++11 I can write
typename <typename T1, typename T2>
decltype(T1()+T2()) add(T1 a1, T2 a2) { return a1 + a2; }
Yes. C++11 resolved lot of things that were sloppy in C++98/C++03.
May be another problem is the fact that the library includes
the standard header <unordered_map> to create 4 small hash-tables
used only by dynamic measures. If that is a problem, it may be
possible to implement the hash-table code inside the library,
or remove dynamic measures by a conditional compilation.
I imagine such dimensioned type system as static and nothing of it
feels dynamically polymorphic. So I can't imagine need for virtual
functions or hash tables or maps of function pointers.
Can you elaborate what is the purpose and use cases supported by
your dynamic unordered map?
My library supports two kinds of measures, for different purposes:
* Measures with statically-defined unit, to be used when the
application programmer knows which unit to use for a variable.
* Measures with dynamically-defined unit, not so efficient, to be
when the programmer knows which magnitude to use for a variable,
and knows also a set of possible units to use for it, but the actual
unit is defined only at run-time as it depends on input data or on
system configuration.
Ok, let me try to think about it.
1) Most efficient is to use the values with fixed units that involve
least amount of conversions done during math.
2) However user may want to see or to enter milliseconds or minutes
instead of seconds or something like that.
3) Also users differ so there is always controversy.
A solution: We let user to dynamically pick a variable (lets say
to pick an index of member of tuple or variant) that has unit that
he wants to use during I/O and assign our internal variables to
or from it.
However that user-picked member can fully have fixed unit and still
it can be used for I/O. So a need for dynamic units does not follow
only need for dynamic choice between different variables.
In the latter case, some lookup tables are used for the following purpose=
..
When two measures are multiplied, say a force is multiplied by a length,
the unit of the resulting measure must be chosen among the available
units for energy. And as the units of force and of length are dynamic,
i.e. stored in variables, the unit of energy cannot be computed at
compile-time, but looking it up in a container.
Using variables with such dynamic types in math feels inefficient
since there are likely (dynamically decided) conversions needed on the
fly. Especially when there is a lot of math to do it hurts.
It is less crucial in I/O. In I/O the throughput and latency are the
bottle-necks. Modern processors are idle most of the time during I/O
so can use the spare time to convert things and what not. That is why
most web services are Java, C# or even PHP. Only most huge sites like
youtube or google use C++.
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.