C objects

"Mabden" <mabden@sbc_global.net> writes:

"junky_fellow" <ju**********@yahoo.co.in> wrote in message
news:8c**************************@posting.google.c om...
What is a C object ?

C has objects? When did that happen?!

Boy I have GOT to get one of these new "standards" gizmos...

Yes, C has objects. (They have nothing to do with what's commonly
called "object-oriented programming".)

--
Keith Thompson (The_Other_Keith) 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.

Nov 14 '05 #4

junky_fellow wrote on 07/08/04 :

What is a C object ?
A variable.
If i have some function "func()" in my C program, then
can i say that "func()" is a C object ?
Nope.
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 ?
Nope.
Is a C object always associated with some "data" ?

It *is* data.

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

"C is a sharp tool"

Nov 14 '05 #5

Jack Klein

On Sat, 07 Aug 2004 10:05:46 GMT, Keith Thompson <ks***@mib.org> wrote
in comp.lang.c:

"Mabden" <mabden@sbc_global.net> writes:
"junky_fellow" <ju**********@yahoo.co.in> wrote in message
news:8c**************************@posting.google.c om...
What is a C object ?

C has objects? When did that happen?!

Boy I have GOT to get one of these new "standards" gizmos...

Yes, C has objects. (They have nothing to do with what's commonly
called "object-oriented programming".)

....and interestingly enough, if slightly OT, is the fact that the
definition of the term 'object' in C++ is the same as it is in C.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

Nov 14 '05 #6

Jack Klein

On Sat, 07 Aug 2004 15:49:48 +0200, Emmanuel Delahaye
<em***@YOURBRAnoos.fr> wrote in comp.lang.c:

junky_fellow wrote on 07/08/04 :
What is a C object ?

A variable.

const int x = 10;

'x' is an object.

char *hello_world = "hello world";

Both the pointer and the string literal it points to are objects.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

Nov 14 '05 #7

ra*@zedat.fu-berlin.de (Stefan Ram) writes:

Emmanuel Delahaye <em***@YOURBRAnoos.fr> writes:
What is a C object ?

A variable.

An object is a region of data storage in the execution
environment (3.14).

A variable is an identifier for an object introduced by a
declaration.

An object does not need to have a variable.

The C standard does not define the term "variable". It uses it
informally, but only a few times.

There was a long and futile discussion here recently about whether
something like *ptr is a variable (there is no definitive answer).

<OT>The C++ standard does define the term "variable"; I don't remember
what the definition is.</OT>

--
Keith Thompson (The_Other_Keith) 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.

Nov 14 '05 #8

junky_fellow wrote:

What is a C object?
A *data* object.
If I have some function "func()" in my C program,
then can I say that "func()" is a C object?
Yes.
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?
Yes.
Is a C object always associated with some "data"?

Yes. Objects are *data* objects
in the context of any computer programming language.

Be aware that the term *object* also has a special meaning
in the context of ISO C standards documents
which corresponds roughly to mutable storage, lvalues or variables.

Nov 14 '05 #9

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.

Nov 14 '05 #10

"Mabden" <mabden@sbc_global.net> wrote in message
news:Kh****************@newssvr27.news.prodigy.com ...

"junky_fellow" <ju**********@yahoo.co.in> wrote in message
news:8c**************************@posting.google.c om...
What is a C object ?

C has objects? When did that happen?!

Boy I have GOT to get one of these new "standards" gizmos...

C has always had objects. An example:

int i; /* an object of type 'int' */

-Mike

Nov 14 '05 #11

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

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.

Correct.
It returns a pointer of type void*.
... at which address an object or objects may be stored.
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 i; /* is 'i' an object? The language standard says it is */
return 0;
}

-Mike

Nov 14 '05 #12

E. Robert Tisdale wrote on 07/08/04 :

What is a C object?
A *data* object.
If I have some function "func()" in my C program,
then can I say that "func()" is a C object?

Yes.

No.

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?

Yes.

No.

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

Yes. Objects are *data* objects
in the context of any computer programming language.

