Is it standard and practical to use long long types?

[PlasmaDragon]

Re: Is it standard and practical to use long long types?

"Ioannis Vranos" <ivr@guesswh.at .emails.ru> wrote in message news:<c5hhdv$p9 v$1@ulysses.noc .ntua.gr>...
-posted because I am asking the questions about both languages.[color=blue]
>
>
> There is no long long in C++98 standard. I also hope that there will not be
> one in C++0x.[/color]
[color=blue]
>
> Regards,
>
> Ioannis Vranos[/color]

Why do you hope so?

[Arthur J. O'Dwyer]

Re: Is it standard and practical to use long long types?


On Tue, 13 Apr 2004, Ioannis Vranos wrote:[color=blue]
>
> There is no long long in C++98 standard. I also hope that there will
> not be one in C++0x.[/color]

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]

Re: Is it standard and practical to use long long types?

In <c5gs1j$cr9$1@n ews-reader2.wanadoo .fr> "jacob navia" <jacob@jacob.re mcomp.fr> writes:
[color=blue]
>lcc-win32 supports long long.[/color]

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
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Dan Pop]

Re: Is it standard and practical to use long long types?

In <oJTec.1013$AF2 .406@news02.roc .ny> Matt <matt@themattfe lla.zzzz.com> writes:
[color=blue]
>Kevin Goodsell wrote:[color=green]
>> Matt wrote:
>>[color=darkred]
>>> Hi folks. Can you help with some questions?[/color]
>>
>>
>> Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right thing
>> to do. While related, these languages are different enough that answers
>> for one frequently don't apply to the other.[/color]
>
>I cross-posted because I am asking the questions about both languages.[/color]

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
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Irrwahn Grausewitz]

Re: Is it standard and practical to use long long types?

"Arthur J. O'Dwyer" <ajo@nospam.and rew.cmu.edu> wrote:[color=blue]
>
>On Tue, 13 Apr 2004, Ioannis Vranos wrote:[color=green]
>>
>> There is no long long in C++98 standard. I also hope that there will
>> not be one in C++0x.[/color]
>
> 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 "[/color]

AFAIK the dodo concept already died out. However, I'm very
interested in the new additional meanings of 'static'.
[color=blue]
>" joke here[/color]
--
Irrwahn Grausewitz (irrwahn33@free net.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html

[Dan Pop]

Re: [OT] Re: Is it standard and practical to use long long types?

In <4DYec.1040$Ab3 .254@news02.roc .ny> Matt <matt@themattfe lla.zzzz.com> writes:
[color=blue]
>The post to which I am now replying appears to me in a normal-size font.[/color]

Usenet posts are not written in one font or another.
[color=blue]
> Your first post showed up tiny in my browser (Mozilla 1.4.1).[/color]

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

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Ioannis Vranos]

Re: Is it standard and practical to use long long types?

"PlasmaDrag on" <PlasmaDragon@l ycos.co.uk> wrote in message
news:15f1ff99.0 404140043.7f42a cf0@posting.goo gle.com...[color=blue]
> "Ioannis Vranos" <ivr@guesswh.at .emails.ru> wrote in message[/color]
news:<c5hhdv$p9 v$1@ulysses.noc .ntua.gr>...[color=blue]
>[color=green]
> > There is no long long in C++98 standard. I also hope that there will not[/color][/color]
be[color=blue][color=green]
> > one in C++0x.[/color]
>[color=green]
> > Regards,
> >
> > Ioannis Vranos[/color]
>
>
> Why not?[/color]


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]

Re: Is it standard and practical to use long long types?

In <c5jgns$2trd$1@ ulysses.noc.ntu a.gr> "Ioannis Vranos" <ivr@guesswh.at .emails.ru> writes:
[color=blue]
>When we will need an 128 bit type in the future we will have long long
>long?[/color]

For the time being, there is little evidence that we're going to need an
128-bit integer type.
[color=blue]
>At first i think long would be sufficient enough to be of 64 bits in
>32-bit systems in case we need it.[/color]

Unfortunately, the guy who invented the C language thought otherwise. And
his ideas seem to be far more popular than yours.
[color=blue]
>In 64-bit systems i feel it natural int to be of 64 bits.[/color]

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Ioannis Vranos]

Re: Is it standard and practical to use long long types?

