It was actually Ken@Alverson.net ("Ken Alverson") who wrote
> > > > Gross World Product in Italian Lire (approx):
> > > >   86,059,192,289,472,048
> > > > Maximum 128 bit value:
> > > >   340,282,366,920,938,463,463,374,607,431,768,211,455

> > "Allan W" <allan_w@my-dejanews.com> wrote in message
> > >   Maximum 64-bit signed value:
> > >     9,223,372,036,854,775,807

> "DrPizza" <drpizza@anti-flash.co.uk> wrote
> > Turkish Lire are I think the most inflated currency around, I believe.
> >
> > 16801414582768992256 TRL > 9223372036854775807
> >
> > Hence the need for something larger than 64 bits when manipulating
> > currencies -- today.

"Hillel Y. Sims" <usenet@phatbasset.com> wrote
> "need" seems a bit strong given the contrived scenario you just described

A bit, perhaps, but not very much. The point is, if we can come up with
a conceivable need for 128-bit values in commerce, then it's very likely
that the scientific community will need it for something more tangible.
Astronomical distances/dates, for instance. Not being of the scientific
community myself, I can't get much more specific than that.

> (besides, are all those digits really significant anyhow?).

Even in ordinary commerce, the rule is: "use the most accurate data
possible."

Once again, federal law requires banks to keep balances to the nearest
1/1000 of a penny, and many banks provide two decimal places beyond that.
(Why? To avoid the problem that happened about 20 years ago, when a
programmer diverted round-off errors to his own account. Besides,
Federal legislators are fickle; they might change the precision rule
again any day, and if they do they're likely to demand that it be
implemented in 2 months!).

When dealing with import/export duties, it's very likely that you won't
be doing business in a single currency, but two, three, even four
currencies. Round-off errors can really add up when you constantly
translate back and forth between these sources.

Have you ever seen a statement like this?

    Item 1: $22.44
    Item 2: $11.05
    Item 3: $ 1.20
            ------
      Total $34.70

The apparent 1-cent error appears because prices on the statement
have been rounded to the nearest cent. Otherwise we could well see:

    Item 1: $22.44430
    Item 2: $11.05425
    Item 3: $ 1.20245
            ---------
      Total $34.70100

But isn't this only relevant to floating-point calculations?
Nonsense. There's no reason not to do monetary calculations with
"exact" numeric types. C++ doesn't have fixed-point arithmetic,
but it's easy to simulate it with an integral type. Some
languages (i.e. Forth) don't even have floating-point values,
and don't miss them either. (Not a Forth expert -- maybe it does
have it now, but it didn't used to.)

> "Who wants to be a Turkish Millionaire?!"

I very nearly am! (I really need a raise...)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Allan W" <allan_w@my-dejanews.com> wrote...
>
> A bit, perhaps, but not very much. The point is, if we can come up
with
> a conceivable need for 128-bit values in commerce, then it's very
likely
> that the scientific community will need it for something more
tangible.

In floating point, yes, but in fixed point or integers, I doubt it.

In commerce, the places where you are allowed to drop precision are
carefully controlled by law, so measuring all monetary values in
milli-pennies is a natural implementation technique.

In science, there is no such legal requirement. If your intermediate
results warrant 20-digit precision (so that you can subtract values
without a catastrophic loss of precision) then you might be interested
in "extra long double", but it is unlikely that you'd be interested
in coding up your own fixed point routines on top of an integer type.

Nevertheless, I think you have a case for commercial usage...

> Once again, federal law requires banks to keep balances to the nearest
> 1/1000 of a penny, and many banks provide two decimal places beyond
that.

...and (2**64)*(10e-7) is roughly 2 trillion (US).

That's a realistic monetary value, either as an end-result or
as an intermediate when (say) balancing the books.

I've chosen the "two decimal places beyond that" because it is possible
that some form of micro-payments for e-trade might force the legislators
to increase the precision in future. It's debatable whether the cost of
15 seconds of downloaded music will ever need to be factored into a
national balance sheet, but there may be implementation pressures which
make it attractive to measure all monetary values in the same units.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Allan W" <allan_w@my-dejanews.com> wrote in message
news:7f2735a5.0301120208.1877c6ef@posting.google.com...
> > US GDP in Mexican Centavos (approx):
> >   10,641,590,130,605,220
> > Gross World Product in Centavos (approx):
> >   49,588,421,076,264,900
> > Gross World Product in Italian Lire (approx):
> >   86,059,192,289,472,048
> > Maximum 128 bit value:
> >   340,282,366,920,938,463,463,374,607,431,768,211,455
>   Maximum 64-bit signed value:
>     9,223,372,036,854,775,807
>
>   9,223,372,036,854,775,807 / 86,059,192,289,472,048:
>     107.17
>
> We'll use your numbers, and assume that Italian Lire remain
> the lowest commonly-used currency (a big assumption). If the
> GWP doubles every 5 years, then within 3 decades it will have
> overflowed 32-bits of Italian Lire. 128-bit numbers have no
> such problem.
Turkish Lire are I think the most inflated currency around, I believe.

106,415,901,306,052.20 Mexican Pesos, at today's rates, is
16,801,414,582,768,992,256.00 Turkish Lira.  They're about 1.6 million to the
dollar.  (Italian Lire are no longer legal tender, let alone commonly used;
their exchange rate is/was only about 1800 to the dollar.  They've been
replaced by the Euro)

16801414582768992256 TRL > 9223372036854775807

Hence the need for something larger than 64 bits when manipulating
currencies -- today.


--
Now Playing:  Electric Light Orchestra - Last train to London


char a[99999],*p=a;main(int c,char**V){char* v=c>0?1[V]:V;if(c<0)for(c=1;c;c
+=!(91^*v)-!(93^*v),++v);else for(;(c=*v)&&93^c;p+=!(62^c)-!(60^c),*p+=!(43^
c)-!(45^c),44^c||read(0,p,1),46^c||putchar(*p),91^c||(v=*p?main(0,++v),v-2:\
main(-1,++v)-1),++v);return v;}/*bf prog as argv[1]. drpizza@battleaxe.net*/


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"DrPizza" <drpizza@anti-flash.co.uk> wrote in message
news:v2j8kkr0g7m095@corp.supernews.com...
> "Allan W" <allan_w@my-dejanews.com> wrote in message
> news:7f2735a5.0301120208.1877c6ef@posting.google.com...
> > > US GDP in Mexican Centavos (approx):
> > >   10,641,590,130,605,220
> > > Gross World Product in Centavos (approx):
> > >   49,588,421,076,264,900
> > > Gross World Product in Italian Lire (approx):
> > >   86,059,192,289,472,048
> > > Maximum 128 bit value:
> > >   340,282,366,920,938,463,463,374,607,431,768,211,455
> >   Maximum 64-bit signed value:
> >     9,223,372,036,854,775,807
> >
> >   9,223,372,036,854,775,807 / 86,059,192,289,472,048:
> >     107.17
> >
> > We'll use your numbers, and assume that Italian Lire remain
> > the lowest commonly-used currency (a big assumption). If the
> > GWP doubles every 5 years, then within 3 decades it will have
> > overflowed 32-bits of Italian Lire. 128-bit numbers have no
> > such problem.
> Turkish Lire are I think the most inflated currency around, I believe.
>
> 106,415,901,306,052.20 Mexican Pesos, at today's rates, is
> 16,801,414,582,768,992,256.00 Turkish Lira.  They're about 1.6 million to
the
> dollar.  (Italian Lire are no longer legal tender, let alone commonly
used;
> their exchange rate is/was only about 1800 to the dollar.  They've been
> replaced by the Euro)
>
> 16801414582768992256 TRL > 9223372036854775807
>
> Hence the need for something larger than 64 bits when manipulating
> currencies -- today.
>
>

"need" seems a bit strong given the contrived scenario you just described
(besides, are all those digits really significant anyhow?).

hys
"Who wants to be a Turkish Millionaire?!"

--
(c) 2003 Hillel Y. Sims
hsims AT factset.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

brangdon@cix.co.uk (Dave Harris) wrote
> allan_w@my-dejanews.com (Allan W) wrote (abridged):
> > > Are there many real world problems that need 128-bit integers?
> >
> > Sure. [various examples]
>
> Even for those, I think I would be more comfortable with arbitrary
> precision integers. These would be guaranteed available, albeit
> implemented in software rather than hardware on some platforms. They would
> be more portable and more extendable, if I ever found even 128 bits wasn't
> enough.

I would like that.

I know that the standard library doesn't try to cover every field of
science or engineering; it intentionally leaves out the ones that won't
apply to most programmers, figuring that third-party add-ons should be
sufficient.

I think, though, that arbitrary-precision integers do not fall into
this class, at least not anymore. Better yet, arbitrary-precision
decimals. I think we ought to be able to write a program that calculates
the first 1000 digits of PI, without having to invent our own high-
precision number class first.

> > > Most uses are either (a) are not really integers; or (b) not
> > > really fixed-size.
> > >
> > > Examples of (a) include pointers
> >
> > Perhaps these aren't really integers, but that doesn't mean we don't
> > need to do math with them. If your array starts at virtual address
> > 0x400000012EFF0000, each element is 256 bytes, and you want the
> > fourth element... you need SOME way to come up with the virtual
> > address 0x400000012EFF0030.
>
> Indeed. I think pointers are what has driven the need for 64-bit
> arithmetic in hardware. 32-bits isn't enough address space. And once you
> have 64-bit arithmetic for pointers you might as well make it available
> for integers.

I agree. Addition and subtraction on multiple-precision integers is
trivial in assembly language. It's only when your pointers get bigger
that you bother increasing the size of the ALU -- and then of course
it's available for integers too.

> And I am not sure that [128-bit address spaces] will ever make sense.
> I am not saying we won't need to address that much, but rather, I
> wonder whether a segmented architecture in which arithmetic is only
> done on the low 64 bits may be better use of hardware.

Probably, but I don't think it would sell as well. Theoretically the
Pentium still has segmented architecture. In practice, nobody uses it
that way except in device drivers and such.

> > Furthermore, if the hardware has a way to multiply two longs and
> > return the entire result, and you don't take advantage of it, you
> > won't be taking maximum advantage of your platform. The proper place
> > for code that "knows" things like that, is in the Standard C++
> > library that comes with each compiler.
>
> Sure. I am not sure if it is worth adding 128-bit ints to the language
> just to help implement arbitrary precision libraries. Rather, such a
> library should be put into the standard. Then it can be implemented in
> assembler using whatever facilities the host machine offers.

I agree.

Not too hard to multiply two 640-bit unsigned integers in most assembly
languages. You multiply two unsigned longs, you get two unsigned longs
returned -- the low-order and high-order product. Add them to the
appropriate place in the result and keep going.

In C or C++, things get much tougher. When you multiply two unsigned
longs, you get only one unsigned long in return. If you need the
high-order bits, you have to multiply smaller types. If you know that
longs are 32 bits and shorts are 16 bits, you can use them. You have
to convert 16 bits at a time to unsigned long (with the high-order bits
set to 0), do the multiply, then the low-order 16 bits is your result
and the high-order 16 bits are your "carry."

In Portable C++, you don't have much choice except the lowest
common denominator. Use 8-bit numbers (stored in unsigned char),
load them into unsigned long for the multiplication, and so on. SLOW!

> (Which are probably better for not being obscured by C++. Eg many machines
> have 32x32 => 64, but C++ only has 32x32 => 32 and 64x64 => 64.)
>
> I suppose it may ultimately be a matter of keeping up with the Joneses.
> C++ aims to leave no room for a lower level language, other than
> assembler. So if some hardware has 128-bit ints, and some other language
> adds direct support for them, C++ must have them too.

If the hardware has 128-bit ints, the local assembly language always
has access to it too.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) writes:

[...]

| > This, I can agree with.  But it is curious to note how the discussion
| > has shifted from "long long" to "int64_t", which both have been added to
| > the language in a way that could not have broken a valid program.
|
| int64_t certainly could (theoretically) have broken a valid program!
|
|     int main() {
|         for (int int64_t=0; int64_t<10; ++int64_t)
|             std::cout << int64_t;
|         }
|     }

Not, really: the above int64_t would have shodowed the typedef-name
::int64_t.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Allan W" <allan_w@my-dejanews.com> wrote in message
news:7f2735a5.0301141711.50149781@posting.google.com...
> brangdon@cix.co.uk (Dave Harris) wrote
> > allan_w@my-dejanews.com (Allan W) wrote (abridged):

[snip]

> In C or C++, things get much tougher. When you multiply two unsigned
> longs, you get only one unsigned long in return. If you need the
> high-order bits, you have to multiply smaller types. If you know that
> longs are 32 bits and shorts are 16 bits, you can use them. You have
> to convert 16 bits at a time to unsigned long (with the high-order bits
> set to 0), do the multiply, then the low-order 16 bits is your result
> and the high-order 16 bits are your "carry."
>
> In Portable C++, you don't have much choice except the lowest
> common denominator. Use 8-bit numbers (stored in unsigned char),
> load them into unsigned long for the multiplication, and so on. SLOW!

Not quite true. C++ guarantees that 'unsigned short' can hold at least 16
bits, and that 'unsigned long' can hold at least 32 bits.

For that matter, if the 'unsigned int' type on your system uses an even
number of bits (I don't know of a system for which this is not true) - you
may be better off using that type, and writing a few inline functions that
split an 'unsigned int' in two. For example:


#include <limits>

template <typename T>
inline T LOHALF(T x)
{
    return x & ((1 << (std::numeric_limits<T>::digits / 2)) - 1);
}

template <typename T>
inline T HIHALF(T x)
{
    return x >> (std::numeric_limits<T>::digits / 2);
}


The advantage of using 'unsigned int' rather than 'unsigned long', for
example, is that 'unsigned int' is more likely to use the machine's
'natural' integer size, which should make calculations faster.


HTH,
Daniel Pfeffer


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net ("James Kuyper Jr.") writes:

| Gabriel Dos Reis wrote:
| > kuyper@wizard.net ("James Kuyper Jr.") writes:
| > |        . Previously strictly conforming use code that used int64_t
| > for
| > | some other purpose is now broken;
| > Do you know of any concrete one; or is it speculation?
|
| It's trivial to write an example of code that would break.

Please do.  Show us how that happens.

| Is that what you're asking for?

More or less.  As I said, I'm asking you a concrete real-world example
of code that broke.

| My point wasn't that such code is common. My point was that strictly
| conforming code which would have been broken by standardization of
| __int64 is absolutely guaranteed to be non-existent; a guarantee which
| doesn't exist for int64_t.

But, what is important is the validity of your claim.  Not its
potential validity in an imaginary world.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Witless wrote:
....
> Before this gets much sillier we should consider the implications of short
> short int.  My preference would be to interpret that as an int with a minimum
> width of 8 bits.  ...

Why would we need that? That's already provided by 'signed char'.

> ... Since a C++ char is not an integer type it is difficult to
> implement tiny arithmetic.  Short short ints would solve that problem (a
> problem that C does not have).

I'm not sure what you mean by that. 'char' is an integral type
(3.9.1p7), but I'll have to admit that it is not described as an integer
type. However, 'char' must have the same representation and same range
of values as either 'signed char', which is a signed integer type
(3.9.1p2) or 'unsigned char', which is an unsigned integer type
(3.9.1p3). When I need to do tiny arithmetic, I use either signed char
or unsigned char, not 'char', for improved portability. But that doesn't
seem to be what you mean.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Witless" <witless@attbi.com> wrote...
>
> Yes.  There are a number of physical values that require 64-bit
integers.

Are you sure? Certainly there are interesting values that require more
than 32-bits, but I can't think of any that require 64.

> Arithmetic over integers of size N usually requires integers of
> size 2N for the results of multiplication.  Sum of product routines
> typically require slightly more than 2N bits.
>
> So 128-bit integers make useful accumulators for 64-bit arithmetic.

...but are overkill if the values concerned are (say) 43-bit.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

SPAMstephen.howeGUARD@tnsofres.com ("Stephen Howe") writes:

> [someone wrote:]

>> Except, of course, the fact that it was a bad precedent, and one that
>> the C committee itself regretted being forced to accept.

I don't think that is a complete and accurate summary.

>Then I wish the committee has bit more courage. If an extension has crept
>into use by some compiler vendors, must the committee accept it in a
>forthcoming standard just because it is existing practice, especially if
>there are shortcomings?

No.

>If the committee feels a different approach has less shortcomings then it
>should strike in that direction.

The C committee has certainly been willing to define new features with
different syntax or semantics than that used by existing compilers.
For example, take a look at the treatment of inline in C99.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ken Alverson wrote:
> "Allan W" <allan_w@my-dejanews.com> wrote in message
> news:7f2735a5.0301101232.21b8e15d@posting.google.com...
>
>>brangdon@cix.co.uk (Dave Harris) wrote
>>
>>>Are there many real world problems that need 128-bit integers?
>>
>>Sure. How about a non-US application which needs the GDP of the United
>>States in Mexican Centavos (rather than Pesos, to avoid floating-point
>>math) or in Italian currency?
>
>
> US GDP in Mexican Centavos (approx):
>   10,641,590,130,605,220
> Gross World Product in Centavos (approx):
>   49,588,421,076,264,900
> Gross World Product in Italian Lire (approx):
>   86,059,192,289,472,048
> Maximum 128 bit value:
>   340,282,366,920,938,463,463,374,607,431,768,211,455
>
> I don't think we're going to run into problems with 128 bit money values
> in the near future.

The thing that determines whether you need a 128 bit type, is whether
the value will fit in a 64 bit that. The maximum 64-bit value. Assuming
a signed type, that's: 9,223,372,036,854,775,807. Of course, that is
still more than big enough to hold any of those numbers. But only by a
factor of about 100.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.de (James Kanze) writes:

| gdr@integrable-solutions.net (Gabriel Dos Reis) wrote in message
| news:<m34r8i99yh.fsf@uniton.integrable-solutions.net>...
| > kuyper@wizard.net ("James Kuyper Jr.") writes:
| >
| > |        . Previously strictly conforming use code that used int64_t for
| > | some other purpose is now broken;
| >
| > Do you know of any concrete one; or is it speculation?
|
|     $ grep 'int64_t' /usr/include/*.h /usr/include/*/*.h | wc -l
|     439
|
| under Solaris 2.8.  Or do you call that speculation?

Yes, because it completely eluded the original question.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ken Hagan wrote:

> "Witless" <witless@attbi.com> wrote...
> >
> > Yes.  There are a number of physical values that require 64-bit
> integers.
>
> Are you sure? Certainly there are interesting values that require more
> than 32-bits, but I can't think of any that require 64.
>
> > Arithmetic over integers of size N usually requires integers of
> > size 2N for the results of multiplication.  Sum of product routines
> > typically require slightly more than 2N bits.
> >
> > So 128-bit integers make useful accumulators for 64-bit arithmetic.
>
> ...but are overkill if the values concerned are (say) 43-bit.

If I had to manipulate 43-bit ints I would have much higher hopes for someday
having 128-bit accumulators than I would for 86-bit accumulators.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:
> kuyper@wizard.net ("James Kuyper Jr.") wrote in message
> news:<3E1CDEDF.3070702@wizard.net>...
>
>
>>Which would have made a name like __int64 a better choice for
>>standardization than the one that was actually chosen: int64_t.
>>Previously strictly conforming use code that used int64_t for some
>>other purpose is now broken; that would not have been the case if
>>they'd chosen __int64 instead.
>
>
> But only if it includes <stdint.h>.
>
> That's the mechanism that the C committee has chosen for protecting
> existing code.  Thus, they didn't introduce a keyword bool (which would
> have broken code having a user defined symbol bool), but rather _Bool;
> they then provide a header which makes bool synonomous with _Bool.
> Since existing code doesn't include this header, it doesn't break.
>
> I'm not sure to what degree I agree with this policy, but I certainly
> agree with the motivation behind it.

I agree that putting those definitions in a new header file makes the
new identifiers a lot safer. But they would have been even safer if
they'd been names reserved to the implementation, rather than ones that
had previously been reserved exclusively for the user.

There's a key difference. You can use _Bool rather than bool in a C99
program without #including a new header. That was made possible by the
fact that _Bool came from the list of names reserved to the
implementation. You can't use any of the <stdint.h> types without
#including that header.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:
> kuyper@wizard.net ("James Kuyper Jr.") writes:
>
> | Gabriel Dos Reis wrote:
> | > kuyper@wizard.net ("James Kuyper Jr.") writes:
> | > |          Previously strictly conforming use code that used int64_t
> | > for
> | > | some other purpose is now broken; that would not have been the case if
> | > | they'd chosen __int64 instead.
> | > How does not necessarily follow.  For example, there were existing
> | > pratice for bool, but the C committee choosed to invent the _Bool plus
> | > macros.  There have been existing pratice for __inline, the C
> | > committee choosed "inline".
> |
> | Yes, strictly speaking what I said can't happen, since int64_t is
> | defined only for code that directly or indirectly #includes
> | <stdint.h>; such code would not have been strictly conforming under
> | C90.
>
> Exactly; that *is* my point.

But that's not the point that I'm worried about.

> | However, there could be strictly conforming code which would be broken
> | by pre-pending #include <stdint.h>.
>
> But such program couldn't have existed before C99.

My point is that strictly conforming code written before C99 could have
been written to use int64_t in a manner that would make the code break
when someone decided they wanted to modify it for C99 by inserting
"#include <stdint.h>". If the committee had chosen __int64 instead of
int64_t, that wouldn't be a possibility.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net ("James Kuyper Jr.") writes:

| Gabriel Dos Reis wrote:
| > kuyper@wizard.net ("James Kuyper Jr.") writes:
| > | Gabriel Dos Reis wrote:
| > | > kuyper@wizard.net ("James Kuyper Jr.") writes:
| > | > |          Previously strictly conforming use code that used int64_t
| > | > for
| > | > | some other purpose is now broken; that would not have been the case if
| > | > | they'd chosen __int64 instead.
| > | > How does not necessarily follow.  For example, there were existing
| > | > pratice for bool, but the C committee choosed to invent the _Bool plus
| > | > macros.  There have been existing pratice for __inline, the C
| > | > committee choosed "inline".
| > | | Yes, strictly speaking what I said can't happen, since int64_t is
| > | defined only for code that directly or indirectly #includes
| > | <stdint.h>; such code would not have been strictly conforming under
| > | C90.
| > Exactly; that *is* my point.
|
| But that's not the point that I'm worried about.

But a program that gets modified after C99 is -not- the same program,
hence it is not right to claim that the program has been
broken because the C committee added int64_t to the language.  No.
The program has been broken by that someone who carelessly modified
it by including <stdint.h>.

| > | However, there could be strictly conforming code which would be broken
| > | by pre-pending #include <stdint.h>.
| > But such program couldn't have existed before C99.
|
| My point is that strictly conforming code written before C99 could
| have been written to use int64_t in a manner that would make the code
| break when someone decided they wanted to modify it for C99 by
| inserting "#include <stdint.h>".

Well, firstly, that is not what you wrote in your initial message
which is still quoted.

Secondly, I've yet to see real-word programs that have been brkoen
because someone willy-nilly added <stdint.h> -- I guess if that
someone added <stdint.h> then he knew what he is doing, in particular,
he knew what the assumptions of the program he is rying to modify.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> "Witless" <witless@attbi.com> wrote...
> > So 128-bit integers make useful accumulators for 64-bit arithmetic.

K.Hagan@thermoteknix.co.uk ("Ken Hagan") wrote
> ...but are overkill if the values concerned are (say) 43-bit.

They are only "overkill" if there's a smaller value that would
be sufficient. Perhaps you'd like to see an 86-bit integer? Or
are you assuming that multiples of 32 will abound, and we can
just pull up a 96-bit integer, which would be (after all) smaller
than 128-bits?

On platforms that use 32 bits internally, a 96-bit integer is just
as easy to create as a 128-bit integer, and potentially 25% faster.
On platforms that use 64 bits internally, the reverse is true.
I'm starting to warm to the C typedefs, so that you can explicitly
ask for the smallest integer with at least 86 bits, or else the
fastest one, depending on the situation.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) wrote (abridged):
> > Are there many real world problems that need 128-bit integers?
>
> Sure. [various examples]

Even for those, I think I would be more comfortable with arbitrary
precision integers. These would be guaranteed available, albeit
implemented in software rather than hardware on some platforms. They would
be more portable and more extendable, if I ever found even 128 bits wasn't
enough.


> > Most uses are either (a) are not really integers; or (b) not
> > really fixed-size.
> >
> > Examples of (a) include pointers
>
> Perhaps these aren't really integers, but that doesn't mean we don't
> need to do math with them. If your array starts at virtual address
> 0x400000012EFF0000, each element is 256 bytes, and you want the
> fourth element... you need SOME way to come up with the virtual
> address 0x400000012EFF0030.

Indeed. I think pointers are what has driven the need for 64-bit
arithmetic in hardware. 32-bits isn't enough address space. And once you
have 64-bit arithmetic for pointers you might as well make it available
for integers.

Even though there are some uses for 128-bit arithmetic, I don't think they
are as compelling as pointer arithmetic. In other words, I don't think we
will see 128-bit integer maths in hardware until we have 128-bit address
spaces. And I am not sure that will ever make sense. I am not saying we
won't need to address that much, but rather, I wonder whether a segmented
architecture in which arithmetic is only done on the low 64 bits may be
better use of hardware.


> Furthermore, if the hardware has a way to multiply two longs and
> return the entire result, and you don't take advantage of it, you
> won't be taking maximum advantage of your platform. The proper place
> for code that "knows" things like that, is in the Standard C++
> library that comes with each compiler.

Sure. I am not sure if it is worth adding 128-bit ints to the language
just to help implement arbitrary precision libraries. Rather, such a
library should be put into the standard. Then it can be implemented in
assembler using whatever facilities the host machine offers.

(Which are probably better for not being obscured by C++. Eg many machines
have 32x32 => 64, but C++ only has 32x32 => 32 and 64x64 => 64.)

I suppose it may ultimately be a matter of keeping up with the Joneses.
C++ aims to leave no room for a lower level language, other than
assembler. So if some hardware has 128-bit ints, and some other language
adds direct support for them, C++ must have them too.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Gabriel Dos Reis" <gdr@integrable-solutions.net> wrote in message
news:m365sxyy9e.fsf@uniton.integrable-solutions.net...
> kuyper@wizard.net ("James Kuyper Jr.") writes:
>
> | Gabriel Dos Reis wrote:
> | > kuyper@wizard.net ("James Kuyper Jr.") writes:
> | > |        . Previously strictly conforming use code that used int64_t
> | > for
> | > | some other purpose is now broken;
> | > Do you know of any concrete one; or is it speculation?
> |
> | It's trivial to write an example of code that would break.
>
> Please do.  Show us how that happens.


int main() { int int64_t(0); }

It's strictly conforming -- the name int64_t isn't reserved in the current
standard -- and it'll break if a type named int64_t is introduced.

On the other hand,
int main() { int __int64(0); }
isn't strictly conforming -- the name __int64 is reserved, so one shouldn't
use it.  The introduction of a type __int64 will break the code, but that's
one price you pay for using reserved names.

If you state that the new type names require a particular header to be
included you can reduce the problem, by offering people a set of tradeoffs;
either they have the new types or they risk breaking existing code.

How much this matters, I don't know.  Personally, I don't think that language
designers should shy away from introducing breaking changes -- I'm confident
that compiler developers will provide the tools required to ease the
transition (for instance, many compilers offer both pre-standardization
scoping of variables declared in for loops, and the standard behaviour).
Fixed-size integers as well as larger integers are desirable additions.

"long long" is horrible, though.  I am somewhat disappointed that VC++ 7.1
supports it; I think that it is largely without merit.

--
Now Playing:  Bianco & Bavaglio - Sweet tears

char a[99999],*p=a;main(int c,char**V){char* v=c>0?1[V]:V;if(c<0)for(c=1;c;c
+=!(91^*v)-!(93^*v),++v);else for(;(c=*v)&&93^c;p+=!(62^c)-!(60^c),*p+=!(43^
c)-!(45^c),44^c||read(0,p,1),46^c||putchar(*p),91^c||(v=*p?main(0,++v),v-2:\
main(-1,++v)-1),++v);return v;}/*bf prog as argv[1]. drpizza@battleaxe.net*/


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

drpizza@anti-flash.co.uk ("DrPizza") writes:

| "Gabriel Dos Reis" <gdr@integrable-solutions.net> wrote in message
| news:m365sxyy9e.fsf@uniton.integrable-solutions.net...
| > kuyper@wizard.net ("James Kuyper Jr.") writes:
| >
| > | Gabriel Dos Reis wrote:
| > | > kuyper@wizard.net ("James Kuyper Jr.") writes:
| > | > |        . Previously strictly conforming use code that used int64_t
| > | > for
| > | > | some other purpose is now broken;
| > | > Do you know of any concrete one; or is it speculation?
| > |
| > | It's trivial to write an example of code that would break.
| >
| > Please do.  Show us how that happens.
|
|
| int main() { int int64_t(0); }

As you may notice, the above isn't borken by C99 addition since it
isn't even a valid program.

| It's strictly conforming

No: it uses an undeclared name.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Witless" <witless@attbi.com> wrote...
>
> If I had to manipulate 43-bit ints I would have much higher
> hopes for someday having 128-bit accumulators than I would
> for 86-bit accumulators.

Yes, but my point was that you could use a 64-bit accumulator,
unless you had an *awful* lot of them to add up.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:
> kuyper@wizard.net ("James Kuyper Jr.") writes:
>
> | Gabriel Dos Reis wrote:
> | > kuyper@wizard.net ("James Kuyper Jr.") writes:
> | > |        . Previously strictly conforming use code that used int64_t
> | > for
> | > | some other purpose is now broken;
> | > Do you know of any concrete one; or is it speculation?
> |
> | It's trivial to write an example of code that would break.
>
> Please do.  Show us how that happens.

I'm sorry, I missed your point. It was indeed speculation. I don't know
of a single real world example of strictly conforming C code, of any
kind, much less of this specific kind. I sort of assumed that you would
see the phrase "strictly conforming" and realize that this inherently
means that I wasn't talking about real world examples. I'm sorry - we're
talking about the C standard in the C++ newsgroup, and "strictly
conforming" is a piece of C standard jargon which the C++ standard
didn't borrow. The closest equivalent in C++ is "well-formed code", but
that's a far more lenient conformance category than "strictly conforming".

That doesn't mean that there aren't any real world examples; there
certainly could be, but I don't personally know of any. The fact that
there COULD be real world examples is enough to worry me, and it was
that worry which I was expressing. Using __int64 instead of int64_t
would have been sufficient to eliminate that worry.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ken@Alverson.net ("Ken Alverson") wrote
> "Allan W" <allan_w@my-dejanews.com> wrote
> > brangdon@cix.co.uk (Dave Harris) wrote
> > > Are there many real world problems that need 128-bit integers?
> >
> > Sure. How about a non-US application which needs the GDP of the United
> > States in Mexican Centavos (rather than Pesos, to avoid floating-point
> > math) or in Italian currency?
>
> US GDP in Mexican Centavos (approx):
>   10,641,590,130,605,220
> Gross World Product in Centavos (approx):
>   49,588,421,076,264,900
> Gross World Product in Italian Lire (approx):
>   86,059,192,289,472,048
> Maximum 128 bit value:
>   340,282,366,920,938,463,463,374,607,431,768,211,455
  Maximum 64-bit signed value:
    9,223,372,036,854,775,807

  9,223,372,036,854,775,807 / 86,059,192,289,472,048:
    107.17