So how a function could be an object ? There is a flaw in your logic.
BTW, the forum topic is unambigous. It's the C-language, opposite to
'any computer programming language'
Be aware that the term *object* also has a special meaning
in the context of ISO C standards documents
which corresponds roughly to mutable storage, lvalues or variables.

Yes, this is why a function is not an object.

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

"C is a sharp tool"

Nov 14 '05 #13

RCollins

Stefan Ram wrote:

"Mike Wahler" <mk******@mkwahler.net> writes:
int i; /* is 'i' an object? The language standard says it is */

'i' is an identifier.

Yes, it identifies an object of the type integer.

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

Nov 14 '05 #14

RCollins

Stefan Ram wrote:

RCollins <rc***@nospam.theriver.com> writes:
int i; /* is 'i' an object? The language standard says it is */

'i' is an identifier.
Yes, it identifies an object of the type integer.

The number of objects being bound to i depends on the
execution.

Here is one 'i' (in the source code) being bound to up to 3
objects during execution and another one being bound to no
object at all.

#include <stdio.h> /* printf */

int main( void ) { int i; static char count = 0;
if( count++ < 3 )main();
else printf( "Now we got 3 int objects!" ); }

Since you are calling main() recursively, aren't you actually
creating 3 different i's? Each i is _not_ the same, even though
they happen to have the same name.

static int main0( void )
{ int i; /* this "i" never is never bound to any object */ }

In the declaration "static int i;" the "i" is better suited to
be identified with an object (for each instance of program
execution).

"Bound"? I don't know what that means in C (although I understand
the concept from ProLog). In this case, your example seems very
compiler-specific (or perhaps, optimization-specific). The compiler
is perfectly free to allocate memory storage to i, even if it is
never used to store a value. That would make i an object, regardless
of what (if anything) is stored in it. BTW, I don't see a "static int i"
anywhere ... you declared main() as static, but not the varible i.

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

Nov 14 '05 #15

ra*@zedat.fu-berlin.de (Stefan Ram) writes:

Keith Thompson <ks***@mib.org> writes:
ra*@zedat.fu-berlin.de (Stefan Ram) writes:
A variable is an identifier for an object introduced by a
declaration.

The C standard does not define the term "variable". It uses it
informally, but only a few times.

Yes.
(An approximate meaning might be derived from those uses.)

All the uses in the standard refer to individual declared objects.
There aren't nearly enough to infer whether the term refers *only* to
individual declared objects.

There was a long and futile discussion here recently about whether
something like *ptr is a variable (there is no definitive answer).

I would not call it a variable. Obviously, it is an expression.

It's an expression that refers to an object (assuming there's actually
an object at the address to which ptr points). The question was
whether that object is a "variable" (likewise for array elements,
struct members, and so forth), or whether the term only refers to
declared named objects.

There is no answer to this question. Given a declaration like
"int i;", we can safely refer to i as a "variable"; for more complex
cases, we should stick to the more formal term "object".

--
Keith Thompson (The_Other_Keith) 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.

Nov 14 '05 #16

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> 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.

--
Keith Thompson (The_Other_Keith) 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.

Nov 14 '05 #17

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.

Nov 14 '05 #18

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.

typedef struct X {
int* p;
} X;

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

Nov 14 '05 #19

RCollins

Stefan Ram wrote:

RCollins <rc***@nospam.theriver.com> writes:
int main( void ) { int i; static char count = 0;
if( count++ < 3 )main();
else printf( "Now we got 3 int objects!" ); }
Since you are calling main() recursively, aren't you actually
creating 3 different i's? Each i is _not_ the same, even though
they happen to have the same name.

Yes, one can see it this way.

Actually it depends on the mode of speech:

"Ronald" is a name.
Ronald is a person.
While there are more Ronalds than one Ronald, there is still
only one name "Ronald", but there are several Ronalds.

In the source code, there is exactly one identifier "i".
Executing the program does not change the number of "i"s in
the source code. The identifier "i" is a ("static") entity of
the source code model. An object is a ("dynamic") entity of
the execution model. How these models relate to each other is
being described by the C language specification.

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?

static int main0( void )
{ int i; /* this "i" never is never bound to any object */ }

