Types in C

I

Ian Collins

What do you think of the two definitions
(1) Functional (a type is an algorithm description)

How would that work? An example would bring some clarification.
(2) Conceptual (A type embodies a concept in the program)

That would be the more common use, your example of size_t for example.
And I think I am missing one:

(3) A type implies a set of operations allowed with it.

This would be different than (1) since (1) refers to calculating
the "value" stored in a type.

I am sure (3) is missing but can't really identify it yet as
definitely distinct of (1).

Please explain a bit more about 1).
 
K

Keith Thompson

jacob navia said:
Le 23/05/11 22:03, Keith Thompson a écrit :

You just do not understand Thompson.

C99 6.7.7p3 says:

A typedef declaration does not introduce a new type, only a
synonym for the type so specified.

Is the standard wrong?
 
J

jacob navia

Le 23/05/11 23:25, Ian Collins a écrit :
A typedef may provide an alias to any existing type, built-in, user
defined or even incomplete.

True, but the PURPOSE of typedefs is to HIDE the underlying type so that
source code refers to it INDIRECTLY.

The purpose of that indirection is twofold:
(1) To highlight a CONCEPT of the program:
typedef double CustomerBalance;

(2) To make code portable by abstracting the underlying type
away. (size_t for instance)
 
J

jacob navia

Le 23/05/11 23:29, Ian Collins a écrit :
How would that work? An example would bring some clarification.

Well, in my first answer to Seebs in this thread I wrote:

<quote>
A first tentative, definition for what a type is, could be “a type is a
definition of an algorithm for understanding a sequence of storage
bits”. It gives the meaning of the data stored in memory. If we say
that the object a is an int, it means that the bits stored at that
location are to be understood as a natural number that is built by
consecutive additions of powers of two as specified by its bits.
If we say that the type of a is a double, it means that the bits are to
be understood as the IEEE 754 (for instance) standard sequences of bits
representing a double precision floating point value.
<end quote>

jacob
 
J

jacob navia

Le 23/05/11 23:38, Keith Thompson a écrit :
C99 6.7.7p3 says:

A typedef declaration does not introduce a new type, only a
synonym for the type so specified.

Is the standard wrong?

No, you are wrong.

And since you snip away all my arguments
there is no point in putting any more arguments. They will
be snipped away anyway.
 
I

Ian Collins

Le 23/05/11 23:29, Ian Collins a écrit :

Well, in my first answer to Seebs in this thread I wrote:

<quote>
A first tentative, definition for what a type is, could be “a type is a
definition of an algorithm for understanding a sequence of storage
bits”. It gives the meaning of the data stored in memory. If we say
that the object a is an int, it means that the bits stored at that
location are to be understood as a natural number that is built by
consecutive additions of powers of two as specified by its bits.
If we say that the type of a is a double, it means that the bits are to
be understood as the IEEE 754 (for instance) standard sequences of bits
representing a double precision floating point value.
<end quote>

But that doesn't describe a algorithm. (3) A type implies a set of
operations allowed with it. Comes closer.
 
U

Uncle Steve

A typedef may provide an alias to any existing type, built-in, user
defined or even incomplete.

There are no "user defined" types in C. Structures and unions are
aggregates of basic types (and structures/unions). I believe
incomplete types are a (usually temporary) artifact of the compilation
process and you won't ever see them in a running program.

Correct me if I'm wrong, but I've never heard of a C compiler that
allows you to define something like a BCD integer type when the
compiler has no built-in support for it. This is reasonable since the
compiler can only generate arithmetic code for types it 'understands'.
If you invent your own arithmetic type (as they do in the gmp
library) the compiler 'sees' it as opaque binary data, and arithmetic
operations are carried out with ... macros and function calls.

BTW, have a look at the gmp.h header and note that they do not shy
away from macro-like functions. Not that I care a whole lot, but I'd
say the writers of the gmp library probably know more than you do
about the suitability of inline functions versus macros and when to
use each. Just a 'feeling' on the matter, which is not to say that
you're entirely wrong.



Regards,

Uncle Steve
 
S

Seebs

C99 6.7.7p3 says:

