Natural size: int

  • Thread starter Frederick Gotham
  • Start date
G

Giorgio Silvestri

"Keith Thompson" <[email protected]> ha scritto nel messaggio

[...]
Is it possible to write a macro such that
UNSIGNED_TYPE(1000000)
portably expands to either "unsigned int" or "unsigned long",
depending on which type can hold the specified value? I suspect not.

#define UNSIGNED_TYPE(x) x ## u
 
G

Giorgio Silvestri

Giorgio Silvestri said:
"Keith Thompson" <[email protected]> ha scritto nel messaggio

[...]
Is it possible to write a macro such that
UNSIGNED_TYPE(1000000)
portably expands to either "unsigned int" or "unsigned long",
depending on which type can hold the specified value? I suspect not.

#define UNSIGNED_TYPE(x) x ## u

ops. you probably mean textually "unsigned int" or "unsigned long" ...
 
K

Keith Thompson

jacob navia said:
Look, if you have
double a,b,c,d;
...
d = a*b+c;

you need more precision? You do:
qfloat a,b,c,d;
...
d = a*b+c;

You see?

Yes, jacob, we understand. Most of us know what operator overloading
is.

C doesn't have it. We discuss C here. I'm very happy for you that
you've implemented what may or may not be a useful extension, but it's
off-topic here.

If you want to propose a change to the language, take it to
comp.std.c. If you want to discuss some non-standard extension, take
it to comp.compilers.lcc.
 
K

Keith Thompson

Giorgio Silvestri said:
Giorgio Silvestri said:
"Keith Thompson" <[email protected]> ha scritto nel messaggio
[...]
Is it possible to write a macro such that
UNSIGNED_TYPE(1000000)
portably expands to either "unsigned int" or "unsigned long",
depending on which type can hold the specified value? I suspect not.

#define UNSIGNED_TYPE(x) x ## u

ops. you probably mean textually "unsigned int" or "unsigned long" ...

Yes. For example:

UNSIGNED_TYPE(1000000) obj;
 
E

Eric Sosman

Keith Thompson wrote On 08/10/06 17:00,:
Giorgio Silvestri said:
"Keith Thompson" <[email protected]> ha scritto nel messaggio
[...]

Is it possible to write a macro such that
UNSIGNED_TYPE(1000000)
portably expands to either "unsigned int" or "unsigned long",
depending on which type can hold the specified value? I suspect not.

#define UNSIGNED_TYPE(x) x ## u

ops. you probably mean textually "unsigned int" or "unsigned long" ...


Yes. For example:

UNSIGNED_TYPE(1000000) obj;

All I can think of is

#include <limits.h>
#define T unsigned int
typedef T T0;
typedef T T1;
...
typedef T T65535;
#if UINT_MAX == 65535
#undef T
#define T unsigned long
#endif
typedef T T65536;
typedef T T65537;
...
typedef T T131071;
#if UINT_MAX == 131071
#undef T
#define T unsigned long
#endif
typedef T T131072
...
typedef T T4294967295
... /* !!! */
#undef T /* for cleanliness' sake */
#define UNSIGNED_TYPE(x) T ## x

.... which might be deemed less than elegant.
 
E

Eric Sosman

Keith Thompson wrote On 08/10/06 16:58,:
Look, if you have
double a,b,c,d;
...
d = a*b+c;

you need more precision? You do:
qfloat a,b,c,d;
...
d = a*b+c;

You see?


Yes, jacob, we understand. Most of us know what operator overloading
is.

C doesn't have it. [...]