We'll use your numbers, and assume that Italian Lire remain
the lowest commonly-used currency (a big assumption). If the
GWP doubles every 5 years, then within 3 decades it will have
overflowed 32-bits of Italian Lire. 128-bit numbers have no
such problem.

> I don't think we're going to run into problems with
> 128 bit money values in the near future.

Depends on what you mean by "near future." That type of thinking
in the 1970's lead to big problems with dates in the late 1990's,
and it's already going to lead to similar date problems prior to
year 2038.

My first computer job was for a real-estate database in Los
Angeles in 1976. At the time, we had about 10,000 homes for sale,
including about 3 for over $1 million. Those three were entered
in our database as selling for $999999, with notes in the
"remarks" section telling what the real price was. Within two
years 10% of the homes had prices over $1 million, and we could
no longer handle the process this way; we simply had to have
another digit. (We were wise enough to add 3, not just 1.)

When IBM stopped ignoring the desktop computer market, they
decided to use an existing chip (the 8086) to shorten their
time-to-market. The 8086 had 65535 bytes of IO addresses and
1 million bytes of RAM address. IBM wanted their first display
monitor to have it's display memory directly accessible to the
CPU. Rather than use the IO space, they divided the RAM space
in half, on the grounds that no desktop computer would ever
need more than half a meg of RAM. Today, a desktop computer
with less than 32 Meg has limited usefulness.

The one common thread in all of these stories is, no matter how
much space you think you need -- you really need more.

"Data expands to fill available media"
-- one of the correlaries to Murphy's Law

> > How about a U.S. bank? In the U.S., banks are required to
> > keep balances to 5 decimal places, and some accounts have
> > billions of dollars. Floating point balances can lose
> > accuracy, and besides that if you're processing 10,000,000
> > checks per day a 1-millisecond delay per check adds up to
> > 2.5 hours per day.
> >
> > How about astronomical calculations? For some work in
> > astronomy, a date/time with a 4-digit year and hh:mm:ss
> > just isn't good enough. Sometimes they want microseconds
> > or even nanoseconds; other times, they want a span of many
> > thousands or even millions of years. A unified date/time
> > system that meets all of that would just about fit in 128 bits.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis schrieb:

>
> Secondly, I've yet to see real-word programs that have been brkoen
> because someone willy-nilly added <stdint.h> -- I guess if that
> someone added <stdint.h> then he knew what he is doing, in particular,
> he knew what the assumptions of the program he is rying to modify.

Why do you assume someone even knew that <stdint.h> was #included?
You'd have to recursively check all #included files what they are in turn
#including.


regards,

Thomas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

brangdon@cix.co.uk (Dave Harris) wrote in message
news:<memo.20030112182458.39435C@brangdon.madasafish.com>...
> allan_w@my-dejanews.com (Allan W) wrote (abridged):
> > > Are there many real world problems that need 128-bit integers?

> > Sure. [various examples]

> Even for those, I think I would be more comfortable with arbitrary
> precision integers. These would be guaranteed available, albeit
> implemented in software rather than hardware on some platforms. They
> would be more portable and more extendable, if I ever found even 128
> bits wasn't enough.

> > > Most uses are either (a) are not really integers; or (b) not
> > > really fixed-size.

> > > Examples of (a) include pointers

> > Perhaps these aren't really integers, but that doesn't mean we don't
> > need to do math with them. If your array starts at virtual address
> > 0x400000012EFF0000, each element is 256 bytes, and you want the
> > fourth element... you need SOME way to come up with the virtual
> > address 0x400000012EFF0030.

> Indeed. I think pointers are what has driven the need for 64-bit
> arithmetic in hardware.

More than pointers in memory, I think it is offsets in disk files
(although machines with more than 4 GB virtual memory aren't that
extraordinary either).  32 bits ceased being sufficient the day they
brought out disk drives with more than 2 GB.

> 32-bits isn't enough address space. And once you have 64-bit
> arithmetic for pointers you might as well make it available for
> integers.

Most systems use an integral type for disk offsets.  Posix requires it,
I believe.  Still, I don't think that it will be anytime soon that 64
bits ceases to suffice for this.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) wrote (abridged):
> The one common thread in all of these stories is, no matter how
> much space you think you need -- you really need more.

Yes. In my view that's an argument against 128-bit int and in favour of
arbitrary-sized int and variable-sized int.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:
> kuyper@wizard.net ("James Kuyper Jr.") writes:
>
> | Gabriel Dos Reis wrote:
> | > kuyper@wizard.net ("James Kuyper Jr.") writes:


> But a program that gets modified after C99 is -not- the same program,

It's part of the same family. At work, I've been working on what I think
of as the same program for the past 6 years. Technically, the way you're
describing it, it's actually been several dozen different programs over
that time. However, the core functionality of that program is the same
that it's always been. Therefore, I think it's more reasonable to think
of it as retaining the same basic identity, despite bug fixes and upgrades.

> hence it is not right to claim that the program has been
> broken because the C committee added int64_t to the language.  No.
> The program has been broken by that someone who carelessly modified
> it by including <stdint.h>.

The C committee is fully responsible for the fact that it takes a lot
more care to insert <stdint.h> than it would have taken if different
names had been chosen.

> | > | However, there could be strictly conforming code which would be broken
> | > | by pre-pending #include <stdint.h>.
> | > But such program couldn't have existed before C99.
> |
> | My point is that strictly conforming code written before C99 could
> | have been written to use int64_t in a manner that would make the code
> | break when someone decided they wanted to modify it for C99 by
> | inserting "#include <stdint.h>".
>
> Well, firstly, that is not what you wrote in your initial message
> which is still quoted.

The "strictly conforming" in my original statement modifies the code as
it existed BEFORE pre-pending "#include <stdint.h>". I've since found
clearer ways of saying what I meant, but those ways are still consistent
with my original statement.

> Secondly, I've yet to see real-word programs that have been brkoen

As I said, I don't have any such programs, and the validity of my point
is independent of whether or not there are any. However, it would
certainly strengthen my point if someone could come up with an example.

I was hopeful for a moment when I saw James Kanze's message, but all
that he demonstrated was that the standard library headers in Solaris
2.8 use int64_t. He failed to demonstrate

a) that those headers use it in a manner incompatible with <stdint.h>. I
wouldn't be surprised to find that they were there as a result of
implementing <stdint.h> as an extension to C90.

b) that those uses of int64_t would even survive pre-processing, when
code is compile in what is supposed to be a fully conforming mode. I
would expect them to be conditionally compiled, and to not be compiled
in such a mode. They shouldn't be, because under C90, they would have
infringed on the set of names reserved to the user.

c) that there is code which would break as a result

....
> because someone willy-nilly added <stdint.h> -- I guess if that
> someone added <stdint.h> then he knew what he is doing, in particular,
> he knew what the assumptions of the program he is rying to modify.

If the new types had been named differently, the programmer would have
had a lot fewer things to check before inserting that header. That's my
point.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net ("James Kuyper Jr.") writes:

[...]

| > because someone willy-nilly added <stdint.h> -- I guess if that
| > someone added <stdint.h> then he knew what he is doing, in particular,
| > he knew what the assumptions of the program he is rying to modify.
|
| If the new types had been named differently, the programmer would have
| had a lot fewer things to check before inserting that header. That's
| my point.

This, I can agree with.  But it is curious to note how the discussion
has shifted from "long long" to "int64_t", which both have been added to
the language in a way that could not have broken a valid program.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

gdr@integrable-solutions.net (Gabriel Dos Reis) wrote
> kuyper@wizard.net ("James Kuyper Jr.") writes:
>
> [...]
>
> | > because someone willy-nilly added <stdint.h> -- I guess if that
> | > someone added <stdint.h> then he knew what he is doing, in particular,
> | > he knew what the assumptions of the program he is rying to modify.
> |
> | If the new types had been named differently, the programmer would have
> | had a lot fewer things to check before inserting that header. That's
> | my point.
>
> This, I can agree with.  But it is curious to note how the discussion
> has shifted from "long long" to "int64_t", which both have been added to
> the language in a way that could not have broken a valid program.

int64_t certainly could (theoretically) have broken a valid program!

    int main() {
        for (int int64_t=0; int64_t<10; ++int64_t)
            std::cout << int64_t;
        }
    }

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:
> kuyper@wizard.net ("James Kuyper Jr.") writes:
>
> |        . Previously strictly conforming use code that used int64_t for
> | some other purpose is now broken;
>
> Do you know of any concrete one; or is it speculation?

It's trivial to write an example of code that would break. Is that what
you're asking for? I doubt that there's any real life examples.

My point wasn't that such code is common. My point was that strictly
conforming code which would have been broken by standardization of
__int64 is absolutely guaranteed to be non-existent; a guarantee which
doesn't exist for int64_t.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:
> kuyper@wizard.net ("James Kuyper Jr.") writes:
>
> |          Previously strictly conforming use code that used int64_t for
> | some other purpose is now broken; that would not have been the case if
> | they'd chosen __int64 instead.
>
> How does not necessarily follow.  For example, there were existing
> pratice for bool, but the C committee choosed to invent the _Bool plus
> macros.  There have been existing pratice for __inline, the C
> committee choosed "inline".

Yes, strictly speaking what I said can't happen, since int64_t is
defined only for code that directly or indirectly #includes <stdint.h>;
such code would not have been strictly conforming under C90.

However, there could be strictly conforming code which would be broken
by pre-pending #include <stdint.h>. That's wouldn't have been even a
remote possibility if __int64 had been standardized instead.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:

> So you would prefer "long long long" to __int128.

Before this gets much sillier we should consider the implications of short
short int.  My preference would be to interpret that as an int with a minimum
width of 8 bits.  Since a C++ char is not an integer type it is difficult to
implement tiny arithmetic.  Short short ints would solve that problem (a
problem that C does not have).

That leaves short short short int for BCD arithmetic.

But long long long is _very_quickly_ going to become lllong.  Ant the longer
(sorry) the type name becomes the more interest there will be in
abbreviations.  Normalizing the name so that the width of the type in bits is
2^(repeat factor) would exacerbate the need for abbreviations.

For the above reasons I support the concept of templates for findamental
types such as int<32>.

;-)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Dave Harris wrote:

> scottm@toast.net ("Scott Mayo") wrote (abridged):
> > The good news is that I think after 256 bit hardware integers arrive,
> > we'll be done growing integers for at least a few decades. There are
> > not too many real world problems that need integers larger than that...
>
> Are there many real world problems that need 128-bit integers?

