C objects

[Stefan Ram]

Now ... what was *your* position again?

I will try to answer this, by commenting your
position below.

Let me summarize my position:
Across different scopes (or different lifetimes) there may be
multiple objects (variables?) with the same identifier name.

I agree to the intended contents of your sentence, while I
might have used different wording to express it.

These objects are separate and distinct from each other; the
mere fact that multiple objects have the same identifier name does
not make them the same object.

Yes.

In addition, I feel that an identifier name declared in two
different functions declares two different identifiers. IOW,
the "i" in foo() is a *different* identifier than the "i" in
bar().

To me, the identifier "i" is the same identifier as the
identifier "i". An identifier is fully given by its
characters. That's the way it is being defined in 6.4.2.1.

"An identifier is a sequence of nondigit characters
(including the underscore _, the lowercase and
uppercase Latin letters, and other characters) and
digits, which designates one or more entities as
described in 6.2.1."

This says, that a single identifier ("An identifier") might
designate multiple entities ("more entities").

There is a Paris in French and a Paris in Texas. The name
"Paris" is the same name as the name "Paris", while it might
have different meanings.

 

[Joe Wright]

Keith Thompson wrote:

E. Robert Tisdale writes:

pete wrote:

junky_fellow wrote:


Is a C object always associated with some "data"?




Normally, yes, though I suppose you could malloc some memory and
free it immediately if you wanted to, without involving any data.




No.

malloc() doesn't create objects.
It returns a pointer of type void*.
A data object must be initialized to a valid value
of an object of that type before you can call it an object --
it must be constructed.





C99 3.14 defines the term "object":

object
region of data storage in the execution environment,
the contents of which can represent values

The term "object" refers to the *region*, not to the data it may
contain.




It *must* be an object of some type.
The type specifies *all* of the values that that object may have.

Please Mr. Tisdale, consider this ..

unsigned int *ui;
ui = malloc(sizeof *ui);

... Assuming malloc() was successful, is ui[0] an object? Of course it
is. Was it created by the declaration of ui? No, declarations don't
define or create objects. I guess malloc() did it.

What if *ui (since it is un-initialized) contains a trap representation?
Is it still considered an int object?

Sure, why not?

 

[RCollins]

E. Robert Tisdale wrote:

Keith Thompson wrote:

E. Robert Tisdale writes:

pete wrote:

junky_fellow wrote:


Is a C object always associated with some "data"?





Normally, yes, though I suppose you could malloc some memory and
free it immediately if you wanted to, without involving any data.





No.

malloc() doesn't create objects.
It returns a pointer of type void*.
A data object must be initialized to a valid value
of an object of that type before you can call it an object --
it must be constructed.






C99 3.14 defines the term "object":

object
region of data storage in the execution environment,
the contents of which can represent values

The term "object" refers to the *region*, not to the data it may
contain.





It *must* be an object of some type.
The type specifies *all* of the values that that object may have.




Please Mr. Tisdale, consider this ..

unsigned int *ui;
ui = malloc(sizeof *ui);

... Assuming malloc() was successful, is ui[0] an object? Of course
it is. Was it created by the declaration of ui? No, declarations
don't define or create objects. I guess malloc() did it.

What if *ui (since it is un-initialized) contains a trap representation?
Is it still considered an int object?

Sure, why not?

I just wanted to make sure I was on the 'same page' as the other
posters in this thread.

 

[Joe Wright]

Joe Wright wrote on 08/08/04 :

unsigned int *ui;

This is the defintion of a pointer. It creates statically a 'pointer'
object. Its value is undeterminate (points anywhere).

ui = malloc(sizeof *ui);

This creates dynamically an object which address is stored into the
pointer 'ui'.

... Assuming malloc() was successful, is ui[0] an object? Of course it
is.

Yes.

Was it created by the declaration of ui?

What declaration ?

No, declarations don't define or create objects. I guess malloc() did it.

I think you are mixing declaration and definition. Of course an object
declaration creates nothing, but an object definition does create an
object.

The point is that a pointer is just a few bytes in memory, but it has a
size, type and address. It is an object.

Thanks ed, you're right, of course. My point is that defining ui as
pointer to unsigned int, while creating the pointer, does not create
the unsigned int. Before the successful malloc() above, the contents
of ui is indeterminate and any reference to *ui or ui[0] causes
undefined behaviour. If, and only if, the malloc() succeeds does
ui[0] become an object.

 

[pete]

Joe Wright wrote:

E. Robert Tisdale wrote:

Keith Thompson wrote:

E. Robert Tisdale writes:

pete wrote:

junky_fellow wrote:


Is a C object always associated with some "data"?





Normally, yes, though I suppose you could malloc some memory and
free it immediately if you wanted to, without involving any data.





No.

malloc() doesn't create objects.
It returns a pointer of type void*.
A data object must be initialized to a valid value
of an object of that type before you can call it an object --
it must be constructed.






C99 3.14 defines the term "object":

object
region of data storage in the execution environment,
the contents of which can represent values

The term "object" refers to the *region*, not to the data it may
contain.





It *must* be an object of some type.
The type specifies *all* of the values that that object may have.




Please Mr. Tisdale, consider this ..

unsigned int *ui;
ui = malloc(sizeof *ui);

... Assuming malloc() was successful, is ui[0] an object? Of course
it is. Was it created by the declaration of ui? No, declarations
don't define or create objects. I guess malloc() did it.



What if *ui (since it is un-initialized) contains a trap representation?
Is it still considered an int object?

Sure, why not?

I just wanted to make sure I was on the 'same page' as the other
posters in this thread.

For
int Integer;
Integer, refers to an object even though it is uninitialized
and may contain a trap representation.

Functions have addresses but they're not objects,
register specified variables don't have addresses, but they're objects.
Except for those two things,
having an address in a C program is equivalent to being an object.

 

[CBFalconer]

.... ******* SNIP 90 odd lines of garbage quotes ******* ...

For
int Integer;
Integer, refers to an object even though it is uninitialized
and may contain a trap representation.

Functions have addresses but they're not objects,
register specified variables don't have addresses, but they're objects.
Except for those two things,
having an address in a C program is equivalent to being an object.

Please snip stuff not germane to your answer.

 

[Rich Grise]

For
int Integer;
Integer, refers to an object even though it is uninitialized
and may contain a trap representation.

Functions have addresses but they're not objects,
register specified variables don't have addresses, but they're objects.
Except for those two things,
having an address in a C program is equivalent to being an object.

So, it's kinda like a function isn't considered an object, by definition?

If I defined a structure with some data members and some pointers to
functions, could I then come up with some rationale for calling that an
"object?" Or is that too much of a stretch?

Thanks,
Rich

 

[Emmanuel Delahaye]

Rich Grise wrote on 11/08/04 :

So, it's kinda like a function isn't considered an object, by definition?

Yes. A function is not an object. It's a function!

If I defined a structure with some data members and some pointers to
functions, could I then come up with some rationale for calling that an
"object?" Or is that too much of a stretch?

A data member is an object
A pointer to a function is an object. The pointee is not an object.
A structure is an object

 

[pete]

So, it's kinda like a function isn't considered an object,
by definition?

Yes.
There are three major catagories of types.
Function types
object types
incomplete types

Function types are defined by their parameter types
and their return types.
Object types like (char), are the types which have determinable sizes.
Incomplete types like (void) or (extern array[]) don't have sizes.

If I defined a structure with some data members and some pointers to
functions,
could I then come up with some rationale for calling that an
"object?" Or is that too much of a stretch?

There's nothing special about a structure being an object.

 

[Rich Grise]

Yes.
There are three major catagories of types.
Function types
object types
incomplete types

Function types are defined by their parameter types
and their return types.
Object types like (char), are the types which have determinable sizes.

This sentence here puts it very concisely. Thanks for this.

Incomplete types like (void) or (extern array[]) don't have sizes.

If I defined a structure with some data members and some pointers to
functions,
could I then come up with some rationale for calling that an
"object?" Or is that too much of a stretch?

There's nothing special about a structure being an object.

Ok, fair enough. What I should do though, is 'splain a little.
I learned to copy-n-paste C many moons ago, by the seat of my
pants with K&R at my elbow. I've been away from programming for
a few years, and now, looking into writing some stuff, I'm almost
overwhelmed with these newfangled languages that seem to have as
a foundation The Language Whose Name Shall Not Be Mentioned++.

Luckily, the main one I'm jumping in at is Qt, which has nice GUI
wrappers.

And so, with my foundation in C, such as it is, I'm trying to wrap my
mind around the philosophy of "Objects" as in The Other Language, or any
of those other OOps things. (is that an ironic acronym, or what? ;-) )

Thanks!
Rich

 

[Rich Grise]

Rich Grise wrote:

There's nothing special about a structure being an object.

I think I'm trying to prove that good ol' C can do anything those
fancy-schmancy OOps things can do - just define your data right.

But I think to do this, you'd have to be a programmer who has
Slack. Not necessarily that particular distro, more the attitude.

Events? Heck, we've got signals, haven't we?

Cheers!
Rich

 

[E. Robert Tisdale]

