Re: Implicit int

Rajesh S R <SRRajesh1989@xxxxxxxxx> writes:
On Aug 16, 6:12 am, "Douglas A. Gwyn" <DAG...@xxxxxxxx> wrote:
"Rajesh S R" <SRRajesh1...@xxxxxxxxx> wrote ...

What is the necessity of long long when long int, itself is allowed to
be 64 bits?

There were many platforms already using 32-bit long, and they needed
a wider standard type due size of data objects.to the ever-increasing
For reasons of binary compatibility it wasn't practical to widen an
existing type.

Ok, I agree that one can not widen the exisiting long type for binary
compatibilty. But that can't be an effective reason for standardizing
long long int!
If a 64 bit integer type is desired we can have as int64_t as exact
width integer type from stdint.h, IF it is available with the
implementation, in this case where we don't have long long int.
My point is we can still manage, rather write good codes without long
long int type which is ugly and creates confusion.
stdint.h had already provided effective means of having integer types
of high sizes.

C99 has two parallel sets of integer types. One set is the predefined
types char, short, int, long, long long. The other set is the
exact-size types in <stdint.h>: int8_t, int16_t, in32_t, int_64_t
(which are defined as aliases for the predefined types). But these
serve different purposes. The predefined types are of sizes chosen in
acordance with the characteristics of the underlying architecture.
The intN_t types are of specified sizes (and not all of them
necessarily exist). I suppose C99 could have introduced int64_t
without introducing long long, but IMHO it was better to introduce
both, particularly given that long long had become existing practice.

If I were designing C from scratch, there's no obvious reason why I
wouldn't include "long long" in the set of predefined types. The
names are arbitrary anyway, and it seems sensible to define 5 types
rather than 4 (in either case, some of them may be the same size).

One thing I might have done differently in C99 would be to make the
"fast" types, rather than the exact types, the default. There's a
tendency, I think, to use an exact-width type when what you really
need is merely the fastest (or sometimes smallest) type with at least
a given width. If you're doing calculations that require 16 bits, it
makes sense to use a 32-bit type if it's faster, unless you really
need to store exactly 16 bits due to an externally imposed layout
requirement. So, what C99 calls "intN_t" I'd call "int_exactN_t", and
what C99 calls "int_fastN_t" I'd call "intN_t". Or maybe I wouldn't
have "intN_t" at all, and require users to specify whether they need
"int_exactN_t", "int_fastN_t", or "int_leastN_t".

I'd also considering defining these types with some new syntax that
accepts a constant expression for the width, rather than using a large
set of ad hoc typedefs.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: enum type int or unsigned int?
    ... The constants /themselves/, must have type int. ... I saw that that distinction had been made in C99, ... The identitiers in an enumerator list are declared as constants ... Each enumerated type shall be compatible with an integer type; ...
    (comp.lang.c)
  • Re: enum type int or unsigned int?
    ... The constants /themselves/, must have type int. ... The identitiers in an enumerator list are declared as constants ... Each enumerated type shall be compatible with an integer type; ... C99 6.7.2.2 says: ...
    (comp.lang.c)
  • Re: how to know the size of an int
    ... C99 6.2.6.2 defines width: "The precision of an integer type is ... Thus, in your example the width of `int' is, um, approximately ...
    (comp.lang.c)
  • Re: INT_MIN and compiler diagnostic
    ... value cannot be represented in any integer type. ... except that the C99 6.4.4.1 doesn't say what its type is: ... long int ... list for the constant are signed, the extended integer type shall ...
    (comp.lang.c)
  • Re: Bit-fields and integral promotion
    ... >> The standard very clearly intends to specify the behaviour. ... > whether declared as int or unsigned int, ... "A bit-field is interpreted as a signed or unsigned integer type ... any signed integer type with less precision." ...
    (comp.lang.c)