From: Andy Little (andy_at_[hidden])
Date: 2003-11-08 16:32:27
"Nicolas Fleury" <nidoizo_at_[hidden]> wrote in message
> 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
> > 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
> 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
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.
Programmers love C because it is terse, fast to type. I want to keep that
Though C++ is my absolute first language ... thanks Bjarne Stroustrup !
In this example I prefer the first invocation of Force(,..,)
using namespace physical_quantities;
// function works in standard units
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;
//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_time<float>::s(t_min) + t_sec ) <<'\n';
// I prefer the first
> 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
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 !
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk