[META] Talking about talking about C.

[Seebs]

That has changed in the current draft -- it's still described as an object type,
but that no longer implies a complete type.

Yay!

So I was wrong all those years ago arguing with the ADA guy about whether
FILE * could be an opaque type, but soon I'll be right!

-s

 

[Keith Thompson]

While FILE cannot be an incomplete type, can it contain a pointer to one?
In other words, is this legal?

typedef struct
{
struct __file *opaque;
}
FILE;

Sure, though managing the allocation of whatever "opaque" points to
would be a (small) extra burden.

I've thought that this:

typedef unsigned char FILE[__FILE_SIZE];

where __FILE_SIZE is the size of the hidden struct it really points to
would make sense. Or even:

typedef unsigned char FILE;

C99 7.19.3p6:

The address of the FILE object used to control a stream may be
significant; a copy of a FILE object need not serve in place
of the original.

Or, for that matter:

typedef struct __file *FILE;

(A pointer to an incomplete type is a complete type, correct?)

It's FILE, not FILE*, that can't be an incomplete type.

But in C's "Trust the programmer" spirit (see page 3 of the C99
Rationale), I think most implementations just make FILE a typedef
for a struct type, and count on programmers to be sane enough not
to peek inside. (Or to go ahead and peek if they don't care about
portability.)

 

[Seebs]

Well, at one point, I was surprised that a function which is prototyped as
taking a parameter of type "pointer to foo" could be passed a parameter of
type "pointer to bar", if the two typedefs were to the same type.

Huh! Okay, I guess it has surprised at least one person.

While FILE cannot be an incomplete type, can it contain a pointer to one?
In other words, is this legal?

typedef struct
{
struct __file *opaque;
}
FILE;

Or, for that matter:

typedef struct __file *FILE;

(A pointer to an incomplete type is a complete type, correct?)

I think you're right. Pretty!

-s

 

[Keith Thompson]

Yay!

So I was wrong all those years ago arguing with the ADA guy about whether
FILE * could be an opaque type, but soon I'll be right!

Alas, you're still wrong about how the language's name is spelled.
(It's Ada, not ADA; the name is not an acronym.)

Unles you've been arguing with an Americans with Disabilities Act guy
for some reason.

 

[Keith Thompson]

It's FILE, not FILE*, that can't be an incomplete type.

(Memo to self: Pay more attention.)

You're defining FILE as the pointer type, not as the incomplete struct
type. Never mind.

 

[Seebs]

Alas, you're still wrong about how the language's name is spelled.
(It's Ada, not ADA; the name is not an acronym.)

I'm pretty sure I even knew that. At some point.

Unles you've been arguing with an Americans with Disabilities Act guy
for some reason.

Oh, that too. But not about C's file types.

-s

 

[Walter Banks]

[...]
Jacob has implemented user defined data types in his compiler maybe
someone who has used this feature can weigh in with their experience.

I didn't know that. I'd be interested in seeing some documentation
on this feature.

Look for operator overloading and jacob navia

The following (one of many links) has an overview of Jacob's ideas

http://bytes.com/topic/c/answers/212416-operator-overloading-c

That appears to be an unacknowledged copy of a discussion thread
from this newsgroup.

It is syntactically simple BUT the devil is always in the details as
we found out. Even a simple type can have complex implementation
issues that affect application reliability. As well as operators
new data types need casts and other conversion code to be complete.

As far as I can see from the discussion, the extension enables
operator overloading but I don't see anything specific about a
new mechanism for creating new types. It seems to provide a way
to treat types created by existing mechanisms *as if* they were
numeric types, e.g., by applying arithmetic operators to them.

There are two things that need to be done in creating user defined
types. A data type needs to be created through some mechanism and
operators need to be defined. If I read what Jacob has written on
this a new data structure type can be defined with a typedef and
then manipulated with user defined operators. This is a significant
departure from using typedefs by themselves which are restricted
to using C operators defined by the compiler.

In our work on this (Mid 90's) we focused on syntax to define a new
data type, syntax and usage. We could define time for example or
engineering units as part of the number.

There are other standards that can do this in use. IEC 61131 has some
material on engineering units.

Regards,


Walter..

 

[Keith Thompson]

Keith Thompson wrote:
[...]
Jacob has implemented user defined data types in his compiler maybe
someone who has used this feature can weigh in with their experience.

I didn't know that. I'd be interested in seeing some documentation
on this feature.

Look for operator overloading and jacob navia

The following (one of many links) has an overview of Jacob's ideas

http://bytes.com/topic/c/answers/212416-operator-overloading-c

That appears to be an unacknowledged copy of a discussion thread
from this newsgroup.

It is syntactically simple BUT the devil is always in the details as
we found out. Even a simple type can have complex implementation
issues that affect application reliability. As well as operators
new data types need casts and other conversion code to be complete.

As far as I can see from the discussion, the extension enables
operator overloading but I don't see anything specific about a
new mechanism for creating new types. It seems to provide a way
to treat types created by existing mechanisms *as if* they were
numeric types, e.g., by applying arithmetic operators to them.

There are two things that need to be done in creating user defined
types. A data type needs to be created through some mechanism and
operators need to be defined. If I read what Jacob has written on
this a new data structure type can be defined with a typedef and
then manipulated with user defined operators. This is a significant
departure from using typedefs by themselves which are restricted
to using C operators defined by the compiler.

I haven't tried jacob's implementation or read the documentation, so the
following is speculative.

My guess is that, for example, you can write:

typedef struct { int value; } my_int;
my_int operator+(my_int x, my_int y);

but that's just because "my_int" is an alias for the struct type, which
is itself a new type. This could have been written as:

struct my_int { int value; };
struct my_int operator+(struct my_int x, struct my_int y);
typedef struct my_int my_int;

But you can't write:

typedef int my_int;
my_int operator+(my_int x, my_int y);

because the latter is identical to:

int operator+(int x, int y);

In other words, I'm guessing that this extension really has nothing
to do with typedefs. Overloaded operators are syntactic sugar
for things that could have been defined as ordinary functions.
(Note that I didn't write "*just* syntactic sugar"; I'm not
commenting on the merits of the idea.)

Perhaps jacob will jump in and confirm or deny this.

 

[Ian Collins]

I haven't tried jacob's implementation or read the documentation, so the
following is speculative.

My guess is that, for example, you can write:

typedef struct { int value; } my_int;
my_int operator+(my_int x, my_int y);

but that's just because "my_int" is an alias for the struct type, which
is itself a new type. This could have been written as:

struct my_int { int value; };
struct my_int operator+(struct my_int x, struct my_int y);
typedef struct my_int my_int;

But you can't write:

typedef int my_int;
my_int operator+(my_int x, my_int y);

because the latter is identical to:

int operator+(int x, int y);

In other words, I'm guessing that this extension really has nothing
to do with typedefs. Overloaded operators are syntactic sugar
for things that could have been defined as ordinary functions.
(Note that I didn't write "*just* syntactic sugar"; I'm not
commenting on the merits of the idea.)

But you have created a big enough opening to see into the can of worms
this opens up!

 

[jacob navia]

Le 30/10/10 00:52, Keith Thompson a écrit :

Keith Thompson wrote:
[...]
Jacob has implemented user defined data types in his compiler maybe
someone who has used this feature can weigh in with their experience.

I didn't know that. I'd be interested in seeing some documentation
on this feature.

Look for operator overloading and jacob navia

The following (one of many links) has an overview of Jacob's ideas

http://bytes.com/topic/c/answers/212416-operator-overloading-c

That appears to be an unacknowledged copy of a discussion thread
from this newsgroup.

It is syntactically simple BUT the devil is always in the details as
we found out. Even a simple type can have complex implementation
issues that affect application reliability. As well as operators
new data types need casts and other conversion code to be complete.

As far as I can see from the discussion, the extension enables
operator overloading but I don't see anything specific about a
new mechanism for creating new types. It seems to provide a way
to treat types created by existing mechanisms *as if* they were
numeric types, e.g., by applying arithmetic operators to them.

There are two things that need to be done in creating user defined
types. A data type needs to be created through some mechanism and
operators need to be defined. If I read what Jacob has written on
this a new data structure type can be defined with a typedef and
then manipulated with user defined operators. This is a significant
departure from using typedefs by themselves which are restricted
to using C operators defined by the compiler.

I haven't tried jacob's implementation or read the documentation, so the
following is speculative.

My guess is that, for example, you can write:

typedef struct { int value; } my_int;
my_int operator+(my_int x, my_int y);

but that's just because "my_int" is an alias for the struct type, which
is itself a new type. This could have been written as:

struct my_int { int value; };
struct my_int operator+(struct my_int x, struct my_int y);
typedef struct my_int my_int;

But you can't write:

typedef int my_int;
my_int operator+(my_int x, my_int y);

because the latter is identical to:

int operator+(int x, int y);

In other words, I'm guessing that this extension really has nothing
to do with typedefs. Overloaded operators are syntactic sugar
for things that could have been defined as ordinary functions.
(Note that I didn't write "*just* syntactic sugar"; I'm not
commenting on the merits of the idea.)

Perhaps jacob will jump in and confirm or deny this.

You are right. The result of compiling

> typedef int my_int;
> my_int operator+(my_int x, my_int y);

is:

Error foo.c 2: operator redefinition needs at least one user defined type.

jacob

 

[Nick Keighley]

You can start by giving typedef some teeth, or replacing/augmenting it with
something stronger.
As it stands, typedef has about as much force as Hungarian Notation.

nonsense. Although I have a (slight) reservation about the name it
definitly serves a purpose. Building complex type declarations is a
*lot* easier with typedef.

Try defining and array of functions taking a function as an argument
and returning a function.

Take a loook at the definition at the signal function:-

void (*signal(int sig, void (*func)(int)))(int);

 

[BartC]

nonsense. Although I have a (slight) reservation about the name it
definitly serves a purpose. Building complex type declarations is a
*lot* easier with typedef.

Try defining and array of functions taking a function as an argument
and returning a function.
Take a loook at the definition at the signal function:-

void (*signal(int sig, void (*func)(int)))(int);

In this case typedef solves a problem that it shouldn't need to solve, if
type declarations had a sane syntax.

My CDECL program no longer works under my 64-bit OS, so I have no idea what
that type declaration is saying. But you shouldn't need to use unreliable
3rd-party tools to find out what a language syntax is doing!

(And if anyone says, why don't I learn C, then please explain why CDECL
exists in the first place...)

 

[Ben Bacarisse]

Nick Keighley ha scritto:

http://www.cdecl.org/ gives syntax error on that.

That's unfortunate. It should be able to handle such things.

To read it, start at the name and work right (if possible) and then
left, respecting the nesting of the parentheses:

1 signal
2 ( )
3 int sig
4 ,
5 *func
6 ( )
7 int
8 void
9 *
10 ( )
11 int
12 void

1 signal is
2 a function taking
3 an int (called sig)
4 and
5 a pointer (called func) to
6 a function taking
7 an int
8 which returns void
9 which returns a pointer to
10 a function taking
11 an int
12 which returns void.

 

[BartC]

Nick Keighley ha scritto:

http://www.cdecl.org/ gives syntax error on that.

Thanks for the link...

I made a few changes (by trial and error), and the following 'works':

void (*signal (int, void (*)(int))) (int);

And the answer is:

"declare signal as function (int, pointer to function (int) returning void)
returning pointer to function (int) returning void"

(Of course we don't know if that was what was intended..)

This is still a little difficult to take it (it's not clear which
'returning' belongs to which 'function'. By writing in one of the various
syntaxes I've proposed in the past:

function signal (int, *function (int)) *function(int);

ie. using the pattern 'function name(arguments,..)result', and suppressing
'result' when the return type is void, I think this is clear enough not to
need typedef.

(Unless of course a particular subtype, such as *function(int) here, occurs
in enough places, and necessarily has to be identical in each place, to
warrant giving it it's own identity, but that would be option not a
necessity...)

 

[BartC]

That's unfortunate. It should be able to handle such things.

To read it, start at the name and work right (if possible)

Presumably, the first name (of the three)?

 

[Ben Bacarisse]

Presumably, the first name (of the three)?

It's always the one inside the fewest brackets. The trouble comes when
you are reading a "type-name" rather than a declaration because the name
will be missing. You have to find where it *would* be. It's actually
easy when you've done a few, but its hard to explain. The name would go
either to right of a parenthesised '*'

void (* )(int);
^ here

or immediately to the left of a bracket that denotes an array or a
function:

void (int);
^ here
or
int [42];
^

 

[Nick Keighley]

and this horror actually comes out of the standard!

In this case typedef solves a problem that it shouldn't need to solve, if
type declarations had a sane syntax.

we are where we are. They say every great language has an experiment
that didn't quite work.

My CDECL program no longer works under my 64-bit OS, so I have no idea what
that type declaration is saying. But you shouldn't need to use unreliable
3rd-party tools to find out what a language syntax is doing!

(And if anyone says, why don't I learn C, then please explain why CDECL
exists in the first place...)

I usually pick em apart by hand. And then bung in lots of typedefs so
I never have to do it again!

the other use for tyepdef is to hide the concrete types. I'm not a fan
of heavy use of int32 and so on. But I find Byte or Octet a nice
shorthand for unsigned char. Application specific type aliases can be
useful

typedef double Latitude;

though of course you can still stuff a Weight into a Latitude and get
no squeals from the compiler...

 

[Nick Keighley]

He said "we" and so "identifies" with "engineers" (we have the beginnings
of a parseable language).


You are so wrong. "engineers" are *not* the "it's black or white"/"yes or
no", they are *not* programmers. Are you afflicted as a programmer?

even programmers aren't quite that bad!

"this program works well"
"that function is too big"
"comments like that are a design smell" (though I'm not fond of the
smell metaphor)

"so"? OK, you are not an engineer but you admire those and wannabe one.
What company to you want to work for? NASA? MS? Do tell.

I can't see how you read that into what he said

 

[Nick Keighley]

I was just kidding, I couldn't resist. (OK, I'm bad now... I'm still an
angel compared to "y'all", especially that Kite guy).

Kite guy?

 

[lawrence.jones]

Alas, you're still wrong about how the language's name is spelled.
(It's Ada, not ADA; the name is not an acronym.)

Unles you've been arguing with an Americans with Disabilities Act guy
for some reason.

Or the American Dairy Association.