Re: Announcement of new C++11 library to handle measures
=D6=F6 Tiib wrote:
On Sunday, 5 October 2014 13:41:49 UTC+3, c.mila...@gmail.com wrote:
I have no experience with using C++ for systems containing only few
KB of memory. And I am in no place to get such experience.
I let other to evaluate feasibility of using C++ compiler and
libraries on such system.
Relax, it is fine. The C++ language is efficient to edge when used
correctly. To the same edge that C targets. C++ libraries are mostly
templates and header-only.
We only get what we actually use from library and from that only the
part that compiler could not do compile-time.
But if I use a non-empty standard container (like "vector" or "unordered_ma=
p"), a memory allocator and an exception handler are included to my executa=
ble. For some application that is not desirable.
For myself, I think that portability on micro-controllers is not
a good-enough argument to avoid the use of the "decltype" keyword.
Forget thinking "micro-controllers". I bet your TV-set if you have
one (I don't) runs Linux somewhere inside of it.
But then it uses more that few KB of RAM.
That is OK that you want to use C++11 features, these are
cool, just that you did put it up as some sort of first benefit
when comparing to Boost while in real industry it is usually
painful impediment.
Well, I presented it as a difference. It is a benefit for Boost.
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 typ=
e of T3?
Using C++11 I can write
typename <typename T1, typename T2>
decltype(T1()+T2()) add(T1 a1, T2 a2) { return a1 + a2; }
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 pr=
ogrammer 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 se=
t of possible units to use for it, but the actual unit is defined only at r=
un-time as it depends on input data or on system configuration.
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, th=
e unit of the resulting measure must be chosen among the available units fo=
r 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 lo=
oking it up in a container.
--
Carlo Milanesi