"Dan Pop" <Dan.Pop@cern.c h> wrote in message
news:c5jljq$scj $2@sunnews.cern .ch...[color=blue]
> In <c5jgns$2trd$1@ ulysses.noc.ntu a.gr> "Ioannis Vranos"[/color]
<ivr@guesswh.at .emails.ru> writes:[color=blue]
>[color=green]
> >When we will need an 128 bit type in the future we will have long long
> >long?[/color]
>
> For the time being, there is little evidence that we're going to need an
> 128-bit integer type.
>[color=green]
> >At first i think long would be sufficient enough to be of 64 bits in
> >32-bit systems in case we need it.[/color]
>
> Unfortunately, the guy who invented the C language thought otherwise. And
> his ideas seem to be far more popular than yours.[/color]


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


[color=blue][color=green]
> >In 64-bit systems i feel it natural int to be of 64 bits.[/color]
>
> 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?[/color]


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.


[color=blue]
> 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.[/color]


Yes me too. I also bet that we will face a "fragmentat ion 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]

Re: Is it standard and practical to use long long types?

Ioannis Vranos wrote:[color=blue]
> "PlasmaDrag on" <PlasmaDragon@l ycos.co.uk> wrote in message[/color]
[color=blue]
> When we will need an 128 bit type in the future we will have long long long?[/color]

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

[Julián Albo]

Re: Is it standard and practical to use long long types?

red floyd wrote:
[color=blue][color=green]
>> When we will need an 128 bit type in the future we will have long long
>> long?[/color]
> No, we'll use "really long long".[/color]

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

--
Salu2

[Dan Pop]

Re: Is it standard and practical to use long long types?

In <c5jmtm$e3b$1@u lysses.noc.ntua .gr> "Ioannis Vranos" <ivr@guesswh.at .emails.ru> writes:
[color=blue]
>"Dan Pop" <Dan.Pop@cern.c h> wrote in message
>news:c5jljq$sc j$2@sunnews.cer n.ch...[color=green]
>> In <c5jgns$2trd$1@ ulysses.noc.ntu a.gr> "Ioannis Vranos"[/color]
><ivr@guesswh.a t.emails.ru> writes:[color=green]
>>[color=darkred]
>> >When we will need an 128 bit type in the future we will have long long
>> >long?[/color]
>>
>> For the time being, there is little evidence that we're going to need an
>> 128-bit integer type.
>>[color=darkred]
>> >At first i think long would be sufficient enough to be of 64 bits in
>> >32-bit systems in case we need it.[/color]
>>
>> Unfortunately, the guy who invented the C language thought otherwise. And
>> his ideas seem to be far more popular than yours.[/color]
>
>I do not know if dmr suggested that.[/color]

His own compiler used 32-bit longs on 32-bit hardware...
[color=blue]
>If he did, i can have my own opinion right?[/color]

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".
[color=blue]
>And i did not discuss popularity.[/color]

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. ..
[color=blue][color=green][color=darkred]
>> >In 64-bit systems i feel it natural int to be of 64 bits.[/color]
>>
>> 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?[/color]
>
>Byte is 8 bit in all 64-bit systems?[/color]

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).
[color=blue]
>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).[/color]

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.
[color=blue]
>Even in your case, long could have been 64 bit until 128 bit
>systems become popular.[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
>Yes me too. I also bet that we will face a "fragmentat ion 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...[/color]

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[josh]

Re: Is it standard and practical to use long long types?

"Ioannis Vranos" <ivr@guesswh.at .emails.ru> wrote in
news:c5jgns$2tr d$1@ulysses.noc .ntua.gr:
[color=blue]
> 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.[/color]

Microsoft has had __int64 for a while, as well as __int8, __int16, and
__int32. MSVC6 even recognizes __int128, but it doesn't actually let you
use it. (all of these, and their unsigned versions, are distict types from
the standard C++ ones)

Wouldn't a standard "at least 64 bits" type require compilers for 8-bit
processors to support math that spans 16 registers? Ouch.

-josh

[Christian Bau]

Re: Is it standard and practical to use long long types?

In article <c5jmtm$e3b$1@u lysses.noc.ntua .gr>,
"Ioannis Vranos" <ivr@guesswh.at .emails.ru> wrote:
[color=blue]
> 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.[/color]

unsigned char being anything other than 8 bit will break an awful lot of
code. I know that the C and C++ Standards allow this, but that compiler
will not popular.

[Christian Bau]

Re: Is it standard and practical to use long long types?

In article <m1efc.22514$VG 1.6825@newssvr2 7.news.prodigy. com>,
red floyd <no.spam@here.d ude> wrote:
[color=blue]
> Ioannis Vranos wrote:[color=green]
> > "PlasmaDrag on" <PlasmaDragon@l ycos.co.uk> wrote in message[/color]
>[color=green]
> > When we will need an 128 bit type in the future we will have long long
> > long?[/color]
>
> No, we'll use "really long long".
> When we need 256 bit ints, we'll use "jumbo long"[/color]

More likely int128_t and int256_t.