Please explain why binary `-' should not be considered
overloaded, given that its operands can be any of the twelve
basic arithmetic types (after promotion), or any additional
non-promotable types the implementation might provide, or any
object pointer type paired with a promoted integer type, or
any "commensurate" object pointer types.

Off-hand, I cannot think of any C operator that is *not*
overloaded. No, not even the comma operator.
 
K

Keith Thompson

Eric Sosman said:
Keith Thompson wrote On 08/10/06 16:58,:
Look, if you have
double a,b,c,d;
...
d = a*b+c;

you need more precision? You do:
qfloat a,b,c,d;
...
d = a*b+c;

You see?


Yes, jacob, we understand. Most of us know what operator overloading
is.

C doesn't have it. [...]

Please explain why binary `-' should not be considered
overloaded, given that its operands can be any of the twelve
basic arithmetic types (after promotion), or any additional
non-promotable types the implementation might provide, or any
object pointer type paired with a promoted integer type, or
any "commensurate" object pointer types.

Off-hand, I cannot think of any C operator that is *not*
overloaded. No, not even the comma operator.

I was insufficiently precise.

C doesn't have user-defined operator overloading. Like many
languages, it overloads the predefined operators on its own predefined
types.

If this "qfloat" were part of the C language, presumably there would
be language-defined overloaded operators for it, just as there are for
any other language-defined floating-point type. But it isn't; it's an
extension implemented by a certain compiler that jacob keeps trying to
advertise here.
 
R

robertwessel2

jacob said:
using a signed 64 bit integer type and working in cents
should be able to handle money quantities up to

92 233 720 368 547 758 US$ and 8 cents.

Enough to accomodate the now considerable total US
debt... :)

Using native types is quite easy considering the progres in
hardware in the last years. Besides, accounting people that
need those extreme money amounts will not shudder to buy a
latest model PC for a few thousand dollars.

You can work in decimals of cents if you need sensible rounding.


The Cobol folks are requiring 36 decimal digit support in the lastest
Cobol standard (up from 18), which in a binary format would imply a 128
bit number. For example, until the Turkish Lira was revalued a few
years ago, the US GDP (to say nothing of the global GDP) represented in
TL would rather thoroughly overflowed a 64 bit int. Right now
Indonesian Rupiah's are right on the edge, and Columbian Pesos and
Venezuelan Bolivars are not far behind.

Even worse, C does not have extended range intermediates (required by
Cobol), so currency calculations will overflow far short of the nominal
limits implied by a 64 bit int. Just multiply the GDP of the U.S. in
cents by a 99.99 percentage, and you will overflow 64 bit
intermediates.

A bignum package remains the only way to do reliable currency
calculations in C.
 
J

jacob navia

The Cobol folks are requiring 36 decimal digit support in the lastest
Cobol standard (up from 18), which in a binary format would imply a 128
bit number.

The lcc-win32 C compiler provides a 128 bit integer, and it
will be more and more common in the near future as 64 bit
machines become common. A 64 bit machine can do 128 bit
arithmetic quite fast. And that will really finish it since

pow(2,128) = 3.40282366920938463463374607431768211456E38 exactly

If you imagine that the smallest bill of currency X is a 10 million
bill, and its thickness is 0.1mm, to a pile worth 3.4e38 of
that currency would measure around 3.59E11 Light years.

The radius of the known universe is only around 1.3E9 light years.

So, we are protected against inflation with 128 bits. :)

Using lcc-win32:

* a=pow(2,128)
3.4028236692093846346337460743176821145600000000000000000000000000000000E38
* b=a/10000000 // smallest bill is 10 million
3.4028236692093846346337460743176821145600000000000000000000000000000000E31
* c=b/10000 // Thickness of 0.1mm, expressed in meters: divide by 10 000
3.4028236692093846346337460743176821145600000000000000000000000000000000E27
* e=300000*1000*365*24*3600 // meters in a light year
9.4608000000000000000000000000000000000000000000000000000000000000000000E15
* c/e // number of light years necessary for the pile of bills
3.5967610236020047296568430516633710833756130559783527820057500422797226E11
*

I hope I did not do a mistake somewhere :)
 
D

Dik T. Winter

> Are you familiar with C++ at all? If so, you'd know that classes and
> templates are far more than simple macro and typedef substitution.

