C objects

[junky_fellow]

What is a C object ?

If i have some function "func()" in my C program, then
can i say that "func()" is a C object ?
or if i have some function pointer (ptr) which contains the address
of function "func()", can i say that ptr is pointing to some C object ?

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

thanx in advance for any help .....

[RCollins]

E. Robert Tisdale wrote:

Mike Wahler wrote:

E. Robert Tisdale wrote:

A data object must be initialized to a valid value
of an object of that type before you can call it an object --

Not true.

it must be constructed.

"Constructe d" doesn't have a meaning in C.

int main(int argc, char* argv[]) {
int i; // is 'i' an object? The language standard says it is
return 0;
}

Whatever value 'i' has must be a valid int.

typedef struct X {
int* p;
} X;

int main(int argc, char* argv[]) {
X x; // is 'x' a valid object?
return 0;
}

Sure, X is a valid object; it is a structure containing a pointer.
Since it is never used, the compiler may choose to optimize it
away, but as far as your source code is concerned, it is a real thing.

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

[pete]

E. Robert Tisdale wrote:

Keith Thompson wrote:

E. Robert Tisdale writes:

pete wrote:

junky_fell ow 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.

Keith Thompson is right and you are completely wrong.

N869
6.2.5 Types
[#1] The meaning of a value stored in an object or returned
by a function is determined by the type of the expression
used to access it. (An identifier declared to be an object
is the simplest such expression; the type is specified in
the declaration of the identifier.)

If you have
signed char Integer = -1;
then Integer is less than zero.
but (*(unsigned char *)&Integer) is a positive value
and there's only one object under discusion there.
The statement
--*(unsigned char *)&Integer;
decrements an object of type unsigned char.

[Mike Wahler]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote in message
news:cf******** **@nntp1.jpl.na sa.gov...

Mike Wahler wrote:

E. Robert Tisdale wrote:

A data object must be initialized to a valid value
of an object of that type before you can call it an object --
Not true.

it must be constructed.

"Constructe d" doesn't have a meaning in C.

int main(int argc, char* argv[]) {
int i; // is 'i' an object? The language standard says it is
return 0;
}

Whatever value 'i' has must be a valid int.

Right. But 'i' isn't required to represent a value.
That's what 'uninitialized' means.

typedef struct X {
int* p;
} X;

int main(int argc, char* argv[]) {
X x; // is 'x' a valid object?

Yes. But it doesn't represent any meaningful value.

-Mike

[Mike Wahler]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote in message
news:cf******** **@nntp1.jpl.na sa.gov...

Keith Thompson wrote:

E. Robert Tisdale writes:

pete wrote:

junky_fell ow 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.

Note that it's. "May", not "must". Verbatim from the standard:
"can represent values." When the standard means "must", it
says "must". Here, it does not.

-Mike

[RCollins]

Stefan Ram wrote:

RCollins <rc***@nospam.t heriver.com> writes:

So, by this reasoning, then the 2 functions (in the same source
file) below:
void foo(void) {
int i;
i = 1;
}
void bar(void) {
int i;
i = 2;
}
define only 1 identifier, that happens to have 2 different
object locations?

Yes, just let me quote ISO/IEC 9899:1999 (E):

"For each different entity that an identifier designates,
the identifier is visible (i.e., can be used) only
within a region of program text called its scope."

^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^

Notice the part that I underlined. This would tell me that the
var i inside foo() is different than the var i inside bar(); they
just happen to have the same name.

Note the singular "an identifier". "An identifier" (i.e., only
1 identifier) might designate different entities. This is the
wording of ISO/IEC 9899:1999 (E).

Another reason: An identifier is a lexical concept and is
defined as:

(6.4.2.1) identifier:
identifier-nondigit
identifier identifier-nondigit
identifier digit

So by this extensional definition, there exist only one
identifier "i".
This is just a rule on how to spell identifiers. Let me put this
another way: if I generate a lexical parse tree for the 2 functions
foo() and bar() above, would you expect that the var i appears only
once?

I don't think we're on the same wavelength at all. We're (or, at
least, I) are not talking about what happens at run-time. We're
talking about source code (the only part we have any real control
over).

The source code model does not contain the notion of an
"object". The source code is built of lexical and syntactical
units. An object is part of the execution model, though in
order to interpret (make sense of) the source code, one needs
to mention execution model entities.

in the simple function:
void foo(void) {
int i;
}
the identifer i refers to an object of type integer; if I never use
the variable, or if foo() is explicitly never called, then the
compiler may choose to optimize it away. But, as far as my (source)
program is concerned, both foo() and i exist, and refer to somthing
concrete.

This is not a mere "optimizati on". The local variables of a
function are created as many times as the function is
activated at run time - otherwise recursion would not work.
So, if a function is not activated, there is not reason to
create activation records.

Yes, but what has this to do with identifiers or object names?
For the most part, I would not expect an identifier to survive
the compiler ... only references to stack or memory locations.
(There are exceptions, of course, especially if you are generating
debugging code).

The identifier "i" refers to an object under the assumption
that the function is currently activated. This is usually
taken for granted, so that one does not mention it. By
recursion, a function may be activated more than once in the
same program instance at the same time. In this case, when one
speaks about "i" one usually is referring to an exemplary i
from all those is existing at the same time.

So, then, each time a function is called (recursive or not),
you get a new object named "i" (for example) that is different
than any other object named "i".

I think this is what I started out saying several posts ago.

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

[Joe Wright]

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.
--
Joe Wright mailto:jo****** **@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Emmanuel Delahaye]

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.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html