Yes.  There are a number of physical values that require 64-bit integers.
Arithmetic over integers of size N usually requires integers of size 2N for
the results of multiplication.  Sum of product routines typically require
slightly more than 2N bits.

So 128-bit integers make useful accumulators for 64-bit arithmetic.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

gdr@integrable-solutions.net (Gabriel Dos Reis) wrote in message
news:<m34r8i99yh.fsf@uniton.integrable-solutions.net>...
> kuyper@wizard.net ("James Kuyper Jr.") writes:
>
> |        . Previously strictly conforming use code that used int64_t for
> | some other purpose is now broken;
>
> Do you know of any concrete one; or is it speculation?

    $ grep 'int64_t' /usr/include/*.h /usr/include/*/*.h | wc -l
    439

under Solaris 2.8.  Or do you call that speculation?

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.de (James Kanze) writes:

| gdr@integrable-solutions.net (Gabriel Dos Reis) wrote in message
| news:<m3n0mbahx2.fsf@uniton.integrable-solutions.net>...
|
| > | I'm not sure of your point. The use of __int64 has two advantages
| > | with regards to long long: it is standards conforming, and it is
| > | clearly extensible to even more integral types.
|
| > What is standard conforming about __int64?
|
| A compiler which implements __int64, and doesn't emit a diagnostic when
| it is used, is standard conforming.

Sure , but a program that uses __int64 first invokes undefined
behaviour.  As such there is no point in talking about "__int64" being
more standard conformant.

| > It is an identifier reserved to implementations. The effect of ussing
| > such identifier in a C++ (or C) program is not explicitly described by
| > the standard, which means undefined behaviour.
|
| Which means that the implementation has a right to define it.

and also has the right not to define it and do whatever it likes with
the code.  The program that uses __int64 cannot possibly expecting a
standard conformant semantics in the first place.

| > __int64 is a *fixed* identifier, in that way it certainly isn't
| > extensible.
|
| > On the other hand, the repetition of "long", in a type specifier, to
| > suggest the minimum of bit length however is extensible (although for
| > C++, I really prefer a solution based on template-id).
|
| So you would prefer "long long long" to __int128.

"long long long" is not template-id.  See what I wrote.

| The members of the C standards committee apparently didn't agree with
| you.

For that I should have made such a proposal and submit it.

[...]

| > | > GCC, to name one compiler that uses "long long", can be instructed
| > | > to diagnose or not "long long"; so your point is moot.
|
| > | Moot in what sense. I never made the slightest comment concerning
| > | gcc
|
| > Certainly, you didn't make a direct comment concerning gcc.  But as
| > stated in the part of the message you're replying to, it is an
| > instance of your *"But a lot of others"*.
|
| I was unaware that gcc accepted "long long" before it was standardized.

No worry.  Now you know ;-)

| It was certainly not gcc which created the pressure to adopt it.

This comment would have had a relevance to the issue at hand, did someone
say GCC created the pressure to adopt it.  But nobody did; so what it
is its relevance?

|    [...]
| > | We went through all of this discussion in the C committee.
|
| > So what?
|
| It's true that you weren't yet active in standardization at the time, so
| we couldn't have done any work of value.

You weren't in the room when Antoine Leca and the rest of the AFNOR
group discussed (at multiple times) "long long".  I was there.

| > And in the French national body, I was against this solution -- and
| > yes, we changed our "no" vote.
|
| When the actual discussions were taking place, you weren't yet active in
| the standardization effort.

Sure I was there when we discussed the issue with Antoine Leca
(on multiple occasions) and he exposed the compromise that was
proposed.  But you weren't in France, nor in AFNOR. Just go and check
out (ask Antoine LEca for example).

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

witless@attbi.com (Witless) writes:

| James Kanze wrote:
|
| > So you would prefer "long long long" to __int128.
|
| Before this gets much sillier we should consider the implications of short
| short int.

I guess what is silly about that sentence is that it is written as a
respone to:

  (although for C++, I really prefer a solution based on template-id).

| For the above reasons I support the concept of templates for findamental
| types such as int<32>.

Or a typedef-template :-)

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

brangdon@cix.co.uk (Dave Harris) wrote
> Are there many real world problems that need 128-bit integers?

Sure. How about a non-US application which needs the GDP of the United
States in Mexican Centavos (rather than Pesos, to avoid floating-point
math) or in Italian currency?

How about a U.S. bank? In the U.S., banks are required to keep balances
to 5 decimal places, and some accounts have billions of dollars. Floating
point balances can lose accuracy, and besides that if you're processing
10,000,000 checks per day a 1-millisecond delay per check adds up to
2.5 hours per day.

How about astronomical calculations? For some work in astronomy, a
date/time with a 4-digit year and hh:mm:ss just isn't good enough.
Sometimes they want microseconds or even nanoseconds; other times,
they want a span of many thousands or even millions of years. A
unified date/time system that meets all of that would just about
fit in 128 bits.

> Most uses
> are either (a) are not really integers; or (b) not really fixed-size.
>
> Examples of (a) include pointers

Perhaps these aren't really integers, but that doesn't mean we don't
need to do math with them. If your array starts at virtual address
0x400000012EFF0000, each element is 256 bytes, and you want the
fourth element... you need SOME way to come up with the virtual
address 0x400000012EFF0030.

> or internet addresses.
Did you know that old-style internet addresses sometimes combine terms?
The address 207.46.249.190 could also be expressed as 207.46.63934,
207.3078590, or even 3475962302. The address
    http://347596203
should be equivalent to
    http://207.46.249.190
on most browsers.

> Examples of (b)
> crop up in encryption - for that you certainly want integers bigger than
> 128 bits, but 256 bits isn't enough either. Nor is 2048 bits. I hope a
> future C++ standard will offer arbitrary and/or variable length integers.

For this, I agree with you.

Efficient implementation of multiple-precision integer multiplication
requires knowledge of the largest number of bits that the hardware can
multiply at once. Theoretically you could write a multiple-precision
integer multiplication using only bit-shifting and addition. This would
portably work for any size of unsigned integer, but it would be
unbearably slow. You can do much better by multiplying two ints to get
a long, but only if you know (or non-portably assume) that MAX_UINT
squared is less than MAX_ULONG. Furthermore, if the hardware has a way
to multiply two longs and return the entire result, and you don't take
advantage of it, you won't be taking maximum advantage of your platform.
The proper place for code that "knows" things like that, is in the
Standard C++ library that comes with each compiler.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Allan W" <allan_w@my-dejanews.com> wrote in message
news:7f2735a5.0301101232.21b8e15d@posting.google.com...
> brangdon@cix.co.uk (Dave Harris) wrote
> > Are there many real world problems that need 128-bit integers?
>
> Sure. How about a non-US application which needs the GDP of the United
> States in Mexican Centavos (rather than Pesos, to avoid floating-point
> math) or in Italian currency?

US GDP in Mexican Centavos (approx):
  10,641,590,130,605,220
Gross World Product in Centavos (approx):
  49,588,421,076,264,900
Gross World Product in Italian Lire (approx):
  86,059,192,289,472,048
Maximum 128 bit value:
  340,282,366,920,938,463,463,374,607,431,768,211,455

I don't think we're going to run into problems with 128 bit money values
in the near future.

Ken


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Stephen Howe wrote:
>>Except, of course, the fact that it was a bad precedent, and one that
>>the C committee itself regretted being forced to accept.
>
>
> Then I wish the committee has bit more courage. If an extension has crept
> into use by some compiler vendors, must the committee accept it in a
> forthcoming standard just because it is existing practice, especially if
> there are shortcomings?
>
> If the committee feels a different approach has less shortcomings then it
> should strike in that direction.

I agree with you on that, but I'm not a committee member. The committee
members that would have agreed with you on this weren't sufficiently
influential to change the decision.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3E1E704E.2A92C7E5@attbi.com>, Witless <witless@attbi.com>
writes
>Before this gets much sillier we should consider the implications of short
>short int.  My preference would be to interpret that as an int with a minimum
>width of 8 bits.  Since a C++ char is not an integer type it is difficult to
>implement tiny arithmetic.

3.9.1 para 7 says otherwise.

> Short short ints would solve that problem (a
>problem that C does not have).

Even short does not solve the problem because char and short types are
first promoted to int before arithmetic is done.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net ("James Kuyper Jr.") writes:

| Gabriel Dos Reis wrote:
| > kuyper@wizard.net ("James Kuyper Jr.") writes:
| > |          Previously strictly conforming use code that used int64_t
| > for
| > | some other purpose is now broken; that would not have been the case if
| > | they'd chosen __int64 instead.
| > How does not necessarily follow.  For example, there were existing
| > pratice for bool, but the C committee choosed to invent the _Bool plus
| > macros.  There have been existing pratice for __inline, the C
| > committee choosed "inline".
|
| Yes, strictly speaking what I said can't happen, since int64_t is
| defined only for code that directly or indirectly #includes
| <stdint.h>; such code would not have been strictly conforming under
| C90.

Exactly; that *is* my point.

| However, there could be strictly conforming code which would be broken
| by pre-pending #include <stdint.h>.

But such program couldn't have existed before C99.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net ("James Kuyper Jr.") wrote in message
news:<3E1CDEDF.3070702@wizard.net>...

> Which would have made a name like __int64 a better choice for
> standardization than the one that was actually chosen: int64_t.
> Previously strictly conforming use code that used int64_t for some
> other purpose is now broken; that would not have been the case if
> they'd chosen __int64 instead.

But only if it includes <stdint.h>.

That's the mechanism that the C committee has chosen for protecting
existing code.  Thus, they didn't introduce a keyword bool (which would
have broken code having a user defined symbol bool), but rather _Bool;
they then provide a header which makes bool synonomous with _Bool.
Since existing code doesn't include this header, it doesn't break.

I'm not sure to what degree I agree with this policy, but I certainly
agree with the motivation behind it.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.de (James Kanze) wrote
> And if long long gives you a guaranteed 64 bit type, how to you specify
> a guaranteed 128 bit type, when the need arises.

long long long?

Then a 256-bit type would be long long long long, and
a 512-bit type would be long long long long long, and
pretty soon we have Monty Python's "spam, spam, spam" sketch.

Hmm... makes me long (no pun intended) for Fortran. How about:

    int_minbits<128> bignum; // A signed integer type with at least 256 bits
    int_maxbits<256> bignum2; // No more than 256 bits
    int_exactbits<256> bignum3; // Exactly 256 bits, or else a compile error

The flavor of C's new typedefs, but in a more C++-friendly fashion...?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:
> kanze@gabi-soft.de (James Kanze) writes:
....
> |  The C99 standard adopted long
> | long because of existing practice, but they also provide an intelligent
> | framework for further extensions.  Along the lines of __int64.
>
> But __int64 framework isn't more intelligent.  That framework isn't even
> extensible.

He said "along the lines of". What he's referring to are the new
identifiers defined in <stdint.h>. Those names are definitely
extensible, and in exactly the same sense that __int64 would have been,
had they instead chosen to use that name. In C99, all names of the form
int#_t, where # is some positive integer, are reserved for this kind of
use. The same applies to all of the other families of identifiers
defined in <stdint.h>.

....
> | The symbol __int64 results in undefined behavior
> | according to the standard; one of the purposes of undefined behavior is
> | precisely to allow implementation defined extensions such as this.
>
> And there is no obligation that the implementation, in fact, does
> anything sensible with __int64.

Which would have made a name like __int64 a better choice for
standardization than the one that was actually chosen: int64_t.
Previously strictly conforming use code that used int64_t for some other
purpose is now broken; that would not have been the case if they'd
chosen __int64 instead.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>> jackklein@spamcop.net (Jack Klein) wrote in message news:<ak8f1vsvp8dd0uevgmt3dbpnqujls4uabc@4ax.com>...
>>
>>>Not that I'm a member of either the C or C++ standards committee, but
>>>I really dislike "long long", even though it was mentioned in the
>>>appendix of ISO C90 as an already existing common extension.

Now I'm sad I didn't submit my proposal at the time:

1.  fix long = 32 bits, short = 16 bits.
2.  add the keyword "extra".  Each use of the keyword doubles
    the magnitude of the base type.

So an "extra long" = 64 bits, and an "extra extra long" = 128 bits.
Going the other way, an "extra short" is the oft desired 8 bit integer,
and "extra extra extra extra short" would pretty much make "bool"
obsolete. ;)

--
Mark Harrison
Pixar Animation Studios
in fashionable Emeryville, CA

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net ("James Kuyper Jr.") writes:

|        . Previously strictly conforming use code that used int64_t for
| some other purpose is now broken;

Do you know of any concrete one; or is it speculation?

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net ("James Kuyper Jr.") writes:

|          Previously strictly conforming use code that used int64_t for
| some other purpose is now broken; that would not have been the case if
| they'd chosen __int64 instead.

How does not necessarily follow.  For example, there were existing
pratice for bool, but the C committee choosed to invent the _Bool plus
macros.  There have been existing pratice for __inline, the C
committee choosed "inline".

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

gdr@integrable-solutions.net (Gabriel Dos Reis) wrote in message
news:<m3n0mbahx2.fsf@uniton.integrable-solutions.net>...

> | I'm not sure of your point. The use of __int64 has two advantages
> | with regards to long long: it is standards conforming, and it is
> | clearly extensible to even more integral types.

> What is standard conforming about __int64?

A compiler which implements __int64, and doesn't emit a diagnostic when
it is used, is standard conforming.

> It is an identifier reserved to implementations. The effect of ussing
> such identifier in a C++ (or C) program is not explicitly described by
> the standard, which means undefined behaviour.

Which means that the implementation has a right to define it.

> __int64 is a *fixed* identifier, in that way it certainly isn't
> extensible.

> On the other hand, the repetition of "long", in a type specifier, to
> suggest the minimum of bit length however is extensible (although for
> C++, I really prefer a solution based on template-id).

So you would prefer "long long long" to __int128.

The members of the C standards committee apparently didn't agree with
you.

> |  The C99 standard adopted long long because of existing practice,
> | but they also provide an intelligent framework for further
> | extensions. Along the lines of __int64.

> But __int64 framework isn't more intelligent. That framework isn't
> even extensible.

The C standards extended it (without the __, of course).

> | > GCC, to name one compiler that uses "long long", can be instructed
> | > to diagnose or not "long long"; so your point is moot.

> | Moot in what sense. I never made the slightest comment concerning
> | gcc

> Certainly, you didn't make a direct comment concerning gcc.  But as
> stated in the part of the message you're replying to, it is an
> instance of your *"But a lot of others"*.

I was unaware that gcc accepted "long long" before it was standardized.
It was certainly not gcc which created the pressure to adopt it.

   [...]
> | We went through all of this discussion in the C committee.

> So what?

It's true that you weren't yet active in standardization at the time, so
we couldn't have done any work of value.

> And in the French national body, I was against this solution -- and
> yes, we changed our "no" vote.

When the actual discussions were taking place, you weren't yet active in
the standardization effort.

> |  Long long is an abomination, fostered upon us by a certain number
> | of Unix compilers.

> Thanks, I know that often repeated assertion.

It was the consensus of the C standards committee, at any rate.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> Except, of course, the fact that it was a bad precedent, and one that
> the C committee itself regretted being forced to accept.

Then I wish the committee has bit more courage. If an extension has crept
into use by some compiler vendors, must the committee accept it in a
forthcoming standard just because it is existing practice, especially if
there are shortcomings?

If the committee feels a different approach has less shortcomings then it
should strike in that direction.

Stephen Howe


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

scottm@toast.net ("Scott Mayo") wrote (abridged):
> The good news is that I think after 256 bit hardware integers arrive,
> we'll be done growing integers for at least a few decades. There are
> not too many real world problems that need integers larger than that...

Are there many real world problems that need 128-bit integers? Most uses
are either (a) are not really integers; or (b) not really fixed-size.

Examples of (a) include pointers or internet addresses. Examples of (b)
crop up in encryption - for that you certainly want integers bigger than
128 bits, but 256 bits isn't enough either. Nor is 2048 bits. I hope a
future C++ standard will offer arbitrary and/or variable length integers.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

gdr@integrable-solutions.net (Gabriel Dos Reis) writes:

> Anthony Williams <anthony.williamsNOSPAM@anthonyw.cjb.net> writes:
>
> [...]
>
> | // class to simulate exact-sized integers slowly
> | // shown for exposition, implementation may use a custom internal type
> | template<unsigned bits,__integer_sign_flags sign>
> | class __exact_sized_integer_implementation;
>
> [...]
>
> | As for __exact_sized_integer_implementation, there are three options:
> |
> | 1. Don't require it (but allow it to be a built-in type as an extension)
> | 2. Require it as a class
> | 3. Require it as a built-in type.
> |
> | I favour 1 or 3 --- I think that classes are sufficiently different from
> | built-in types that a type expression should always be either a class or a
> | built-in type, for a given set of parameters; it will only cause problems if
> | an expression is sometimes a built-in type, and sometimes a class, depending
> | on the implementation, it is better that it doesn't compile.
>
> At the last meeting, the Core Working Group and the Evolution Working
> Group discussed several semantics for typedef template.  With the
> "specializable typedef" semantics, Daveed Vandevoorde suggested the
> following possibility:
>
>   template<unsigned bits,__integer_sign_flags sign>
>      typedef __exact_sized_integer_implementation;
>
> This is a general template name definition, saying that every
> instantiation is a typedef, the template is specializable, and since
> the primary template is missing an "initializer", it cannot be
> instantiated (a sort of abstract class); i.e., trying to refer to a
> specialization that does not come from an explicit or partial
> specialization triggers a diagnostic.  I think that neatly resolves
> your above mentionned issue.

To an extent --- it solves the declaration issue, but not the real problem I
was referring to. I meant that some platforms might have integers of specific
sizes they can use with simple hardware instructions, whereas others might
not. For example, it would be nice if
__exact_sized_integer_implementation<32,__signed_flag> was an alias for "int"
on 32-bit platforms. However, not all platforms will have an exactly-32-bit
native type, so if such an expression is to be allowed, it would have to be
emulated. It could be emulated by writing a class, but it is not currently
possible to write a class that behaves exactly like a built-in
type. Alternatively, it could be emulated as part of the run-time support code
for the compiler, and treated as a built-in type. The difference is
detectable, because if you say:

struct X
{
operator Integer<32,__exact_flag,__signed_flag> ();
};

void f(int);

X x
f(x); // *

in the call to f() marked with a *, X is not directly convertible to Y. On a
32-bit platform, Integer<32...> is an alias for "int", so this works fine. On
a non-32-bit platform, Integer<32,...> is an alias for
__exact_sized_integer_implementation<32,__signed_flag>. If this is a class,
then the call fails, because it involves two user-defined conversions. If it
is a built-in type, then it will work, since there is only one UDC, and a
standard conversion (promotion/truncation as appropriate).

This may affect overload resolution, and so silently compile, but calling a
different function on each platform. Even failing noisily as for the example
as it stands is not necessarily a good thing, since some code will compile and
some won't.

Therefore, if you allow __exact_sized_integer_implementation to be a class,
you are making code quietly non-portable. If it is allowed to only be
implemented for certain sizes, and for those cases it is a built-in type, then
it is at least immediately apparent that something is wrong, because you get
an error on the operator Integer<...> in X. This is the case with C99, I
believe --- the exact sized types are not guaranteed to be present.

If __exact_sized_integer_implementation is required to be present for all
sizes, as a built-in type, then you have maximum portability, but the code
will be slow on some platforms. However, by specifying an exact size, you are
stating that you would rather have the properties of the exact size, than
the performance --- if you want performance, then you specify "__fast_flag"
rather than "__exact_flag", and the compiler will pick a type (same-size or
larger) that it can handle with fewer operations, generally one that is a
multiple of the machine word size.

Of course, if you require it to work for all bit values, then someones going
to ask for Integer<UINT_MAX>. If they really need that size, though, it might
be better that the compiler handle it (since the compiler knows the best way
to optimize such code for this platform, in theory) rather than have the user
write a class to handle it; OTOH, if they had to write a class, they might
think about the precise details of their algorithm, and ensure that the class
is optimized for that algorithm.

Anthony
--
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Scott Mayo"" <scottm@toast.net> wrote...
> Unless someone gets around to inventing int<64>, int<128>
> and so on, which I personally think is a fine idea

I actually suggested precisely that notation some time ago, though as I
recall most who replied didn't seem to like it. The biggest problem
seemed to be one of interpretation: is this the minimum size, the exact
size, or something else?

Personally, I don't see a problem with having a second, standard
enumeration, so you can have int<32, exact>, for example. This is, at
least, a consistent and future-proof naming convention, and it's pretty
much guaranteed not to conflict with any other notations currently in
use as compiler extensions. Just reduce things like short int to a
typedef to avoid aliasing problems, and you're done.

(You can introduce a third "parameter" specifying signed/unsigned if you
like, though making "unsigned long" a typedef for int<64, exact,
unsigned> might be taking things a bit too far...?)

> The good news is that I think after 256 bit hardware integers
> arrive, we'll be done growing integers for at least a few decades.
> There are not too many real world problems that need integers
> larger than that...