I do not know much about C++, but have used other languages that extensively
use overloading of operators (Algol 68 and Ada) and functions (Ada and
Fortran for standard functions). Hence my question:
> Put them together and you've got a very powerful tool. A sample usage might
> be to write a class called "Int1024" which is a 1024-Bit integer, and to
> use operator overloading to make it behave like a built-in integer, so that
> we can simply do:
> Int1024 i = 56;
> i *= 3;

and i * 3 and 3 * i and i * i, I suppose. But doesn't that require the
definition of three multiplication operators?
 
K

Keith Thompson

jacob navia said:
The lcc-win32 C compiler provides a 128 bit integer,
[...]

With what syntax? Is it consistent with the C standard? Do you need
to include some non-standard header to use it?

If it's called "long long", or if it's implemented as an "extended
integer type" (types, actually, if you provide signed and unsigned
variants) as described in C99 6.2.5, and if it's used appropriately in
<stdint.h>, that's terrific. If it's implemented as a non-standard
extension, that's not nearly as interesting. (I think Mathematica
implements very long integers, and it's not C either.)
 
F

Frederick Gotham

Dik T. Winter posted:
and i * 3 and 3 * i and i * i, I suppose. But doesn't that require the
definition of three multiplication operators?

<OFF TOPIC>

Not really. Firstly you define the *= operator:

class MyInt {
private:

int val[6];

public:

MyInt &operator*=(MyInt const &rhs)
{
int *p = val;
int const *prhs = rhs.val;

*p++ *= *prhs++;
*p++ *= *prhs++;
*p++ *= *prhs++;
*p++ *= *prhs++;
*p++ *= *prhs++;
*p++ *= *prhs++;

return *this;
}
};

Then you simply pigg-back off it:

MyInt operator*(MyInt lhs, MyInt const &rhs)
{
return lhs *= rhs;
}

You can make an "int" convert implicitly to a "MyInt" by supplying a
constructor which takes a sole "int" parameter.
 
R

robertwessel2

jacob said:
(e-mail address removed) wrote:
The lcc-win32 C compiler provides a 128 bit integer, and it
will be more and more common in the near future as 64 bit
machines become common. A 64 bit machine can do 128 bit
arithmetic quite fast. And that will really finish it since

pow(2,128) = 3.40282366920938463463374607431768211456E38 exactly

If you imagine that the smallest bill of currency X is a 10 million
bill, and its thickness is 0.1mm, to a pile worth 3.4e38 of
that currency would measure around 3.59E11 Light years.

The radius of the known universe is only around 1.3E9 light years.

So, we are protected against inflation with 128 bits. :)


As I mentioned, the problem happens first with intermediate results, so
this is the wrong comparison. OTOH, 128 bit intermediate results ought
to be sufficient for most cases, although will require some care at
times.
 
R

Richard Heathfield

Frederick Gotham said:

Are you familiar with C++ at all?

If I want C++, I know where to find it. Please confine C++ discussions to
newsgroups where they are topical. Thank you.
 
R

Richard Bos

jacob navia said:
Ian said:
Isn't this a case of if the cap doesn't fit, use another one?

You could achieve what you describe in a language that supports operator
overloading on user defined types.

Yes. That is why [spam - ed.] proposes to enhance the language with that
feature. It is needed in MANY situations

No, it isn't.
and it doesn't complexify the language at all.
^^^^^^^^^^
*THWAP* You're not George Pedestrian Bush, so don't imitate him

And yes, it does. Considerably. Most importantly, it makes any code I
read in C-plus-overloading less reliable than code in C.
operator overloading is a MUST for C.

On the contrary, it is greatly to be eschewed.
P.S. flames >/dev/null

P.S. Any future spam >your own toy newsgroup, please.

Richard
 
R

Richard

Richard Heathfield said:
Frederick Gotham said:



If I want C++, I know where to find it. Please confine C++ discussions to
newsgroups where they are topical. Thank you.

Yawn. It was in the context of a C discussion.
 
T

Tom St Denis

