[boost] Re: Physical Quantity- boostified

From: Andy Little (andy_at_[hidden])
Date: 2003-11-08 16:32:27

"Nicolas Fleury" <nidoizo_at_[hidden]> wrote in message
news:bogo70$pbe$1_at_sea.gmane.org...
> Andy Little wrote:
> > If the facilities are there you can decide whether or not to use them.
> > I see this as a policy thing. If it is your company policy not to
convert
> > there is nothing to stop you
> > commenting out all the conversion functions in the headers :-)
>
> Hi Andy,
>
> I agree with Deane, I prefer a design forcing the conversion to be
> explicit.  Something like (or any other way of making the conversion
> explicit):
> TypeA x; TypeB y;
> TypeA z = x + TypeA(y);

I could do this today and of course it would make the problem of
"what is the result of    A op B   " , just go away... which would certainly
give me an easy life on this project.
Maybe I will do that, but only after I have taken the long way round and had
a look at other possibilities :-)

>
> This is less error-prone.

Unfortunately the "conversions are dangerous" mantra is often applied
 to any conversion, between two types without qualification.
Some conversions are very dangerous ie int to X*
Some conversions are a bit dangerous ie double to float,
Some are harmless ie signed char to int.

I hope to identify what I would call precision losing conversions within the
physical_quantity type
and hopefully create a compile time warning for those only,
 possibly using boosts "concept checking " mechanism,
where a precision losing conversion is being performed.

My aim is to make these things look and feel  as much like their precursors
the inbuilt types as I can
while keeping the conversion mechanism

    See here for an overview.
  http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/abstract.html

Programmers love C because it is terse, fast to type. I  want to keep that
spirit.
Though C++ is my absolute first language ... thanks Bjarne Stroustrup !

In this example I prefer the first invocation of Force(,..,)
#include <iostream>
#include "physical_quantities.hpp"
#include "physical_quantities_demo_util.hpp"

using namespace physical_quantities;

// function works in standard units
pq_force<float>::N  Force(
           pq_mass<float>::kg const& mass,
           pq_velocity<float>::m_per_s const& initial_veloc,
           pq_velocity<float>::m_per_s const& final_veloc,
           pq_time<float>::s const& t)
{
            return   mass * (final_veloc - initial_veloc) / t;
}

int main()
{
    //lab technician works in "odd units"...

    pq_mass<float>::g const  mass(0.1);
    pq_velocity<float>::mm_per_minute const initial_v(5);
    pq_velocity<float>::mm_per_minute const final_v(5.5);
    pq_time<float>::minutes const t_min(10);
    pq_time<float>::s const  t_sec( 12);

    // func does work ... he doesnt have to...

    std::cout << Force(mass,initial_v, final_v, t_min + t_sec) << '\n';

    // the alternative with explicit conversions...

    std::cout << Force(pq_mass<float>::kg(mass),
                pq_velocity<float>::m_per_s(initial_v),
                pq_velocity<float>::m_per_s(final_v),
                pq_time<float>::s(t_min) + t_sec ) <<'\n';

    // I prefer the first
  return 0;
}

> For similar reasons it is justified that
> std::string doesn't provide an implicit conversion to const char*, it is
> justified to force explicit conversion in that case.

hmm... I am happy to use  str.c_str();  Whatever youre suggesting doesnt
sound very nice :-)
not very nice at all..

>I agree with Deane
> you're work/challenge is interesting, but still not a design I would
> choose.

Yes I've had a fair amount of flak. More please ...:-)

> I remember searching for a way to do:
> template <typename X, typename Y>
> Value<Result<X,Y>::Sum> operator+(Value<X> x, Value<Y> y);
>
> to discover it was impossible without a typeof operator (or many
> specializations).  In the end, it was better and simpler to not do it
> anyway and even with a typeof I would stuck with explicit conversion.

Bear in mind that C++ compiler and techniques  (ie boost et al)  technology
is moving forward rapidly,
What seemed impossible before is becoming possible now.

Why I love C++. Only C++ can do this ..................:-)
the future is MPL !

regards
Andy Little