There's nothing special about a structure being an object.

Sigh.

A 'struct' is not an object.
it introduces a User Defined Type (UDT).
An *object* is an *instance* of some *type*.
For example:

struct X {
int* p;
};

defines a *type* and *not* an object.

// pseudo constructor
struct X X_create(size_t n) {
struct X x; // a reference to the return value
x.p = (X*)malloc(n*sizeof(struct X);
// initialize the return value
return x;
}

int main(int argc, char* argv[]) {
size_t n = 16;
struct X x = X_create(n);
// x is an object of type struct X
// . . .
return 0;
}

The type defines
*all* of the values that an object of that type may have
so an object *must* be initialized to one of those values
if it is to be called an object of that type.

 

[Keith Thompson]

Sigh.

A 'struct' is not an object.

First, he wrote "structure", not "struct". I assume that by
"structure" he meant "an object of a struct type".

For example, given:
struct foo { int whatever; } obj;
it's reasonable to say that "obj" is the name of a structure (which
is, of course, an object). Just as, given
int i;
char c;
it's reasonably to say that "i" is the name of an integer and "c" is
the name of a character.

We can talk about a "struct type" vs. a "struct object", or an
"integer type" vs. an "integer object", if it's not clear from
context. In this case, I think it was.

it introduces a User Defined Type (UDT).

Why the gratuitous abbreviation (WTGA)?

An *object* is an *instance* of some *type*.
Agreed.

For example:

struct X {
int* p;
};

defines a *type* and *not* an object.

Of course.