jacob said:
The lcc-win32 C compiler provides a 128 bit integer, and it
will be more and more common in the near future as 64 bit
machines become common. A 64 bit machine can do 128 bit
arithmetic quite fast. And that will really finish it since

Because I hate you so very much I wrote

http://math.libtomcrypt.com/ltmpp.zip

Which is a C++ wrapper around my LTM library. It's no more valid C
than your extensions. However, it's also portable C++ and is the
"smart" way to deal with this.

If people really wanted something like

bignum a;
a = 2; a <<= 128;

Then C++ is the way to achieve it. Which is what my C++ code does.
But instead of being tied to some crappy halfbreed compiler like yours,
any conforming C++ compiler will handle my code. It will work in Linux
and BSD just as happily as in Windows, etc. Oh and my C++ class will
support ANY size integer (within reasonable limits) not just compile
time fixed size integers.

This is what separates us real software developers from the script
kiddie hackers like you who just don't get how to work in a team.

Sorry for posting about C++ on clc but Navia really needs to get beaten
back into reality.

Tom
 
E

Eric Sosman

Keith Thompson wrote On 08/10/06 18:54,:
I was insufficiently precise.

C doesn't have user-defined operator overloading. Like many
languages, it overloads the predefined operators on its own predefined
types.

Ah. Okay, but C does support a very limited form of
user-defined overloading for some operators. For example,
the user can apply the () operator to function pointer
types not listed in the Standard.

In other words, "I know what you mean, and you know
what you mean, but we're both having a hard time expressing
it exactly." ;-)
If this "qfloat" were part of the C language, presumably there would
be language-defined overloaded operators for it, just as there are for
any other language-defined floating-point type. But it isn't; it's an
extension implemented by a certain compiler that jacob keeps trying to
advertise here.

From the dribs and drabs of information he's trumpeted
so often, I think Jacob has probably done his "qfloat" in the
form of a Standard-conforming extension, that is, something
that doesn't interfere with a conforming program. I don't
know the specifics of his choices, but if I were going to
add such an extension I'd add a `_qfloat' keyword (in the
implementation's name space), and maybe a <qfloat.h> header
that (among other things) did `typedef _qfloat qfloat;'.

Assuming that qfloat is really _qfloat behind the scenes,
I think the extended compiler is within its rights to define
how this extended type responds to various operators. That
is, "implementor-defined operator overloading" seems legal,
if applied to implementor-defined extended types. The
situation with mixed types is a little murkier because of the
Standard's enumeration of promotion rules; I'm not sure that

_qfloat q = 6;
q *= 7;

.... would be a legal way to obtain forty-two, because the
Standard describes all the possible promotions of the int
operand 7, and none of them leads to a _qfloat value. But
there may be a loophole somewhere I haven't spotted.

Hmmm... I wonder what his _qfloat constants look like.
It seems to me that a diagnostic is required for 3.14Q0 or
suchlike, even if the compiler also recognizes it as a
highly-precise poor approximation to pi. Maybe the compiler
needs to reject such constructs until <qfloat.h> provides
the magic `#pragma enable_qfloat'. I suppose such a #pragma
would also offer a way out of the promtion pickle. In fact,
maybe #pragma could take care of the whole business: turning
`qfloat' from an identifier to a keyword (doing away with
the need for `_qfloat'), enabling the recognition of constants,
augmenting the conversion rules, everything.
 
E

ena8t8si

Eric said:
Keith Thompson wrote On 08/10/06 18:54,:

Ah. Okay, but C does support a very limited form of
user-defined overloading for some operators. For example,
the user can apply the () operator to function pointer
types not listed in the Standard.

There's still only one semantic for function call. The
operator is overloaded, but not user-defined overloading,
because the semantics can't be changed. Array indexing is
another overloaded operator; also not user-defined overloading.
In other words, "I know what you mean, and you know
what you mean, but we're both having a hard time expressing
it exactly." ;-)

The key is a user having the ability to choose different
semantics based on operand types. If the language chooses, it
isn't user-defined.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top