Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Is it standard and practical to use long long types?

Reply
Thread Tools

Is it standard and practical to use long long types?

 
 
Matt
Guest
Posts: n/a
 
      04-12-2004
Hi folks. Can you help with some questions?

I gather that some types supported by g++ are nonstandard but have been
proposed as standards.

Are the long long and unsigned long long types still under consideration
for the ANSI C and C++ standards? Are they likely to be accepted into
the standards?

Which compilers support those types, and which do not?

In a general practical sense, is portability impaired for programs that
use those types?

Is there any good literature on standard techniques related to word size
and portability?
________________________
keywords: gnu gcc g++ borland turbo visual microsoft intel ISO ANSI
compiler long long C C++ language standard

 
Reply With Quote
 
 
 
 
Kevin Goodsell
Guest
Posts: n/a
 
      04-12-2004
Matt wrote:
> Hi folks. Can you help with some questions?


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.

>
> I gather that some types supported by g++ are nonstandard but have been
> proposed as standards.
>
> Are the long long and unsigned long long types still under consideration
> for the ANSI C and C++ standards? Are they likely to be accepted into
> the standards?


long long (along with its variants) was added to C with the 1999 ISO
standard. C++ had not been updated with new features since 1998 (a 2003
update corrected and clarified the existing standard, but added nothing
new), and does not include long long. I don't know the details, but I'm
sure it has been discussed and may still be being discussed for
addition. I'd be surprised if it was not included in the next version of
the C++ standard.

>
> Which compilers support those types, and which do not?


C99 compilers do. Other C and C++ compilers do not, unless through
extensions.

>
> In a general practical sense, is portability impaired for programs that
> use those types?


I would say so. C99 support is rather narrow at the moment.

>
> Is there any good literature on standard techniques related to word size
> and portability?


I don't understand this question.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
 
Reply With Quote
 
 
 
 
Malcolm
Guest
Posts: n/a
 
      04-12-2004

"Matt" <(E-Mail Removed)> wrote in message
>
> Are the long long and unsigned long long types still under
> consideration for the ANSI C and C++ standards? Are they likely
> to be accepted into the standards?
>

Traditionally an int is the size of a register, and registers can be used
either to hold addresses or data, so void * is also the same size as an int.
That rule of thumb is breaking down with 64-bit architectures, because
integers usually represent real numbers (say, the number of employees in a
company) and there are only a few cases where you need a number bigger than
4 billion.
long long looks like the most likely convention to emerge for the 64-bit
type. However it will be a long time before 32-bit architectures become
rare, or long long becomes so entrenched that they are forced to support it.
>
> Is there any good literature on standard techniques related to word > size

and portability?
>

Not that I know of. The main reason for using a 64-bit type is to represent
a size of memory, in which case you should use size_t. Just occasionally you
will need 64 bits for another purpose (eg give the entire population of the
world an id number). In that case there is no neat solution if the target
compiler won't support 64-bit types - you will have to define a structure
and write your own arithmetical routines. (In C++ it is easier because you
can wrap into a class). typedefing long long is probably a good idea if you
think this might happen.


 
Reply With Quote
 
Kevin Goodsell
Guest
Posts: n/a
 
      04-12-2004
Malcolm wrote:
> "Matt" <(E-Mail Removed)> wrote in message
>
>>Are the long long and unsigned long long types still under
>>consideration for the ANSI C and C++ standards? Are they likely
>>to be accepted into the standards?
>>

>
> Traditionally an int is the size of a register,


Not on 8-bit machines. It's a recommendation, not a requirement.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
 
Reply With Quote
 
Martin Ambuhl
Guest
Posts: n/a
 
      04-13-2004
Matt wrote:


> Are the long long and unsigned long long types still under consideration
> for the ANSI C and C++ standards? Are they likely to be accepted into
> the standards?


The C standard has included [signed | unsigned] long long now into its
4th year.

Follow-ups set to comp.lang.c.
 
Reply With Quote
 
Matt
Guest
Posts: n/a
 
      04-13-2004
Kevin Goodsell wrote:
> Matt wrote:


>> Is there any good literature on standard techniques related to word
>> size and portability?

>
>
> I don't understand this question.
>
> -Kevin


Oh. Uh, well, people have to deal with the fact that for a given
numerical type, different compilers have different precisions for the
given type. They want the same code to work the same with all or many
compilers. I am looking for descriptions of standard techniques for
doing that.

 
Reply With Quote
 
Kevin Goodsell
Guest
Posts: n/a
 
      04-13-2004