// pseudo constructor
struct X X_create(size_t n) {
struct X x; // a reference to the return value
x.p = (X*)malloc(n*sizeof(struct X);
// initialize the return value
return x;
}

int main(int argc, char* argv[]) {
size_t n = 16;
struct X x = X_create(n);
// x is an object of type struct X
// . . .
return 0;
}

How is your "pseudo constructor" relevant to the point? Presenting an
example in pseudo-C++ is not helpful.

It would have been polite to try compiling the above code before you
posted it. In your X_create, function, x.p is a pointer to int, but
you assign to it a pointer to X. Presumably "X" should be "struct X";
you can leave out the "struct" keyword in C++, but not in C. You have
mismatched parentheses in the assignment statement.

And of course you cast the result of malloc(), but we've been over
that before.

If you meant the "n" argument to X_create to specify the number of
"struct X"s it would return, your entire interface is broken, since
X_create returns a single "struct X" value. If you meant to have x.p
point to an array of n ints, you're a little closer, but not much.

But even a correct version of your "X_create" function would be beside
the point, so I won't bother to fix it.

The type defines
*all* of the values that an object of that type may have
so an object *must* be initialized to one of those values
if it is to be called an object of that type.

Perhaps, but it doesn't have to be initialized to be called an object.
An object is a "region of data storage in the execution environment,
the contents of which can represent values" (C99 3.14).

And, of course, the term "object" as used in C has nothing at all to
do with object-oriented programming.

 

[pete]

First, he wrote "structure", not "struct". I assume that by
"structure" he meant "an object of a struct type".

Thank you.

Agreed.

I would say that an instance of some type is an object,
but the objects that malloc returns pointers to,
don't have types until they are accessed by an identifier.

N869
3.15
[#1] object
region of data storage in the execution environment, the
contents of which can represent values
[#2] NOTE When referenced, an object may be interpreted as
having a particular type;

Tisdale has some agenda against using the standard's definition
of technical terms. He likes to define technical terms in C
according to his intuition, his American Collegiate Pocket Dictionary
and his recollections of whatever he felt was true about C
the last time that he compiled code.

 

[CBFalconer]

.... snip ...

Tisdale has some agenda against using the standard's definition
of technical terms. He likes to define technical terms in C
according to his intuition, his American Collegiate Pocket
Dictionary and his recollections of whatever he felt was true
about C the last time that he compiled code.

Well, with his return from some sort of hiatus he seems to have
curbed his worst attributes, and should be encouraged somewhat.
If he keeps it up criticism should be limited to technical errors.

 

[pete]

I think I'm trying to prove that good ol' C can do anything those
fancy-schmancy OOps things can do - just define your data right.

The definition wouldn't be an object, though.
The definition would only define the type.
When you declare a variable of that type,
then that identifier would refer to an object.

Object types also apply to constant expressions, which aren't objects.
int (0)
unsigned (0u)
double (0.0)
float (0.0f)

 

[E. Robert Tisdale]

Perhaps, but it doesn't have to be initialized to be called an object.
An object is a "region of data storage in the execution environment,
the contents of which can represent values" (C99 3.14).

And, of course, the term "object" as used in C has nothing at all to
do with object-oriented programming.

 

[E. Robert Tisdale]

Perhaps, but it doesn't have to be initialized to be called an object.
An object is a "region of data storage in the execution environment,
the contents of which can represent values" (C99 3.14).

And, of course, the term "object" as used in C
has nothing at all to do with object-oriented programming.

'When I use a word,'
Humpty Dumpty said, in a rather scornful tone,
'it means just what I choose it to mean, neither more nor less.'

http://sundials.org/about/humpty.htm

What do you think the term 'object" means
in the phrase 'object-oriented programming'?
Are you saying that it is not possible
to write object-oriented programs in C?

Why not say 'region of data storage' instead of object
if that is all that is meant by object?

What I am saying is that the English language is badly abused
in the standards documents.
It converts ordinary English words into meaningless jargon.
These redefinitions narrow the meaning of these words
to the point where it is impossible to make valid inferences
and require the redefinition of other common terms.
For example, your redefinition of object appears to require
the redefinition of the term type
to include *all* of the values that could be represented
by the "region of storage" that you call a type.
This, in turn, seems to imply that the type depends
upon the representation that the programmer chooses
and that data abstraction is impossible in C.

Take for example

struct X {
int* p;
};

struct X x;

Does the object referenced through x include
the region of data pointer to by p?

 

[Keith Thompson]

[Humpty Dumpty quotation deleted'

What do you think the term 'object" means
in the phrase 'object-oriented programming'?

I don't have a good answer to that. All I can say (and all I care to
say) is that the usual meaning of "object" in the context of
object-oriented programming is different from the definition in the C
standard (C99 3.14):

region of data storage in the execution environment, the contents
of which can represent values

NOTE When referenced, an object may be interpreted as having a
particular type; see 6.3.2.1.

(The note is not part of the definition.)

The C90 definition is more verbose (C90 3.14), but it expresses the
same basic idea:

A region of data storage in the execution environment, the
contents of which can represent values. Except for
bit-fields, objects are composed of contiguous sequences of one or
more bytes, the number, order, and encoding of which are either
explicitly specified or implementation-defined. When referenced,
an object may be interpreted as having a particular type, see
6.2.2

(That may not be an exact quote; my copy of the C90 standard makes
cut-and-paste difficult.)

Are you saying that it is not possible
to write object-oriented programs in C?

No, I'm not saying that, nor have I ever said anything resembling it.
Why do you ask?

Why not say 'region of data storage' instead of object
if that is all that is meant by object?

What I am saying is that the English language is badly abused
in the standards documents.
It converts ordinary English words into meaningless jargon.
These redefinitions narrow the meaning of these words
to the point where it is impossible to make valid inferences
and require the redefinition of other common terms.

No, it converts ordinary English words into meaningful jargon. Any
field of discourse has its own jargon, consisting of ordinary words
with specific definitions, phrases, and, in some cases, invented
words. (The word "object" in everyday English has a meaning that's
not particularly useful in the context of programming languages, for
example.)

If you're going to discuss C, as you insist on doing, you have to
understand the way the C standard defines certain terms. If you're
going to use terms defined in the C standard in ways inconsistent with
their definitions, you're going to have difficulties communicating in
this newsgroup (as you've already discovered).

For example, your redefinition of object appears to require
the redefinition of the term type
to include *all* of the values that could be represented
by the "region of storage" that you call a type.

It's not *my* redefinition, it's in the C standard. Apart from that,
I'm not sure what you mean.

This, in turn, seems to imply that the type depends
upon the representation that the programmer chooses
and that data abstraction is impossible in C.
Nonsense.

Take for example

struct X {
int* p;
};

struct X x;

Does the object referenced through x include
the region of data pointer to by p?

Given the C standard's definition of "object", the object named x
includes the storage for x.p, but it doesn't include the region of
data pointed to by x.p. If you want to refer to both x and the data
pointed to by x.p as a single entity, you should choose a name other
than "object"; I suggest "data structure".

 

[pete]

struct X {
int* p;
};

struct X x;

Does the object referenced through x include
the region of data pointer to by p?

No.
x is an object of type struct X.
(sizeof x) is not affected by what x.p points to.
Objects are blocks of contiguous memory.
It's explicitly stated in the C89 object definition.

C89 Last public draft
1.6 DEFINITIONS OF TERMS
* Object --- a region of data storage in the execution environment,
the contents of which can represent values. Except for bit-fields,
objects are composed of contiguous sequences of one or more bytes,
the number, order, and encoding of which are either explicitly
specified or implementation-defined.

A list is not an object.