Personally, I don't know why we didn't just stop at 16. After all,
no-one would ever need more than 640K of RAM, right? :-)

Cheers,
Chris


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Al Grant wrote:
> jackklein@spamcop.net (Jack Klein) wrote in message news:<ak8f1vsvp8dd0uevgmt3dbpnqujls4uabc@4ax.com>...
>
>>Not that I'm a member of either the C or C++ standards committee, but
>>I really dislike "long long", even though it was mentioned in the
>>appendix of ISO C90 as an already existing common extension.
>
>
> It's not that surprising if you remember the bit of Dennis Ritchie's
> paper on the history of C where he describes the influence of the
> Algol 68 type system.  In Algol 68 "long" and "short", as modifiers
> to "int" (and "real"), can be used repeatedly.  So as far as technical
> precedent goes there seems little justification for C++ not following
> C's lead as a matter of course.

Except, of course, the fact that it was a bad precedent, and one that
the C committee itself regretted being forced to accept.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <avfrpi$n33$1@knossos.btinternet.com>, Chris Newton
<chrisnewton@no.junk.please.btinternet.com> writes
>(You can introduce a third "parameter" specifying signed/unsigned if you
>like, though making "unsigned long" a typedef for int<64, exact,
>unsigned> might be taking things a bit too far...?)


What syntax are you suggesting to allow a multi-token type-name to
become a synonym for anything. Currently C++ syntax only allows me to
declare new single token names for types. That means that for
portability between C and C++  all new C names need to have single token
versions. IOWs the only way C++ can support long long int as a type by
that name is to make it a fundamental type. That was one of the reasons
that I voted against the introduction of long long types into C.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

francis.glassborow@ntlworld.com (Francis Glassborow) writes:

> In article <avfrpi$n33$1@knossos.btinternet.com>, Chris Newton
> <chrisnewton@no.junk.please.btinternet.com> writes
>
> >(You can introduce a third "parameter" specifying signed/unsigned if you
> >like, though making "unsigned long" a typedef for int<64, exact,
> >unsigned> might be taking things a bit too far...?)
>
>
> What syntax are you suggesting to allow a multi-token type-name to become a
> synonym for anything. Currently C++ syntax only allows me to declare new
> single token names for types. That means that for portability between C and
> C++ all new C names need to have single token versions. IOWs the only way
> C++ can support long long int as a type by that name is to make it a
> fundamental type. That was one of the reasons that I voted against the
> introduction of long long types into C.

Assuming template typedefs:

enum __integer_sign_flags
{
    __signed_flag,__unsigned_flag
};

enum __integer_exactness_flags
{
    __exact_flag,__least_flag,__fast_flag
};

// class to simulate exact-sized integers slowly
// shown for exposition, implementation may use a custom internal type
template<unsigned bits,__integer_sign_flags sign>
class __exact_sized_integer_implementation;

// primary template for typedef
// defaults to void for cases we don't specialize below
template<unsigned bits,__integer_exactness_flags
        exactness,__integer_sign_flags sign>
typedef void integer;

// the following assumes that char,short,int,long are distinct sizes
// and that SHORT_BIT, INT_BIT, etc. are the number of bits in the
// representation of short, int

template<>
typedef signed char integer<CHAR_BIT,__exact_flag,__signed_flag>;

template<>
typedef unsigned char integer<CHAR_BIT,__exact_flag,__unsigned_flag>;

template<>
typedef signed short integer<SHORT_BIT,__exact_flag,__signed_flag>;

template<>
typedef unsigned short integer<SHORT_BIT,__exact_flag,__unsigned_flag>;

template<>
typedef signed int integer<INT_BIT,__exact_flag,__signed_flag>;

template<>
typedef unsigned int integer<INT_BIT,__exact_flag,__unsigned_flag>;

template<>
typedef signed long integer<LONG_BIT,__exact_flag,__signed_flag>;

template<>
typedef unsigned long integer<LONG_BIT,__exact_flag,__unsigned_flag>;

// __if yields true_type if selector is true, else false_type
template<bool selector,typename true_type,typename false_type>
typedef void __if;

template<typename true_type,typename false_type>
typedef true_type __if<true,true_type,false_type>;

template<typename true_type,typename false_type>
typedef false_type __if<false,true_type,false_type>;

// specialization for types with least_flag set
// use long if possible, otherwise defer to the generic (slow) implementation
template<unsigned bits,integer_sign_flags sign>
typedef __if<(bits<LONG_BIT),
             integer<LONG_BIT,__exact_flag,sign>,
             __exact_sized_integer_implementation<bits,sign> >
    integer<bits,__least_flag,sign>;

// etc.

// Usage:

integer<32,__least_flag,__signed_flag> i;

// you might want to swap the parameters around, and provide
// defaults, so
// integer<> was equivalent to int
// integer<__unsigned_flag> was equivalent to unsigned
// integer<__signed_flag,32> was equivalent to
// integer<__signed_flag,32,__exact_flag>

Obviously, specializations for __fast_flag are highly implementation
dependent, and you might want to change the specialization for __least_flag to
use smaller types than long when applicable.

As for __exact_sized_integer_implementation, there are three options:

1. Don't require it (but allow it to be a built-in type as an extension)
2. Require it as a class
3. Require it as a built-in type.

I favour 1 or 3 --- I think that classes are sufficiently different from
built-in types that a type expression should always be either a class or a
built-in type, for a given set of parameters; it will only cause problems if
an expression is sometimes a built-in type, and sometimes a class, depending
on the implementation, it is better that it doesn't compile.

Anthony
--
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Anthony Williams <anthony.williamsNOSPAM@anthonyw.cjb.net> writes:

[...]

| // class to simulate exact-sized integers slowly
| // shown for exposition, implementation may use a custom internal type
| template<unsigned bits,__integer_sign_flags sign>
| class __exact_sized_integer_implementation;

[...]

| As for __exact_sized_integer_implementation, there are three options:
|
| 1. Don't require it (but allow it to be a built-in type as an extension)
| 2. Require it as a class
| 3. Require it as a built-in type.
|
| I favour 1 or 3 --- I think that classes are sufficiently different from
| built-in types that a type expression should always be either a class or a
| built-in type, for a given set of parameters; it will only cause problems if
| an expression is sometimes a built-in type, and sometimes a class, depending
| on the implementation, it is better that it doesn't compile.

At the last meeting, the Core Working Group and the Evolution Working
Group discussed several semantics for typedef template.  With the
"specializable typedef" semantics, Daveed Vandevoorde suggested the
following possibility:

  template<unsigned bits,__integer_sign_flags sign>
     typedef __exact_sized_integer_implementation;

This is a general template name definition, saying that every
instantiation is a typedef, the template is specializable, and since
the primary template is missing an "initializer", it cannot be
instantiated (a sort of abstract class); i.e., trying to refer to a
specialization that does not come from an explicit or partial
specialization triggers a diagnostic.  I think that neatly resolves
your above mentionned issue.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.de (James Kanze) writes:

| gdr@integrable-solutions.net (Gabriel Dos Reis) wrote in message
| news:<m3k7himcbt.fsf@uniton.integrable-solutions.net>...
| > kanze@gabi-soft.de (James Kanze) writes:
|
| > | petebecker@acm.org (Pete Becker) wrote in message
| > | news:<3E173743.B71A0B30@acm.org>...
| > | > Sachin Garg wrote:
|
| > | > > When we switched from 16 bit platforms to 32 bit platforms, we
| > | > > called the 64 bit integers as "long long"
|
| > | > We didn't do that. C99 did. Ask them. <g>
|
| > | Don't blame them (entirely); they just standardized existing
| > | practice.
|
| > | One compiler manufacturer handled the added type in a professional
| > | way that respected the standard and took into account possible
| > | future problems with 128 bit ints, 256 bit ints, etc., and named it
| > | __int64.  But a lot of others just looked for a short term fix, more
| > | or less said to hell with any standard, and adopted long long (which
| > | unlike __int64 requires a diagnostic -- and is a likely error -- in
| > | C90 and C++).
|
| > "long long" is just equally short-term fix as __int64.  Both implement
| > 64-bit ints for the short-term needs.
|
| I'm not sure of your point.  The use of __int64 has two advantages with
| regards to long long: it is standards conforming, and it is clearly
| extensible to even more integral types.

What is standard conforming about __int64?

It is an identifier reserved to implementations. The effect of ussing
such identifier in a C++ (or C) program is not explicitly described by
the standard, which means undefined behaviour.

__int64 is a *fixed* identifier, in that way it certainly isn't
extensible.

On the other hand, the repetition of "long", in a type specifier, to
suggest the minimum of bit length however is extensible (although for
C++, I really prefer a solution based on template-id).

|  The C99 standard adopted long
| long because of existing practice, but they also provide an intelligent
| framework for further extensions.  Along the lines of __int64.

But __int64 framework isn't more intelligent.  That framework isn't even
extensible.

| > GCC, to name one compiler that uses "long long", can be instructed to
| > diagnose or not "long long"; so your point is moot.
|
| Moot in what sense.  I never made the slightest comment concerning gcc

Certainly, you didn't make a direct comment concerning gcc.  But as
stated in the part of the message you're replying to, it is an
instance of your *"But a lot of others"*.

| (which generally adopts to the platform on which it runs).  And whether
| you can turn the diagnostic on or off is irrelevant

Sure, it is relevant: you were talking about standard conformance.

[...]

| > Actually, I suspect that is the case of other major compilers out
| > there.  Actually I suspect "long long" to be better than __int64 which
| > users aren't formally allowed to use at global scope
|
| Where do you find that users aren't formally allowed to use __int64 at
| global scope.

You were talking about standard conformance, and if you restrict
yourself to constructs whose meanings are explicilty decribed by the
standard then you not allowed to use __int64, otherwise you get an
undefined behaviour.

| The symbol __int64 results in undefined behavior
| according to the standard; one of the purposes of undefined behavior is
| precisely to allow implementation defined extensions such as this.

And there is no obligation that the implementation, in fact, does
anything sensible with __int64.

On the opposite side: C90 and C++ requires a diagnostic for "long
long" as a type specifier.  However the Standard does also explicitly
say that the implementation may accept the construct as an extension
(after diagnosis).

So:
On one side, an undefined behaviour (__int64), on the other side a
required diagnostic (long long).  And you're saying that __int64 is
more standard conformant.  Huh.

| And if long long gives you a guaranteed 64 bit type, how to you specify
| a guaranteed 128 bit type, when the need arises.

Ask your compiler vendor.

| We went through all of this discussion in the C committee.

So what?

And in the French national body, I was against this solution -- and
yes, we changed our "no" vote.

