I
Ian Collins
How would that work? An example would bring some clarification.
That would be the more common use, your example of size_t for example.
Please explain a bit more about 1).
How would that work? An example would bring some clarification.
That would be the more common use, your example of size_t for example.
Please explain a bit more about 1).
K
Keith Thompson
jacob navia said:
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 :
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)
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 :
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
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 :
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.
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
But that doesn't describe a algorithm. (3) A type implies a set of
operations allowed with it. Comes closer.
U
Uncle Steve
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
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
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.
-s
J
jacob navia
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;
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
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 :
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
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
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
Sure there are!
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.
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
The big issue is that a lot of code which assumes that int and long are
interchangeable tends to break.
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
If they aren't defined buy programmers, who are they defined by?
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?
Have you ever used void*? What about a library with an opaque handle type?
gmp has been around for a long time, well before inline function support
was common in C compilers (or even standardised).
S
Seebs
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
Isn't that just for the bootstrap phase of the build? Once it's past
that, it can build its self.
I
Ian Collins
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
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
Oh, no there aren't!
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.
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