Is it standard and practical to use long long types?

[Kevin Goodsell]

And entirely off topic in this world, i strongly suggest Mozilla Firefox.
It is my default browser now and i do not switch any kind of programs so
easily. Definetely it is worth to check it out.

I use Firefox myself, but I think he mis-spoke when he said "browser".
He was probably referring to his news client (Mozilla is both, and
more). Firefox is, of course, only a web browser. I also use
Thunderbird, the stand-alone version of Mozilla's mail and news client.

In any case, the actual problem is the fonts used by Mozilla,
apparently. I know you can adjust them in Thunderbird, and I'm sure you
can in Mozilla as well. I've seen different fonts used for unusual
character sets before, but it should be easy to fix.

Incidentally Mozilla 1.4.1 is a bit old now. 1.7 is in beta, I think.

-Kevin

 

[Kevin Goodsell]

Okay, sorry. Please don't deprive me of gems like:

Perhaps a more specific question would have gotten a more satisfactory
answer. I'm not psychic, and I cannot guess exactly what you want to do
or what your level of knowledge and experience is. So I answered the
question you asked. If you don't like the answer... well, I'd be happy
to refund the money you paid for it.

-Kevin

 

[Nick Hounsome]

True. 'int' is only required to be at least 16 bits. There are also
numerous other guarantees: 'char' must be at least 8 bits, 'long' must
be at least 32, certain types may not have greater precision than
others, etc.

The size requirements are, as far as I know, not stated explicitly, but
are implied from other requirements. In particular, restrictions on how
integers may be represented, plus the required minimum ranges for the
integer types (e.g. -32,767 to 32,767 for 'int'), imply that they must
have at least some easily determined number of bits.

Help me out here - what;s the std reference? The index is useless.

 

[Martin Ambuhl]

Help me out here - what;s the std reference? The index is useless.

5.2.4.2.1 Sizes of integer types <limits.h>

 

[PlasmaDragon]

There is no long long in C++98 standard. I also hope that there will not be
one in C++0x.

Regards,

Ioannis Vranos

Why not?

 

[PlasmaDragon]

There is no long long in C++98 standard. I also hope that there will not be
one in C++0x.

Regards,

Ioannis Vranos

Why do you hope so?

 