|  Long long is
| an abomination, fostered upon us by a certain number of Unix compilers.

Thanks, I know that often repeated assertion.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <smw3an2j.fsf@anthonyw.cjb.net>, Anthony Williams
<anthony.williamsNOSPAM@anthonyw.cjb.net> writes
>I favour 1 or 3 --- I think that classes are sufficiently different from
>built-in types that a type expression should always be either a class or a
>built-in type, for a given set of parameters; it will only cause problems if
>an expression is sometimes a built-in type, and sometimes a class, depending
>on the implementation, it is better that it doesn't compile.

And the trouble with C/C++ compatibility is that new types with extended
behaviour have just about got to be fundamental types in C and C++ tries
to avoid new fundamental types because the break legacy code.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Sachin Garg wrote:
>
> Hi,
>
> When we switched from 16 bit platforms to 32 bit platforms, we called the 64
> bit integers as "long long"
>
> What will be the name of 128 bit integers when we switch to 64 bit platforms
> (which will be happening very soon)?

Since 'long long' is a new feature in C99, and is not yet a C++ feature,
I'll give you a C99 answer:

#include <stdint.h>, and then use int128_t, int_least128_t, or
int_fast128_t, depending upon whether you need a signed type with
exactly 128 bits, the smallest signed type with at least 128 bits, or
the fastest signed type with at least 128 bits. If you need an unsigned
type, prefix those type names with 'u'. You can check for whether or not
the corresponding *_MAX macros are #defined by <stdint.h>. Such
identifiers are required to be defined only for the 'least' and 'fast'
types, and only for the sizes 8, 16, 32, and 64, but all such
identifiers are reserved for that use. A conforming C99 implementation
might or might not support them, can't use those names for any other
purpose.

I may have misplaced the '_'s in those typedef names. I don't have any
experience actually using them, since conforming C99 implementations are
so new, and I don't currently have access to my copy of the C99
standard.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Sachin Garg wrote:

> Hi,
>
> When we switched from 16 bit platforms to 32 bit platforms, we called the 64
> bit integers as "long long"

No we did not.  We call the most convenient size "int" and the longest available
size "long".

If you want a specific size  ask for it by name.  Common names include int16_t,
int32_t, int64_t and various flavors of  those sizes.

>
>
> What will be the name of 128 bit integers when we switch to 64 bit platforms

"long".

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

schngrg@yahoo.com ("Sachin Garg") writes:

> Hi,
>
> When we switched from 16 bit platforms to 32 bit platforms, we called the 64
> bit integers as "long long"
>
> What will be the name of 128 bit integers when we switch to 64 bit platforms
> (which will be happening very soon)?

I believe the standard allows an implementation to name a 128 bit
    integer any of 'char', 'short', 'int', or 'long'. Anything else,
    such as 'long long' would be an extension.

> :-)
[snip]

:-)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> When we switched from 16 bit platforms to 32 bit platforms, we called the
64
> bit integers as "long long"
>
> What will be the name of 128 bit integers when we switch to 64 bit
platforms
> (which will be happening very soon)?

Probably "long long". C doesn't guarantee that a given name is a given size;
things change.

Unless someone gets around to inventing int<64>, int<128> and so on, which I
personally think is a fine idea (and very desirable to cryptographers, who
often specify algorithms with explicit integer sizes). I realise that the
prospects of int<57> and int<512> are disturbing (and int<64> wouldn't be
fun on a 36 bit machine either), but the problem are solvable. Though it
does get a little frightening if you want to go as far as something like
anyIntAcceptedHere(int<*>& iValue).

The good news is that I think after 256 bit hardware integers arrive, we'll
be done growing integers for at least a few decades. There are not too many
real world problems that need integers larger than that...




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

petebecker@acm.org (Pete Becker) wrote in message
news:<3E173743.B71A0B30@acm.org>...
> Sachin Garg wrote:

> > When we switched from 16 bit platforms to 32 bit platforms, we
> > called the 64 bit integers as "long long"

> We didn't do that. C99 did. Ask them. <g>

Don't blame them (entirely); they just standardized existing practice.

One compiler manufacturer handled the added type in a professional way
that respected the standard and took into account possible future
problems with 128 bit ints, 256 bit ints, etc., and named it __int64.
But a lot of others just looked for a short term fix, more or less said
to hell with any standard, and adopted long long (which unlike __int64
requires a diagnostic -- and is a likely error -- in C90 and C++).

There was a great deal of discussion in the C standards committee, where
it was generally recognized that long long was a serious design error.
But in the end, the first role of a standards committee is to
standardize existing practice, so they did.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Sachin Garg"" <schngrg@yahoo.com> wrote in message
news:av6b4f$4s8$1@newsreader.mailgate.org...
> When we switched from 16 bit platforms to 32 bit platforms, we called the
64
> bit integers as "long long"
> What will be the name of 128 bit integers when we switch to 64 bit
platforms
> (which will be happening very soon)?

The D language www.digitalmars.com/d/ calls them "cent".

-Walter

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.de (James Kanze) writes:

| petebecker@acm.org (Pete Becker) wrote in message
| news:<3E173743.B71A0B30@acm.org>...
| > Sachin Garg wrote:
|
| > > When we switched from 16 bit platforms to 32 bit platforms, we
| > > called the 64 bit integers as "long long"
|
| > We didn't do that. C99 did. Ask them. <g>
|
| Don't blame them (entirely); they just standardized existing practice.
|
| One compiler manufacturer handled the added type in a professional way
| that respected the standard and took into account possible future
| problems with 128 bit ints, 256 bit ints, etc., and named it __int64.
| But a lot of others just looked for a short term fix, more or less said
| to hell with any standard, and adopted long long (which unlike __int64
| requires a diagnostic -- and is a likely error -- in C90 and C++).

"long long" is just equally short-term fix as __int64.  Both implement
64-bit ints for the short-term needs.

GCC, to name one compiler that uses "long long", can be instructed to
diagnose or not "long long"; so your point is moot.  Actually, I
suspect that is the case of other major compilers out there.
Actually I suspect "long long" to be better than __int64 which users
aren't formally allowed to use at global scope -- better get a
diagnostic than having an undefined behaviour if we were to be overly
peeky about standard conformance issues.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

gdr@integrable-solutions.net (Gabriel Dos Reis) wrote in message
news:<m3k7himcbt.fsf@uniton.integrable-solutions.net>...
> kanze@gabi-soft.de (James Kanze) writes:

> | petebecker@acm.org (Pete Becker) wrote in message
> | news:<3E173743.B71A0B30@acm.org>...
> | > Sachin Garg wrote:

> | > > When we switched from 16 bit platforms to 32 bit platforms, we
> | > > called the 64 bit integers as "long long"

> | > We didn't do that. C99 did. Ask them. <g>

> | Don't blame them (entirely); they just standardized existing
> | practice.

> | One compiler manufacturer handled the added type in a professional
> | way that respected the standard and took into account possible
> | future problems with 128 bit ints, 256 bit ints, etc., and named it
> | __int64.  But a lot of others just looked for a short term fix, more
> | or less said to hell with any standard, and adopted long long (which
> | unlike __int64 requires a diagnostic -- and is a likely error -- in
> | C90 and C++).

> "long long" is just equally short-term fix as __int64.  Both implement
> 64-bit ints for the short-term needs.

I'm not sure of your point.  The use of __int64 has two advantages with
regards to long long: it is standards conforming, and it is clearly
extensible to even more integral types.  The C99 standard adopted long
long because of existing practice, but they also provide an intelligent
framework for further extensions.  Along the lines of __int64.

> GCC, to name one compiler that uses "long long", can be instructed to
> diagnose or not "long long"; so your point is moot.

Moot in what sense.  I never made the slightest comment concerning gcc
(which generally adopts to the platform on which it runs).  And whether
you can turn the diagnostic on or off is irrelevant -- if you turn it
on, you don't have a guaranteed 64 bit type.

> Actually, I suspect that is the case of other major compilers out
> there.  Actually I suspect "long long" to be better than __int64 which
> users aren't formally allowed to use at global scope

Where do you find that users aren't formally allowed to use __int64 at
global scope.  The symbol __int64 results in undefined behavior
according to the standard; one of the purposes of undefined behavior is
precisely to allow implementation defined extensions such as this.

And if long long gives you a guaranteed 64 bit type, how to you specify
a guaranteed 128 bit type, when the need arises.

We went through all of this discussion in the C committee.  Long long is
an abomination, fostered upon us by a certain number of Unix compilers.
Because it was widely existing practice, in fact, universal practice on
64 bit machines, it was felt that we had no choice but to adopt it.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

jackklein@spamcop.net (Jack Klein) wrote in message news:<ak8f1vsvp8dd0uevgmt3dbpnqujls4uabc@4ax.com>...
> Not that I'm a member of either the C or C++ standards committee, but
> I really dislike "long long", even though it was mentioned in the
> appendix of ISO C90 as an already existing common extension.

It's not that surprising if you remember the bit of Dennis Ritchie's
paper on the history of C where he describes the influence of the
Algol 68 type system.  In Algol 68 "long" and "short", as modifiers
to "int" (and "real"), can be used repeatedly.  So as far as technical
precedent goes there seems little justification for C++ not following
C's lead as a matter of course.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi,

When we switched from 16 bit platforms to 32 bit platforms, we called the 64
bit integers as "long long"

What will be the name of 128 bit integers when we switch to 64 bit platforms
(which will be happening very soon)?

:-)

Sachin Garg [India]
http://sachingarg.cjb.net
http://sachingarg.go.to





---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Sachin Garg wrote:
>
> When we switched from 16 bit platforms to 32 bit platforms, we called the 64
> bit integers as "long long"
>

We didn't do that. C99 did. Ask them. <g>

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sat, 4 Jan 2003 19:24:38 +0000 (UTC), schngrg@yahoo.com ("Sachin
Garg") wrote in comp.std.c++:

> Hi,
>
> When we switched from 16 bit platforms to 32 bit platforms, we called the 64
> bit integers as "long long"
>
> What will be the name of 128 bit integers when we switch to 64 bit platforms
> (which will be happening very soon)?
>
> :-)
>
> Sachin Garg [India]
> http://sachingarg.cjb.net
> http://sachingarg.go.to

Not that I'm a member of either the C or C++ standards committee, but
I really dislike "long long", even though it was mentioned in the
appendix of ISO C90 as an already existing common extension.  I don't
know of a spelling checker that can be told to completely ignore a
particular repeated word.

Still, in the spirit of "long long", I will repeat a suggestion I made
on comp.std.c years ago:

How about "spam spam spam spam long and spam"?  :)

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]