"C is a sharp tool"

[Keith Thompson]

A note to Stefan Ram:

You indent all your new text. Please don't do this; it's confusing.
Indentation usually indicates that you're quoting someone else. New
text should be left-justified, like this.

Thank you.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[E. Robert Tisdale]

Mike Wahler wrote:

E. Robert Tisdale wrote:

Mike Wahler wrote:

E. Robert Tisdale wrote:

A data object must be initialized to a valid value
of an object of that type before you can call it an object --

Not true.

it must be constructed.

"Constructed " doesn't have a meaning in C.

int main(int argc, char* argv[]) {
int i; // is 'i' an object? The language standard says it is
return 0;
}

Whatever value 'i' has must be a valid int.

Right. But 'i' isn't required to represent a value.
That's what 'uninitialized' means.

typedef struct X {
int* p;
} X;

int main(int argc, char* argv[]) {
X x; // is 'x' a valid object?

Yes. But it doesn't represent any meaningful value.

Then your definition of *type* makes no sense.
A type defines *all* of the values that an object may have.
You seem to be saying that an "uninitiali zed" object
may have [redundant] meaningless values.
By your definition, the values that a type may have
is determined by its representation
which means that data abstraction is not possible in C.

You are interpreting the C standards documents too literally.
And just like the fundamentalists
who interpret Holy Scripture too literally,
you eventually encounter contradictions to logic and common sense.

[RCollins]

Stefan Ram wrote:

RCollins <rc***@nospam.t heriver.com> writes:

"For each different entity that an identifier designates,
the identifier is visible (i.e., can be used) only
within a region of program text called its scope."

^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^
Notice the part that I underlined. This would tell me that the
var i inside foo() is different than the var i inside bar(); they
just happen to have the same name.

As it has been noticed before, "var" is an informal term in C,
so you might use it this way. The notion "the var i" is not
the same notion as the notion "the identifier i", because the
meaning of "identifier " is defined by ISO/IEC 9899:1999 (E).

(6.4.2.1) identifier:
identifier-nondigit
identifier identifier-nondigit
identifier digit

This is just a rule on how to spell identifiers. Let me put this
another way: if I generate a lexical parse tree for the 2 functions
foo() and bar() above, would you expect that the var i appears only
once?

It is possible that the text "i" is stored only once in the
memory of the parser, when the parse tree actually is a direct
acyclic graph. This is an implementation detail of a parser.

This is not a mere "optimizati on". The local variables of a
function are created as many times as the function is
activated at run time - otherwise recursion would not work.
So, if a function is not activated, there is not reason to
create activation records.

Yes, but what has this to do with identifiers or object names?

It has only to do with identifieres as long as the source
code is taken into consideration.

For the most part, I would not expect an identifier to survive
the compiler ... only references to stack or memory locations.
(There are exceptions, of course, especially if you are generating
debugging code).

(...)

So, then, each time a function is called (recursive or not),
you get a new object named "i" (for example) that is different
than any other object named "i".

Independend of the language "C", the identifier "i" and the
meaning of "object": it is part of the meaning of the word
"other", that any object is different than any /other/ object.

What remains is: A single identifier of the source code might
refer to several objects at run time, either by multiple
scopes, or by multiple life-times, or by both.

While I appreciate your obvious knowledge (and it *is* vast),
I have completely lost track of where *you* stand in all this.

Let me summarize my position:
Across different scopes (or different lifetimes) there may be
multiple objects (variables?) with the same identifier name.
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. 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(). (In other languages, this
would be explicitly called out by the full identifier of foo::i
or bar::i). So long as the compiler can tell the difference,
I don't really care how the run-time environment stores them
(or even *if* it stores them).

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

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"