[PATCH] Amend divetrip model to use int units

[Amit Chaudhuri]

Ah. I can see I only got part of the picture...thanks for the clear
explanations.

It leaves me with the "how do I..?" if I try and change diveItem to use
depth_t directly.  Here goes:

When I create the empty root item for the model I use a default constructor
call.

rootItem = new DiveItem;

And to get that to work I tried this...

explicit DiveItem(): number(0), dateTime(QString()), seconds(0), depth({0})
.....

^^^

This creates a compiler warning: extended initializer lists only available
with -std=c++11 or -std=gnu++11 [enabled by default] when I wrap the value
I want to put into the depth_t struct in braces

If I drop the curly braces I get a warning that boils down to a missing
constructor depth_t::depth_t().

So I guess my question is "what's the best way to pass the simple
subsurface units to a member initialisation list?"
And if the answer to that question is "don't" then how would you like to
see default constructors handle this without using member initialisation
lists?

A







On Wed, Apr 24, 2013 at 6:43 PM, Linus Torvalds <
torvalds at linux-foundation.org> wrote:

> On Wed, Apr 24, 2013 at 8:57 AM,  <amit.k.chaudhuri at gmail.com> wrote:
> >
> > Amend the DiveItem class to avoid float in favour of int
>
> No. Don't do this. "int" is better than "float", but it's still bad,
> because there is no unit, and there is no type safety.
>
> There's a really good reason why we do *not* write
>
>    int depth;
>
> but instead write
>
>    depth_t depth;
>
> and that is very important. The "depth_t" is typesafe (you can't
> mistakenly switch the order of a depth_t and a duration_t, even if
> they end up both having integral values), and "depth_t" has a *unit*,
> namely "mm". There is never any question about what "depth_t depth"
> means, unlike "int depth".
>
> We've used these types since very early on, and they've helped avoid
> unit issues etc. When you have to use "temp.mkelvin" to actually look
> at a temperature value, there's never any confusion about whether the
> values might have been converted to Celsius or Fahrenheit or whatever
> for display. Because our variables have *units*.
>
>                       Linus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130425/70089a9c/attachment-0001.html>