[Arthur J. O'Dwyer]

There is no long long in C++98 standard. I also hope that there will
not be one in C++0x.

C++0x will introduce not only "long long int," but also "signed signed
int" for those numerical applications requiring extremely positive and/or
extremely negative numbers, and probably "short short int" for the
convenience of embedded programmers.
(There is also an extremely vocal contingent pushing for the adoption of
the "do do" control structure, but it's way past their bedtime.)

-Arthur,
insert "embed" joke here

 

[Dan Pop]

lcc-win32 supports long long.

Unfortunately, it does it at the expense of not being conforming to any
C standard. long long is a syntax error in C89 and lcc-win32 is NOT a
conforming C99 implementation, either. So, I have yet to figure out
what -ansic means to the lc and lcc commands.

Then again, this is only one droplet in the ocean of lcc-win32 conformance
problems...

Dan

 

[Dan Pop]

I cross-posted because I am asking the questions about both languages.

This is still not the right thing. Post the question separately in both
newsgroups and compare the C answers and the C++ answers.

Dan

 

[Dan Pop]

The post to which I am now replying appears to me in a normal-size font.

Usenet posts are not written in one font or another.

Your first post showed up tiny in my browser (Mozilla 1.4.1).

Blame all this nonsense on *your* newsreader. Use a plain text newsreader
to avoid such problems.

Dan

 

[Irrwahn Grausewitz]

C++0x will introduce not only "long long int," but also "signed signed
int" for those numerical applications requiring extremely positive and/or
extremely negative numbers, and probably "short short int" for the
convenience of embedded programmers.
(There is also an extremely vocal contingent pushing for the adoption of
the "do do" control structure, but it's way past their bedtime.)

-Arthur,
insert "

AFAIK the dodo concept already died out. However, I'm very
interested in the new additional meanings of 'static'.

 

[CBFalconer]

Unfortunately, it does it at the expense of not being conforming
to any C standard. long long is a syntax error in C89 and
lcc-win32 is NOT a conforming C99 implementation, either. So, I
have yet to figure out what -ansic means to the lc and lcc commands.

Then again, this is only one droplet in the ocean of lcc-win32
conformance problems...

This is the sort of thing that might be controlled by the public
availability of a conformance checking suite, which could be
available in conjunction with the actual standard. Pascal had
such a thing in the early standardization days, but unfortunately
put it under the commercial control of a single firm, which
effectively wiped it out.

comp.lang.c++ dropped, comp.std.c added.

 

[Ioannis Vranos]

"Ioannis Vranos" <[email protected]> wrote in message



Why not?

When we will need an 128 bit type in the future we will have long long
long? At first i think long would be sufficient enough to be of 64 bits in
32-bit systems in case we need it. In 64-bit systems i feel it natural int
to be of 64 bits. In .NET that i am currently studying int and long are of
32 bit and we get __int64 for 64-bit integral type. On the other hand "long"
of C# is 64-bits.

Anyway i think that the already provided range of built in types were enough
to cover our needs and we needed to define explicitly what type we needed,
we could be provided only with typedefs in the standard library like in the
style int8, int16, int32, int64, int128 etc with the notice "where
available". That would be open for future extensions. Meanwhile the already
provided built in types would be spreaded to cover the new space, e.g. in a
max 64 bit scenario, short could be 16 bit, int 32, long 64.






Ioannis Vranos

 

[Dan Pop]

When we will need an 128 bit type in the future we will have long long
long?

For the time being, there is little evidence that we're going to need an
128-bit integer type.

At first i think long would be sufficient enough to be of 64 bits in
32-bit systems in case we need it.

Unfortunately, the guy who invented the C language thought otherwise. And
his ideas seem to be far more popular than yours.

In 64-bit systems i feel it natural int to be of 64 bits.

Leave your feelings alone and engage your brain. If int is 64-bit, we're
left with char and short (two types) for *three* very common and popular
integer sizes: 8, 16 and 32-bit. Which of them should be dropped by the
implementor, so that int can be a 64-bit, according to your feelings?

long long is an ugly name, but it was existing practice at the time when
the C committee decided to add a new integer type that is at least 64-bit
wide. Like it or not, you'll have to live with it and I bet that the next
C++ standard will adopt it.

Dan

 

[Ioannis Vranos]

In <[email protected]> "Ioannis Vranos"

For the time being, there is little evidence that we're going to need an
128-bit integer type.


Unfortunately, the guy who invented the C language thought otherwise. And
his ideas seem to be far more popular than yours.

I do not know if dmr suggested that. If he did, i can have my own opinion
right? And i did not discuss popularity.

Leave your feelings alone and engage your brain. If int is 64-bit, we're
left with char and short (two types) for *three* very common and popular
integer sizes: 8, 16 and 32-bit. Which of them should be dropped by the
implementor, so that int can be a 64-bit, according to your feelings?

Byte is 8 bit in all 64-bit systems? My last info about Itanium when it was
being designed was that it would have 16 bit bytes (which is not prohibited
as you know). Even in your case, long could have been 64 bit until 128 bit
systems become popular.

long long is an ugly name, but it was existing practice at the time when
the C committee decided to add a new integer type that is at least 64-bit
wide. Like it or not, you'll have to live with it and I bet that the next
C++ standard will adopt it.

Yes me too. I also bet that we will face a "fragmentation problem" in the
future, that is not all language features will be implemented in most
(popular) implementations as is the case of C99 now. Who can really rely
that C99 code can be really portable? And 5 years have already passed...






Ioannis Vranos

 

[red floyd]

"PlasmaDragon" <[email protected]> wrote in message

When we will need an 128 bit type in the future we will have long long long?

No, we'll use "really long long".
When we need 256 bit ints, we'll use "jumbo long"

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

No, we'll use "really long long".

No, adding a new keyword is more difficult to be accepted.

 

[Dan Pop]

I do not know if dmr suggested that.

His own compiler used 32-bit longs on 32-bit hardware...

If he did, i can have my own opinion right?

Did anyone dispute your right to your own opinion? However, you expressed
it in terms of "we", so you should tell us who exactly is included in this
"we".

And i did not discuss popularity.

Yet, popularity does matter when the implementor has to decide the sizes
of the types. He could make int's 1024 bits and long's 16384 bits, but
chances are that few people will want to use his implementation...

Byte is 8 bit in all 64-bit systems?

I have yet to hear about one using another byte size. Even the
implementation for the original Cray processors had 8-bit bytes, despite
the lack of hardware support for them (the processor only supported 64-bit
word addressing).

My last info about Itanium when it was
being designed was that it would have 16 bit bytes (which is not prohibited
as you know).

Your last information about Itanium is pure bullshit. I was programming
on the Itanium back when it was called Merced and it only existed in
software emulation, so I should know. Its instruction set makes
implementations with 8, 16, 32 or 64-bit bytes perfectly possible, but
its architecture is based on 8-bit byte addressing.

If you want a processor with 16-bit bytes, have a look at the TMS-320C25,
but don't expect to find any hosted implementation for it.

Even in your case, long could have been 64 bit until 128 bit
systems become popular.

I never said it *couldn't*, I was merely talking about the current
situation, where people needed 64-bit support on 32-bit implementations
that *already* had 32-bit long's. The people maintaining these
implementations would not consider changing the size of long as an
acceptable solution (far too much existing code relied on long as a 32-bit
type), so the *only* acceptable solution was introducing a new type.

I entirely agree that, if C were invented today, long would be the right
type for 64-bit integers. But C was invented over 30 years ago and its
history does influence its current definition.

Yes me too. I also bet that we will face a "fragmentation problem" in the
future, that is not all language features will be implemented in most
(popular) implementations as is the case of C99 now. Who can really rely
that C99 code can be really portable? And 5 years have already passed...

C99 is far from being an industry standard and it is not yet clear whether
it will ever become one. Yet, it does exist and it does influence other
standards (the last Unix specification is based on it) and the C++
standardisation process seems to be moving toward adopting its new
features. Whether you (or I) like it or not.

Dan

 

[Ben Pfaff]

No, adding a new keyword is more difficult to be accepted.

That's no guarantee: C99 added "inline" and "restrict", which
were previously available to the user.

 

[red floyd]

red floyd wrote:




No, adding a new keyword is more difficult to be accepted.

In the future, [HUMOR] tags will be added to aid the humor-impaired in
compliance with the Americans with Disabilities Act.