"Bound"? I don't know what that means in C (although I understand
the concept from ProLog).

The specification in fact does not use this wording.

I am using the term "binding" to refer to a relation between
an identifier (as an element of the source code model) to an
object (as an element of the execution model). ISO/IEC 9899:1999
(E) uses wording such as "denotes", "designates" or "refers".

In this case, your example seems very
compiler-specific (or perhaps, optimization-specific). The compiler
is perfectly free to allocate memory storage to i, even if it is
never used to store a value. That would make i an object, regardless
of what (if anything) is stored in it.

Usually an "activation record" is created, when a function is
being executed, often on the "stack". The automatic variables
and parameter variables are bound to storage in this
"activation record". When a function is not being activated,
it would make no sense to create such an activation record,
although I can not exclude that some compiler might create
code to do so, but this would at least partially execute
a function, which is never called.

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).

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.
--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

Nov 14 '05 #20

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.

"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.

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"

Nov 14 '05 #21

pete

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.

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.

Nov 14 '05 #22

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:cf**********@nntp1.jpl.nasa.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.

"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.

-Mike

Nov 14 '05 #23

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

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.

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

Nov 14 '05 #24

RCollins

Stefan Ram wrote:

RCollins <rc***@nospam.theriver.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 "optimization". 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"

Nov 14 '05 #25

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 ---

Nov 14 '05 #26

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"

Nov 14 '05 #27

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_Keith) 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.

Nov 14 '05 #28

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 "uninitialized" 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.

Nov 14 '05 #29

RCollins

Stefan Ram wrote:

RCollins <rc***@nospam.theriver.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 "optimization". 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"

Nov 14 '05 #30

RCollins

E. Robert Tisdale wrote:

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 "uninitialized" 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.

I think, in this case, "unitialized" might mean "unknown".
For example:

void foo(void) {
int i; /* uninitialized value here */

printf("i=%d\n", i);
}

(ignoring the undefined behaviour for now) will print
out some unknown decimal value.

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.

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

Nov 14 '05 #31

RCollins

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?

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

Nov 14 '05 #32

Joe Wright

RCollins wrote:

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?

--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Nov 14 '05 #33

RCollins

Joe Wright wrote:

RCollins wrote:

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.

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

Nov 14 '05 #34

Joe Wright

Emmanuel Delahaye wrote:

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.

--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Nov 14 '05 #35

pete

RCollins wrote:

Joe Wright wrote:
RCollins wrote:

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.

--
pete

Nov 14 '05 #36

CBFalconer

pete wrote:

.... ******* 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.

--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"A man who is right every time is not likely to do very much."
- Francis Crick, co-discover of DNA

Nov 14 '05 #37

Rich Grise

pete wrote:

RCollins wrote:

Joe Wright wrote: .... 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.

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

Nov 14 '05 #38

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

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

"C is a sharp tool"

Nov 14 '05 #39

pete

Rich Grise wrote:

pete wrote:
RCollins wrote:

Joe Wright wrote: ... 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.

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.

--
pete

Nov 14 '05 #40

Rich Grise

pete wrote:

Rich Grise wrote:

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.

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

Nov 14 '05 #41

Rich Grise

pete wrote:

Rich Grise wrote:

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.

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

Nov 14 '05 #42

pete wrote:

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.

Nov 14 '05 #43

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

pete wrote:
There's nothing special about a structure being an object.
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.

--
Keith Thompson (The_Other_Keith) 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.

Nov 14 '05 #44

pete

Keith Thompson wrote:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
pete wrote:
There's nothing special about a structure being an object.

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".

Thank you.

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

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.

--
pete

Nov 14 '05 #45

CBFalconer

pete wrote:

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

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Nov 14 '05 #46

pete

Rich Grise wrote:

pete wrote:
Rich Grise wrote:

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.

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)

--
pete

Nov 14 '05 #47

Keith Thompson wrote:

E. Robert Tisdale writes:
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.

Nov 14 '05 #48

Keith Thompson wrote:

E. Robert Tisdale writes:
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.

'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?

Nov 14 '05 #49