A typedef declaration does not introduce a new type, only a
synonym for the type so specified.

Is the standard wrong?

FREQUENTLY!

.... Although I think at this point you've finally convinced me; it's more
accurate to refer to the things typedefs create as "type names". It's just
that the error of thinking of them as types happens to encourage me to
write better code. :)

-s
 
S

Seebs

How about the idea that typedefs create aliases for the basic built-in
types supplied by the language spec.?

Not just those; you can typedef struct types.
A language that protects you from doing dumb things is good, but
flexibility is sacrificed as a consequence.

I don't think so. If you allow conversions of pointers, and assert that
the "new types" do not participate in the aliasing magic rules (it's not
undefined behavior to access an unsigned int through a pointer to size_t
if size_t is the same underlying type as unsigned int), I think it would
probably be just as flexible a language as it is now, but less error-prone.

People who do a lot of 64-bit development would probably find it very
helpful. :)

-s
 
J

jacob navia

Le 23/05/11 23:51, Ian Collins a écrit :
But that doesn't describe a algorithm.

Type: int

for (result=0,counter=0; counter<CHAR_BIT*sizeof(int);counter++) {
if (int&1)
result += (1 << counter);
}

ValueOfInt = result;

Type float
// Extract sign, mantissa and exponent.
// Apply formula
// result is value of double

Type someStruct

//At offset 0 extract first field
// At offset offsetof(second field) extract second

// etc
 
J

jacob navia

Le 24/05/11 00:02, Seebs a écrit :
FREQUENTLY!

... Although I think at this point you've finally convinced me; it's more
accurate to refer to the things typedefs create as "type names". It's just
that the error of thinking of them as types happens to encourage me to
write better code. :)

-s

The PURPOSE of typedefs is to HIDE the underlying type so that
source code refers to it INDIRECTLY.

The purpose of that indirection is twofold:

(1) To highlight a CONCEPT of the program:
typedef double CustomerBalance;

(2) To make code portable by abstracting the underlying type
away. (size_t for instance)

Typedefs aren't just aliases. Of course technically they are, but their
purpose is portability and clarity.

Obviously this (as anything) can be carried away to ridiculous heights
like:

typedef char g_char;
typedef int g_int;
typedef short g_short;

like in the glib :)
 
U

Uncle Steve

Not just those; you can typedef struct types.


I don't think so. If you allow conversions of pointers, and assert that
the "new types" do not participate in the aliasing magic rules (it's not
undefined behavior to access an unsigned int through a pointer to size_t
if size_t is the same underlying type as unsigned int), I think it would
probably be just as flexible a language as it is now, but less error-prone.
People who do a lot of 64-bit development would probably find it very
helpful. :)

I don't know anything about 64-bit development, I only hope that when
I do eventually get around to trying out my code on x86_64 that my
type usage is consistent enough to avoid major breakage. To this end
I often define integer types by size, and code from there. 'u32' is a
convenient representation of a 32-bit unsigned int, and will never
change from platform to platform if the platform specific typedefs
are written properly in their respective headers. I know I've used
'int' in lots of places, and I don't know if that's really the best
thing yet given the variation in sizeof(int) that apparently exists
out there.



Regards,

Uncle Steve
 
S

Seebs

There are no "user defined" types in C.

Sure there are!
Structures and unions are
aggregates of basic types (and structures/unions).

Sure.

So? Doesn't make them not types. Pointers, arrays, enums, structs,
unions... all types. Structs and unions are user-defined. And they are
types. This makes them... *drumroll* user-defined types.
BTW, have a look at the gmp.h header and note that they do not shy
away from macro-like functions. Not that I care a whole lot, but I'd
say the writers of the gmp library probably know more than you do
about the suitability of inline functions versus macros and when to
use each. Just a 'feeling' on the matter, which is not to say that
you're entirely wrong.

I would guess that one of the times to use macros is "when you have to
be portable to compilers that don't have inline functions". That's
definitely a key application.

-s
 
S

Seebs

I don't know anything about 64-bit development, I only hope that when
I do eventually get around to trying out my code on x86_64 that my
type usage is consistent enough to avoid major breakage.

The big issue is that a lot of code which assumes that int and long are
interchangeable tends to break.
To this end
I often define integer types by size, and code from there. 'u32' is a
convenient representation of a 32-bit unsigned int, and will never
change from platform to platform if the platform specific typedefs
are written properly in their respective headers. I know I've used
'int' in lots of places, and I don't know if that's really the best
thing yet given the variation in sizeof(int) that apparently exists
out there.

In practice, it's a great thing, because you don't actually *care* whether
something is the same size on all machines, you just care whether it's
working well.

I find very little need for int32_t, and very much for int and long.

-s
 
I

Ian Collins

There are no "user defined" types in C.

If they aren't defined buy programmers, who are they defined by?
Structures and unions are
aggregates of basic types (and structures/unions).

Well if you want to be pedantic, unions aren't aggregate types because
they can only contain one member at a time.

Let's expand the above for completeness:

A typedef may provide an alias to any existing type, built-in,
aggregate, union, composite or even incomplete.

There, did I leave anything out?
I believe
incomplete types are a (usually temporary) artifact of the compilation
process and you won't ever see them in a running program.

Have you ever used void*? What about a library with an opaque handle type?
BTW, have a look at the gmp.h header and note that they do not shy
away from macro-like functions. Not that I care a whole lot, but I'd
say the writers of the gmp library probably know more than you do
about the suitability of inline functions versus macros and when to
use each. Just a 'feeling' on the matter, which is not to say that
you're entirely wrong.

gmp has been around for a long time, well before inline function support
was common in C compilers (or even standardised).
 
S

Seebs

gmp has been around for a long time, well before inline function support
was common in C compilers (or even standardised).

More importantly:

gmp is used by gcc.

gcc has a strictly dogmatic requirement that you don't need a very good
or modern compiler to build it.

Therefore gmp must be buildable with a very old compiler.

-s
 
I

Ian Collins

More importantly:

gmp is used by gcc.

gcc has a strictly dogmatic requirement that you don't need a very good
or modern compiler to build it.

Isn't that just for the bootstrap phase of the build? Once it's past
that, it can build its self.
 
I

Ian Collins

Le 23/05/11 23:51, Ian Collins a écrit :

Type: int

for (result=0,counter=0; counter<CHAR_BIT*sizeof(int);counter++) {
if (int&1)
result += (1<< counter);
}

ValueOfInt = result;

I'm sorry, but I still don't see a type defining an algorithm.

I was thinking more along the lines of "struct SomeAlgorithm" where the
struct has function pointer members that implement "some algorithm".
 
S

Seebs

Isn't that just for the bootstrap phase of the build? Once it's past
that, it can build its self.

Yes. But gmp is built first for the bootstrap phase. (At least... It
is in the version I maintain build scripts for. I assume the clever folks
at Code Sourcery know what they're doing.)

-s
 
U

Uncle Steve

Sure there are!

Oh, no there aren't!
Sure.

So? Doesn't make them not types. Pointers, arrays, enums, structs,
unions... all types. Structs and unions are user-defined. And they are
types. This makes them... *drumroll* user-defined types.

Not if we make a finer distinction between types. As I see it there
are two types of types:

char, int, long, float, void *, etc. are /basic types/ fundamental to
the implementation of the C language (and arithmetic operations).
Compound types are aggregates of these basic types as well as compound
types. There's a fundamental difference you are ignoring given a
sufficient vague definition of 'type'.

A real user-defined type would be something new like the complex
numbers extension in gcc. I don't do much OOP, but someone here
probably knows of a language that allows new fundamental type
definitions without direct compiler support. C requires compiler
support for this. So, if you want a 128-byte integer type either you
modify the compiler to emulate arithmetic operations with smaller asm
instructions, or you write a library to handle it.
I would guess that one of the times to use macros is "when you have to
be portable to compilers that don't have inline functions". That's
definitely a key application.

gmp is well into version 4; I doubt it would compile where there is no
support for inline functions, but I have not verified this.



Regards,

Uncle Steve
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,056
Messages
2,570,443
Members
47,090
Latest member
LillieRipl

Latest Threads

Top