Matt wrote:
>
> Oh. Uh, well, people have to deal with the fact that for a given
> numerical type, different compilers have different precisions for the
> given type. They want the same code to work the same with all or many
> compilers. I am looking for descriptions of standard techniques for
> doing that.
>


Well, the general technique is to know the required minimum ranges of
the types and write code that doesn't rely on anything beyond those
ranges. So if I need a variable that might exceed 32,767, I don't use an
int. In many cases, additional precision beyond what is needed is not
harmful, so choosing something guaranteed to be "wide enough" works just
fine.

When people have problems with the differences in precision that
different implementations may use, it's usually because they want to do
something that relies on variables using a particular representation and
size. For example, writing a value out to a file as raw bits, and
reading it back in later. The simple answer to this problem is "don't do
that". A file written that way isn't portable anyway. The right thing to
do is to define your file format, and write your program so that it
handles that format (by reading & writing byte-by-byte and
reconstructing/deconstructing values as you go if necessary -- though
differences in the size of a byte could potentially cause problems).

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
 
Reply With Quote
 
Matt
Guest
Posts: n/a
 
      04-13-2004
Kevin Goodsell wrote:
> Matt wrote:
>
>>
>> Oh. Uh, well, people have to deal with the fact that for a given
>> numerical type, different compilers have different precisions for the
>> given type. They want the same code to work the same with all or many
>> compilers. I am looking for descriptions of standard techniques for
>> doing that.
>>

>
> Well, the general technique is to know the required minimum ranges of
> the types and write code that doesn't rely on anything beyond those
> ranges.


OMG. Is this my punishment for cross posting?

 
Reply With Quote
 
Jack Klein
Guest
Posts: n/a
 
      04-13-2004
On Tue, 13 Apr 2004 00:10:35 +0100, "Malcolm"
<(E-Mail Removed)> wrote in comp.lang.c:

>
> "Matt" <(E-Mail Removed)> wrote in message
> >
> > Are the long long and unsigned long long types still under
> > consideration for the ANSI C and C++ standards? Are they likely
> > to be accepted into the standards?
> >

> Traditionally an int is the size of a register, and registers can be used
> either to hold addresses or data, so void * is also the same size as an int.
> That rule of thumb is breaking down with 64-bit architectures, because
> integers usually represent real numbers (say, the number of employees in a
> company) and there are only a few cases where you need a number bigger than
> 4 billion.


The correspondence in size between ints and registers has been broken
in many, many platforms over the years, long before 64-bit
architectures (other than Cray, perhaps) existed.

The assumption that sizeof(void *) == sizeof(int) is horrible broken
and a crutch for the uninformed or lazy, always has been, and always
will be.

I was working today, and will be for the next few weeks, on a platform
with quite a decent C compiler where int has 16 bits and pointers have
32. Not "far" pointers, but all pointers. At the hardware level,
addresses have 32 bits and there is a 4Gb address space.

--
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++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      04-13-2004
Matt <(E-Mail Removed)> writes:
> Kevin Goodsell wrote:
> > Matt wrote:

>
> >> Is there any good literature on standard techniques related to word
> >> size and portability?

> > I don't understand this question.
> > -Kevin

>
> Oh. Uh, well, people have to deal with the fact that for a given
> numerical type, different compilers have different precisions for the
> given type. They want the same code to work the same with all or many
> compilers. I am looking for descriptions of standard techniques for
> doing that.


I've redirected followups to comp.lang.c.

C99 provides a standard header, <stdint.h>, that provides typedefs for
a variety of exact-width, minimum-width, and "fastest" signed and
unsigned integer types.

If your compiler doesn't support <stdint.h>, it's easy to implement
for any C90 compiler (except that it may or may not support 64-bit
types). See Doug Gwyn's public-domain q8 library, available at
<http://www.lysator.liu.se/c/q8/>.

Many pre-C99 compilers support "long long" and "unsigned long long" as
an extension, though it's not certain that the corresponding printf
formats will be supported by the library.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Does pure, standard C++ alone serve any practical purpose? Peter C++ 8 12-29-2012 05:24 PM
Having compilation error: no match for call to (const __gnu_cxx::hash<long long int>) (const long long int&) veryhotsausage C++ 1 07-04-2008 05:41 PM
Use of Long and Long Long Bart C C Programming 27 01-15-2008 05:27 AM
ANN: New book - C++ Standard Library Practical Tips Greg Reese C++ 0 11-28-2005 04:03 PM
Is it standard and practical to use long long types? Matt C++ 88 04-16-2004 10:11 PM



Advertisments