[haiku-development] Re: gcc enable _Decimal32, _Deimal64 and _Decimal128 (and g++ decimal32, ...) support

  • From: fano il primo <fanoilprimo@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 5 Dec 2011 15:04:12 +0100

On Mon, Dec 5, 2011 at 3:48 AM, Joseph Groover <looncraz@xxxxxxxxxxx> wrote:

>  Mmmh yes, I suppose I've done the wrong example, but if you do for
>> example a lot of calculation on double number (for example representing
>> €/$) for example multiplying them for 5, and for 6 and in the end you want
>> convert in €cent (casting to int multipying for 100.00)... well it can be
>> in the end you expect 1 €/$ and get 0 €/$ as in the memory it was really a
>> 0.999999999999999748 and not 1.0 (!)... I know I can round but why I have
>> to? For me, a human being, it should do 1 not a 0, it's unimportant if
>> CPU's likes binaries...
>> I've 10 digits to use, I'm*not an horse* :-)
> I'm hoping I'm not entirely off-base (haven't read the entire discussion),
> but if you are trying to get an integer approximation of rounding you
> generally just add 0.5 to the float then cast to int...
> float anonFloat = 0.83333;
> int lazyRoundInt = (anonFloat+0.5);
> lazyRoundInt now holds the value of 1.
> I'm assuming I'm off-base, but oftentimes the simple solutions are the
> hardest to remember...
> --The loon
Yes I can do it, but why?
I've a *compiler* *native type*, why have to do strange tricks or KLUDGES?

You say "it's an evil GCC extension", well I say: "correct! In part...", as
it is a defined IEEE Standard, let see:

so as you can imagine maybe in the future will be add to the next C/C++
standards as a native type or class... so why reinvent the wheel?
There's already... if you do a specific Haiku C++ class instead of G++ one,
I would use the same libdecnumber maybe doing some method in the "Support
Kit" to convert form decimal to BString, flatten, BMessage and so....
I say why do so much work? It's already existent so... what?


Other related posts: