"Referenced type "

[Keith Thompson]

You can't declare an object of type void (or of any other incomplete
type, such as "struct this_type_has_not_yet_been_defined").

[...]

Apparently I was mistaken. It would have been more accurate to say
that you can't *define* an object of any incomplete type. (And you
can't even declare an object of type void.)

I actually hadn't been aware that you can declare an object of an
incomplete type.

 

[Flash Gordon]

Didn't I just read here in the last day that only an error was a diagnostic?

Whatever floats your boat.

An error is also a diagnostic. An informational message could also be a
diagnostic (yes, some systems have erros, warnings and informational
messages, but I don't know if they use informational messages for
diagnostics on compiling C). A suitably nasty compiler could punch you
on the nose as a diagnostic.

A blood orange is an orange.
A seville orange is an orange.
Both of the above are fruit. An apple is also fruit.

 

[Keith Thompson]

Something that is incomplete isn't the thing. It has the potential
to become the thing, when made complete.

No, that's not what "incomplete type" means in C. The standard
defines the term "incomplete type" in C99 6.2.5p1:

... and _incomplete types_ (types that describe objects but lack
information needed to determine their sizes).

Where the standard defines a term, that definition overrides the
ordinary English meaning of the word(s) making up the term.

An "incomplete type" is a type.

 

[Phil Carmody]

Didn't I just read here in the last day that only an error was a diagnostic?

Did you? From whom?

Phil

 

[jameskuyper]

Something that is incomplete isn't the thing. It has the potential to become
the thing, when made complete.

That's at best a highly debatably argument, even in ordinary English
usage. However, we're not talking about ordinary English usage here.
The standard defines the terms "type" and "incomplete type", and it
specifies that "Types are partitioned into _object types_ (types that
fully describe objects), _function types_ (types that describe
functions), and _incomplete types_ (types that describe objects but
lack information needed to determine their sizes)."

There are two distinct ways in which this statement makes it clear
that, as the C standard defines the term, "incomplete types" are a
subset of "complete types". The first is the fact that the category
"types" is being partitioned, and that "incomplete types" describes
one of the sub-categories it is being partitioned into. The second way
is based upon the fact that the phrase "incomplete types" is
italicized in this paragraph. According to ISO conventions, that
indicates that this particular paragraph defines what the phrase
"incomplete types" means, as far as the C standard is concerned. That
definition specifies that they are "types that ...". In other words,
incomplete types ARE types.

What happens to an incomplete type when it is completed is that it
becomes a function or object type; it does not, however, change from
not being a type to being a type.

 

[jameskuyper]

jameskuyper wrote:
....

that, as the C standard defines the term, "incomplete types" are a
subset of "complete types". The first is the fact that the category

As written, that is of course complete nonsense. That was a typo - the
word "complete" was not supposed to be there. Sorry for the confusion!

 

[Phil Carmody]

That is a positive statement, not the usual claptrap spouted on c.l.c about it
being something but missing part of the something.

Now does anything in object conflict?

All the colourless ones conflict furiously.

Phil

 

[Phil Carmody]

I sell you a car without an engine. I call it a "car" not a "car without an
engine" Are you upset?

It's not a car without an engine, it's a car without insurance.

Phil

 

[Keith Thompson]

That is a positive statement, not the usual claptrap spouted on
c.l.c about it being something but missing part of the something.

I have no idea what "usual claptrap" you're talking about. As far as
I can tell, everyone here has been talking about "incomplete types"
and stating that an incomplete type is a type. Now you've seen the
definition in the standard that confirms that we were all right, and
you were mistaken. (That's not an attack; we all learn things here.)

To describe it another way, an "incomplete type" is a type that is
incomplete. The fact that it has the attribute of being "incomplete"
doesn't mean it's not a type, just that it's a particular kind of
type.

In other contexts, the English phrase "an incomplete foo" might refer
to something that is not a "foo", but could become one if it were
completed. But, as we've told you repeatedly, that's not what the
phrase "incomplete type" (which you *could* have looked up yourself;
see n1256.pdf) means.

Now does anything in object conflict?

Please rephrase that so it makes sense.

 

[jameskuyper]

I sell you a car without an engine. I call it a "car" not a "car without an
engine" Are you upset?

To describe something as complete means that is is lacking something
needed to make it complete. That can, but does not have to, mean that
it's missing something it needs to have to retain it's identity.

For instance, someone who is missing important body parts could be
described as "an incomplete human being". Would you say that this
person is not a human being? If that person still has at least one ear
and a brain, both still functioning normally and connected to each
other, would you say it in a place where that person could hear you?

A store offers an incomplete selection of shoe sizes. Do you therefore
conclude that it doesn't offer a selection of shoe sizes? It might
have only size 9 and size 14; but you do still have a selection of
those two sizes to choose from.

A mosaic may be incomplete because it is missing some tiles; most
mosaics that are of any significant age (including virtually every one
that is a museum piece) is incomplete. Does that mean that they are
not mosaics?

An incomplete list of planets in this solar system is still a list of
planets in this solar system.

A set of tableware that only contains 4 place setting rather than the
6 it originally had is incomplete, but it is still a set of tableware.

 

[jameskuyper]

jameskuyper wrote:
....

To describe something as complete means that is is lacking something
needed to make it complete.

Once again, I turned my sentence into nonsense with a simple typo.
Sorry! The first "complete" should have been "incomplete".

 

[Richard Bos]

Didn't I just read here in the last day that only an error was a diagnostic?

Probably from Han. Or Chuck.

Richard

 

[Richard Bos]

I sell you a car without an engine. I call it a "car" not a "car without an
engine" Are you upset?

I sell you a house without any furniture. I call it a "house", not an
"incomplete house". Are you upset? After you've seen my taste in
furniture, are you still upset? If so, do you have any taste at all?

Richard

 

[Richard Bos]

struct houses {...};

struct houses * p;

p += 2;

What if Nelu lives on the end of the street?

Richard

 

[Richard Bos]

I used to have a problem understanding the difference between, say, an int
object and an int value, especially in languages having proper constants.
Imagine C has a 'constant' prefix, similar to an enum:

int x;
constant int y=42;
x=41;

Both x and y are of type int, yet &x is allowed but not &y.

I think you'll find that C writes this as

#define y 42

Richard

 

[Keith Thompson]

Could have been Chuck.

I don't think so; I probably would have remembered a mistake like
that. HfC might have said something like that (and if so, I would
have missed it). Or you might be misremembering.

In any case, a warning message can be a diagnostic.

 

[Keith Thompson]

I'm not mistaken, nor am I mistaken about the claptrap that is used
here. The standard says in a positive manner (set union) what it
is. The claptrap usually used here is used in a subtractive
(subset) manner without proper foundation.

You were mistaken in your stated opinion that void" is not a type.

Upthread, you wrote:
| Maybe I'm wrong but I thought void was the absence of a type.

and Eric Sosman replied:
| You are, and it's not. `void' is a perfectly good type, a type
| that happens to be incomplete (and uncompletable), but a type
| nonetheless.

I fail to see how Eric could have made it any clearer that void is a
type. Nevertheless, you then replied:
| Sounds like the answer "It is noon" to the question, "It is sunny
| outside?"

To say "it is a type that is incomplete" isn't correct.

Sure it is. "incomplete" is an adjective. "type" is a noun.
Do the math^H^H^H^H grammar.

[...]

I make mistakes all the time. Admitting it gets easier with practice.

 

[Guest]

Invariably the people making these objections have never worked in teams
or educated students/new employees and think they're being clever by
being so pedantic

I'm the exception to this in that I've worked in teams and helped
people
learn C! One guy once said "you always get your money's worth when you
ask
Nick a question!"

 

[Tim Rentsch]

[snip]

What happens to an incomplete type when it is completed is that it
becomes a function or object type; [snip]

Yes. More specifically it becomes an object type.

 

[Guest]

To describe something as complete means that is is lacking something
needed to make it complete. That can, but does not have to, mean that
it's missing something it needs to have to retain it's identity.

<snip>

Is there a philosopher in the house? I bet there are whole
news groups devoted to debating the meaning of "complete"