Walter, have you considered adding the "currency" data type to D, like the ones found in VB or Delphi? Something like this:

"Currency is a fixed-point data type that minimizes rounding errors in monetary calculations. It is stored as a scaled 64-bit integer with the four least-significant digits implicitly representing decimal places."

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a62k1m$2t64$1@digitaldaemon.com...
> Walter, have you considered adding the "currency" data type to D, like the ones found in VB or Delphi? Something like this:
>
> "Currency is a fixed-point data type that minimizes rounding errors in monetary calculations. It is stored as a scaled 64-bit integer with the four least-significant digits implicitly representing decimal places."

It sounds like a 64 bit integer type to me.  Which is the D "long" type.

It's no big deal (to my mind, anyway) to use "long" and consider it to represent a number of hudredths of pennies.

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net  (personal)

"Richard Krehbiel" <rich@kastle.com> wrote in message news:a62o9v$2v36$1@digitaldaemon.com...

> It sounds like a 64 bit integer type to me.  Which is the D "long" type.
>
> It's no big deal (to my mind, anyway) to use "long" and consider it to represent a number of hudredths of pennies.

It is actually represented by long internally, but the compiler should be able to convert it to and from other types properly:

    currency debt = 150.95;    // stored as 15095
    ...
    int i = debt;    // i is now 151
    float f = debt;  // f is now 150.95

It's much more convenient than to divide and multiply it all the time yourself. It's also much cleaner.

Pavel Minayev wrote:
> "Richard Krehbiel" <rich@kastle.com> wrote in message
> news:a62o9v$2v36$1@digitaldaemon.com...
> 
> 
>>It sounds like a 64 bit integer type to me.  Which is the D "long" type.
>>
>>It's no big deal (to my mind, anyway) to use "long" and consider it to
>>represent a number of hudredths of pennies.
>>
> 
> It is actually represented by long internally, but the compiler
> should be able to convert it to and from other types properly:
> 
>     currency debt = 150.95;    // stored as 15095
>     ...
>     int i = debt;    // i is now 151
>     float f = debt;  // f is now 150.95
> 
> It's much more convenient than to divide and multiply it
> all the time yourself. It's also much cleaner.

Gosh, if only we hadn't disallowed automatic conversion
operators for user-defined classes, you could do that
without expanding the language definition. :/

class currency
{
private:
   long cents;
public:
   ...
   operator int();
   operator float();
};

Much like every fixed-(binary)-point class I've written
for platforms that don't have fast FPUs.

<soapbox>

I predict that for every feature C++ has that D doesn't
(operator overloading, auto conversion operators, templates),
at least one person is going to ask for a specific language
feature (vector type, currency/fixed point/unit conversion
types, specific container types) that would be easily
be handled with the general feature.

I'm not saying that putting vectors and associative arrays
in the language is necessarily a bad thing. I just think
that generalized language features are a good thing.

</soapbox>

-RB

Russell Borogove wrote:

> <soapbox>
>
> I predict that for every feature C++ has that D doesn't
> (operator overloading, auto conversion operators, templates),
> at least one person is going to ask for a specific language
> feature (vector type, currency/fixed point/unit conversion
> types, specific container types) that would be easily
> be handled with the general feature.
>
> I'm not saying that putting vectors and associative arrays in the language is necessarily a bad thing. I just think that generalized language features are a good thing.
>
> </soapbox>

Agreed.  HOWEVER, I'm not too sure I like the C++ versions of how they are implemented...so let's keep pondering syntax and paradigms.  I bet that in time we'll come up with something that many/most of us like for each one...

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C8504D8.9000409@estarcion.com...

> Gosh, if only we hadn't disallowed automatic conversion operators for user-defined classes, you could do that without expanding the language definition. :/

However, for the sake of efficiency, it'd be better to provide a built-in implementation - just like it's done with complex.

Also from VB, the DECIMAL type is also very interesting: it's a 96 bits (12 bytes) unsigned integer, a sign  byte and a decimal négative power-of-10 byte -29...0, such that you can put the decimal point anywhere in the 29 decimal digits of this long long long (!) integer. These types are supported through the OLE/COM VARIANT record and support routines are available in oleaut32.dll: VarDec[A-Za-z0-9_]+ like VarDecAdd and VarCy[A-Za-z0-9_]+... A good article is at http://msdn.microsoft.com/library/en-us/dnguion/html/drgui042099.asp?frame=t rue (Dr. GUI and COM Automation, Part 3: More on COM's Fabulous Data Types). Reference is at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/automat/htm _hh2/chap7_5alv.asp.

"Pavel Minayev" <evilone@omen.ru> wrote in news message: a62k1m$2t64$1@digitaldaemon.com...
> Walter, have you considered adding the "currency" data type to D, like the ones found in VB or Delphi? Something like this:
>
> "Currency is a fixed-point data type that minimizes rounding errors in monetary calculations. It is stored as a scaled 64-bit integer with the four least-significant digits implicitly representing decimal places."
>
>

"Christophe Bouchon" <cbouchon@hotmail.com> schrieb im Newsbeitrag news:a63d2c$7fd$1@digitaldaemon.com...
> Also from VB, the DECIMAL type is also very interesting: it's a 96 bits
(12
> ...

Hi, I know that most people say you only need basic datatypes and from this you can build the others. Right, but why? If you want to see how powerfull a rich datatype system is I highly suggest to you to have a look at REBOL (http://www.rebol.com) It knows all things you will need in 90% of your applications.

--
Robert M. Münch
IT & Management Freelancer
Mobile: +49 (0)177 2452 802
Fax   : +49 (0)721 8408 9112
Web   : http://www.robertmuench.de

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a62k1m$2t64$1@digitaldaemon.com...
> Walter, have you considered adding the "currency" data type to D, like the ones found in VB or Delphi? Something like this:
>
> "Currency is a fixed-point data type that minimizes rounding errors in monetary calculations. It is stored as a scaled 64-bit integer with the four least-significant digits implicitly representing decimal places."

Why not just use 64 bit longs? The only thing to do is just plop down a decimal point when converting it to an ascii string.

Ah, I should have read the other replies before writing this. <g>

"Walter" <walter@digitalmars.com> wrote in message news:a6j2vt$1jv9$1@digitaldaemon.com...
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:a62k1m$2t64$1@digitaldaemon.com...
> > Walter, have you considered adding the "currency" data type to D, like the ones found in VB or Delphi? Something like this:
> >
> > "Currency is a fixed-point data type that minimizes rounding errors in monetary calculations. It is stored as a scaled 64-bit integer with the four least-significant digits implicitly representing decimal places."
>
> Why not just use 64 bit longs? The only thing to do is just plop down a decimal point when converting it to an ascii string.
>
>