difference

[Ramkumar R K]

what is the difference between objects and pointers?

[Hallvard B Furuseth]

Ramkumar R K wrote:

what is the difference between objects and pointers?

An object is 'a region of data storage in the execution environment, the
contents of which can represent values'. (Quoted from the standard.)
E.g. an integer, struct, malloced area, pointer, or whatever.
So 'int i;' declares an object (and names it 'i').

A pointer is an object which contains the address of another object (or
of a function). E.g. `int *p;'. If you set p = &i, you can access `i'
either through its name `i' or by following the pointer (with the `*'
operator): `*p'.

--
Hallvard

[Mike Wahler]

"Ramkumar R K" <ra********@indiatimes.com> wrote in message
news:74**************************@posting.google.c om...

what is the difference between objects and pointers?

A pointer *is* an object. The difference between objects
of pointer type and those of other types, is that pointer types
are used for storing addresses, and other types store other
types of data, e.g. 'int', 'float', a user defined type
(a class or struct), etc.

-Mike

[Richard Bos]

ra********@indiatimes.com (Ramkumar R K) wrote:

what is the difference between objects and pointers?

A pointer is an object, an object is not necessarily a pointer.
You can have pointer values, which are values of pointer objects, but it
makes little sense to talk of an object value (as opposed to <sometype>
value or simply value).
Pointers can point at pointers, but objects cannot object to objects.

Richard

[Richard Bos]

Hallvard B Furuseth <h.b.furuseth(nospam)@usit.uio(nospam).no> wrote:

A pointer is an object which contains the address of another object (or
of a function).

Or possibly of itself <g>.

Richard

[pete]

Richard Bos wrote:

Hallvard B Furuseth <h.b.furuseth(nospam)@usit.uio(nospam).no> wrote:

A pointer is an object which contains
the address of another object (or of a function).

Or possibly of itself <g>.

The result of the & operator, is a pointer, though not an object.

--
pete

[Richard Bos]

pete <pf*****@mindspring.com> wrote:

Richard Bos wrote:

Hallvard B Furuseth <h.b.furuseth(nospam)@usit.uio(nospam).no> wrote:

A pointer is an object which contains
the address of another object (or of a function).

Or possibly of itself <g>.

The result of the & operator, is a pointer, though not an object.

My hovercraft, OTOH, is full of eels - which is just as relevant.

Richard

[Richard Heathfield]

Mike Wahler wrote:

"Ramkumar R K" <ra********@indiatimes.com> wrote in message
news:74**************************@posting.google.c om...

what is the difference between objects and pointers?

A pointer *is* an object.

Not necessarily. In this code fragment:

int i;
int *p = &i;

&i is a pointer, but not an object.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Richard Heathfield]

Richard Bos wrote:

ra********@indiatimes.com (Ramkumar R K) wrote:

what is the difference between objects and pointers?

A pointer is an object,

Exceptions include the value yielded by the & "address-of" operator, and the
unadorned name of a function (which is converted to a pointer to the
address of that function, but AFAICT is not an object).

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Richard Bos]

Richard Heathfield <in*****@address.co.uk.invalid> wrote:

Mike Wahler wrote:

"Ramkumar R K" <ra********@indiatimes.com> wrote in message
news:74**************************@posting.google.c om...

what is the difference between objects and pointers?

A pointer *is* an object.

Not necessarily. In this code fragment:

int i;
int *p = &i;

&i is a pointer, but not an object.

AFAICT, &i is an expression with pointer type, evaluating to a pointer
value, but p is the only pointer.

Then again, it's a pain to search a document for the definition of
"pointer, but not pointer type or pointer value or object of pointer
type", but the C99 Standard _seems_ to use "pointer" both in contexts
where it must mean "a value of a pointer object" (conversion) and in
contexts where it must mean "an object of pointer type" (increment), so
if _they_ don't have to be consistent about it, I don't see why we
should.

Richard

[pete]

Richard Bos wrote:

pete <pf*****@mindspring.com> wrote:

Richard Bos wrote:

Hallvard B Furuseth <h.b.furuseth(nospam)@usit.uio(nospam).no> wrote:

> A pointer is an object which contains
> the address of another object (or of a function).

Or possibly of itself <g>.

The result of the & operator, is a pointer, though not an object.

My hovercraft, OTOH, is full of eels - which is just as relevant.

That the result of the & operator, is a pointer, and not an object,
is completely relevant to OP's question of
"what is the difference between objects and pointers?"
when OP is being told that pointers are objects.
A pointer isn't necessarily an object.
Pointer is a catagory of types, with each type of pointer
being a pointer to some other type.
All constants are of object type also, not just objects.

--
pete

[Hallvard B Furuseth]

pete wrote:

Richard Bos wrote:

Hallvard B Furuseth <h.b.furuseth(nospam)@usit.uio(nospam).no> wrote:

A pointer is an object which contains
the address of another object (or of a function).

Or possibly of itself <g>.

The result of the & operator, is a pointer, though not an object.

Are you sure? Where does the standard say this?

The program has to put the result somewhere - maybe in memory, maybe in
a register. That place isn't named by a variable or anything else, but
I don't see what that has to do with it. (Or the value could be
optimized away, of course, but so can other objects.)

--
Hallvard

[pete]

Hallvard B Furuseth wrote:

pete wrote:

Richard Bos wrote:

Hallvard B Furuseth <h.b.furuseth(nospam)@usit.uio(nospam).no> wrote:

A pointer is an object which contains
the address of another object (or of a function).

Or possibly of itself <g>.
The result of the & operator, is a pointer, though not an object.

Are you sure? Where does the standard say this?

The program has to put the result somewhere
- maybe in memory, maybe in a register.

The result does not imply storage according
to the representation of the type,
on the abstract machine, and that's why it's not an object.
That place isn't named by a variable or anything else, but
I don't see what that has to do with it.

--
pete

[Emmanuel Delahaye]

In 'comp.lang.c', Richard Heathfield <in*****@address.co.uk.invalid> wrote:

A pointer *is* an object.

Not necessarily. In this code fragment:

int i;
int *p = &i;

&i is a pointer, but not an object.

As I undersdand it, &i is a pointer constant (like NULL in a pointer
context, or the name of an array). It's not a object because it's a constant
value. Constant values have no address. Hence, the assertion "a pointer is an
object" sounds good to me. Please, let me know if I'm wrong.

--
-ed- em**********@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[Thomas Stegen]

Hallvard B Furuseth wrote:

pete wrote:

Richard Bos wrote:

Hallvard B Furuseth <h.b.furuseth(nospam)@usit.uio(nospam).no> wrote:
A pointer is an object which contains
the address of another object (or of a function).

Or possibly of itself <g>.

The result of the & operator, is a pointer, though not an object.

Are you sure? Where does the standard say this?

I think it falls down to the fact the standard does not say to
much explicitly, but rather on how it uses the term.

Me and Joe Wright had a discussion about this some time back.

If you want to see the arguments made then Message id of starting post
is: <bp**********@ctb-nnrp2.saix.net>

--
Thomas.

[CBFalconer]

Emmanuel Delahaye wrote:

Richard Heathfield <in*****@address.co.uk.invalid> wrote:

A pointer *is* an object.

Not necessarily. In this code fragment:

int i;
int *p = &i;

&i is a pointer, but not an object.

As I undersdand it, &i is a pointer constant (like NULL in a
pointer context, or the name of an array). It's not a object
because it's a constant value. Constant values have no address.
Hence, the assertion "a pointer is an object" sounds good to me.
Please, let me know if I'm wrong.

And, in the above context:

int *p = c & i;

is probably a silly error, due to the appalling overuse and
overloading of symbols in C in context sensitive manners. We
won't fix this now, but I just thought I would rant and rave a
bit. Wasn't it the Queen of Hearts who said "it means just what I
intend it to mean".

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

[Joe Wright]

Ramkumar R K wrote:

what is the difference between objects and pointers?

comp.lang.c is not a substitute for reading your C book.

what is the difference fruit and apples?
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Joe Wright]

Richard Heathfield wrote:

Richard Bos wrote:

ra********@indiatimes.com (Ramkumar R K) wrote:

what is the difference between objects and pointers?

A pointer is an object,

Exceptions include the value yielded by the & "address-of" operator, and the
unadorned name of a function (which is converted to a pointer to the
address of that function, but AFAICT is not an object).

Don't fight it so hard. "pointer to the address of" indeed. I contend
simply that we confuse "address" and "pointer" too often. An address is
a value with pointer type but it is a value, not an object. The value
yielded by the & operator is an address. Calling it a pointer is wrong.
Expressing the name of a function yields the address of it. Not a
pointer.

We all know that C is value oriented. We pass arguments to functions by
value. Functions return values to their callers. But we 'say' it wrong.
Because the value returned is of pointer type we call it 'pointer'
instead of value. Example..

int *p; /* p is a pointer to int */
p = malloc(N * sizeof *p);

The return from malloc() is a value of type (void*). The value is
assigned to p, the only pointer around.

I commend the reader to the first sentence of Chapter 5 of K&R 1 and 2.
"A pointer is a variable that contains the address of another variable."

What's so hard about this?
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Richard Heathfield]

Joe Wright wrote:

Richard Heathfield wrote:

Richard Bos wrote:

> ra********@indiatimes.com (Ramkumar R K) wrote:
>
>> what is the difference between objects and pointers?
>
> A pointer is an object,
Exceptions include the value yielded by the & "address-of" operator, and
the unadorned name of a function (which is converted to a pointer to the
address of that function, but AFAICT is not an object).

Don't fight it so hard. "pointer to the address of" indeed.

Sorry about that. I meant, of course, "a pointer to that function".
I contend
simply that we confuse "address" and "pointer" too often. An address is
a value with pointer type but it is a value, not an object. The value
yielded by the & operator is an address. Calling it a pointer is wrong.
I agree that the value is an address, but disagree that calling it a pointer
is wrong. The Standard says:

"The unary & operator returns the address of its operand. [...]
the result is a pointer to the object or function designated by its
operand."
Expressing the name of a function yields the address of it. Not a
pointer.

See above.

<snip>

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Arthur J. O'Dwyer]

On Mon, 26 Jan 2004, Joe Wright wrote:

Richard Heathfield wrote:

Richard Bos wrote:

A pointer is an object,
Exceptions include the value yielded by the & "address-of" operator,
and the unadorned name of a function (which is converted to a pointer
to the address of that function, but AFAICT is not an object).

Don't fight it so hard. "pointer to the address of" indeed.

We all have our terminological quirks. Indeed, I would contend that
Richard's use of "pointer to the address of" is silly -- a pointer,
to me, *is* an address (or, equivalently, the value of a pointer
object is an address). A pointer points to an object, not an address!
:-) Obviously, SMV [someone's mileage varies], or it could have been
a thinko.
I contend simply that we confuse "address" and "pointer" too often.
An address is a value with pointer type but it is a value, not an
object. The value yielded by the & operator is an address.
Agreed.
Calling it a pointer is wrong.
Disagreed. (Would you object to my calling 5 an 'int', even though
it's not an object? ...And that's not even getting into the debate
that hit c.s.c a year or so ago, when it seemed like maybe 5 *was*
an object, just not an lvalue... I don't remember the details.)
Expressing the name of a function yields the address of it. Not a
pointer.
Just as many people call the value 5 an int, many people will
continue to call &foo a pointer no matter how consistent it might
be to go the other way. :)
We all know that C is value oriented. We pass arguments to functions by
value. Functions return values to their callers. But we 'say' it wrong.
Because the value returned is of pointer type we call it 'pointer'
instead of value.
Exactly.
I commend the reader to the first sentence of Chapter 5 of K&R 1 and 2.
"A pointer is a variable that contains the address of another variable."

What's so hard about this?

I'm actually pleasantly surprised that K&R1 Ch5 manages to keep
the concepts of 'pointer object' and 'address value' separate as much
as they do. Way to go, K&R! But I don't like how they appropriated
the word "pointer" to describe those pointer objects, because, as you've
observed above, we *do* use the word "pointer" to refer to values of
pointer type.

Bottom line: Avoid arguing over the semantics of "pointer." Stick
to "object" and "value" in pedantic contexts, because they have almost
unambiguous meanings in C.

-Arthur

[Jack Klein]

On 26 Jan 2004 21:05:45 GMT, Emmanuel Delahaye <em**********@noos.fr>
wrote in comp.lang.c:

In 'comp.lang.c', Richard Heathfield <in*****@address.co.uk.invalid> wrote:

A pointer *is* an object.

Not necessarily. In this code fragment:

int i;
int *p = &i;

&i is a pointer, but not an object.

As I undersdand it, &i is a pointer constant (like NULL in a pointer
context, or the name of an array). It's not a object because it's a constant
value. Constant values have no address. Hence, the assertion "a pointer is an
object" sounds good to me. Please, let me know if I'm wrong.

OK, you're wrong. There are pointer rvalues, too, even though the
latest standard does not mention "rvalue" except in a footnote
explaining that the standard uses the term "value of an expression" in
its place.

Consider:

void my_func(char *cp)
{
char *ccp = cp + 1;
}

The expression "cp + 1" produces a value (what used to be called an
rvalue), that is then assigned to the object ccp. The expression
itself, or rather the value it computes, is not an object.

Of course this example is not particularly common, so consider another
one for limiting a loop to the items in an array:

int max_val(int *ip, int how_many)
{
int guess = INT_MIN;
int *p;;

for (p = ip; p < ip + how_many; ++ip)
{
if (*p > guess)
guess = *p;
}
}

There is no object associated with the expression "ip + how_many". It
provides a pure value.

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

[Jack Klein]

On Mon, 26 Jan 2004 23:55:50 GMT, Joe Wright
<jo********@earthlink.net> wrote in comp.lang.c:

Richard Heathfield wrote:

Richard Bos wrote:

ra********@indiatimes.com (Ramkumar R K) wrote:

> what is the difference between objects and pointers?

A pointer is an object,

Exceptions include the value yielded by the & "address-of" operator, and the
unadorned name of a function (which is converted to a pointer to the
address of that function, but AFAICT is not an object).

Don't fight it so hard. "pointer to the address of" indeed. I contend
simply that we confuse "address" and "pointer" too often. An address is
a value with pointer type but it is a value, not an object. The value
yielded by the & operator is an address. Calling it a pointer is wrong.
Expressing the name of a function yields the address of it. Not a
pointer.

Address is not a C type. If it were a C type, it would be a distinct
type from pointer. Either "address of int" and "pointer to int" are
the same type, meaning they only need one name, or they are different
and therefore incompatible types.

The latter leads to the necessity to write code like this:

int i;
int *ip = (int *)&i; /* &i does not have type "pointer to int" */

const char *fred = (const char *)"fred";

It would be better for the standard to omit the term "address" from
the language. It is an unnecessary low-level term.

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

[pete]

Arthur J. O'Dwyer wrote:

On Mon, 26 Jan 2004, Joe Wright wrote:

The value yielded by the & operator is an address.

Agreed.

Calling it a pointer is wrong.
Disagreed. (Would you object to my calling 5 an 'int',

I would call 5 an int, 5.0f a float, and 5.0 a double.
even though
it's not an object? ...And that's not even getting into the debate
that hit c.s.c a year or so ago, when it seemed like maybe 5 *was*
an object, just not an lvalue... I don't remember the details.)

In C99, an expression with object type is an lvalue,
except that the C99 standard can't possibley mean
what it says there. All constants have object type.

N869
6.3.2.1 Lvalues and function designators
[#1] An lvalue is an expression with an object type or an
incomplete type other than void; if an lvalue does not
designate an object when it is evaluated, the behavior is
undefined.

Therefore, the evaluation of any integer constant,
yields undefined behavior, in C99,
except that the standard can't possibley mean what it says there.

--
pete

[Hallvard B Furuseth]

pete wrote:

N869
6.3.2.1 Lvalues and function designators
[#1] An lvalue is an expression with an object type or an
incomplete type other than void; if an lvalue does not
designate an object when it is evaluated, the behavior is
undefined.

Therefore, the evaluation of any integer constant,
yields undefined behavior, in C99,
except that the standard can't possibley mean what it says there.

....unless it means that constants are objects.

--
Hallvard

[pete]

Hallvard B Furuseth wrote:

pete wrote:

N869
6.3.2.1 Lvalues and function designators
[#1] An lvalue is an expression with an object type or an
incomplete type other than void; if an lvalue does not
designate an object when it is evaluated, the behavior is
undefined.

Therefore, the evaluation of any integer constant,
yields undefined behavior, in C99,
except that the standard can't possibley mean what it says there.

...unless it means that constants are objects.

ITYM ...unless it means that constants are objects and lvalues.

Do you think that consants are lvalues ?

--
pete

[August Derleth]

CBFalconer wrote:

Emmanuel Delahaye wrote:

Richard Heathfield <in*****@address.co.uk.invalid> wrote:

A pointer *is* an object.

Not necessarily. In this code fragment:

int i;
int *p = &i;

&i is a pointer, but not an object.

As I undersdand it, &i is a pointer constant (like NULL in a
pointer context, or the name of an array). It's not a object
because it's a constant value. Constant values have no address.
Hence, the assertion "a pointer is an object" sounds good to me.
Please, let me know if I'm wrong.

And, in the above context:

int *p = c & i;

is probably a silly error, due to the appalling overuse and
overloading of symbols in C in context sensitive manners. We
won't fix this now, but I just thought I would rant and rave a
bit. Wasn't it the Queen of Hearts who said "it means just what I
intend it to mean".

Humpty-Dumpty, but I don't see how parsing that expression could be a
problem. Here's how my mind sees it, in pseudo-assembly:
load r0, [c]
and r0, [i]
store r0, [p]
Is that at variance with the definition of & in this context? I mean, it
probably isn't a highly intelligent use of the bitwise-and, but it parses.

--
My address is yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
Note: Rot13 and convert spelled-out numbers to numerical equivalents.

[Irrwahn Grausewitz]

pete <pf*****@mindspring.com> wrote:

Arthur J. O'Dwyer wrote:

On Mon, 26 Jan 2004, Joe Wright wrote:

>
> The value yielded by the & operator is an address.

Agreed.

> Calling it a pointer is wrong.

Disagreed. (Would you object to my calling 5 an 'int',

I would call 5 an int, 5.0f a float, and 5.0 a double.

In clc-pedantic-mode I would call 5 an integer constant, etc.
;^)

even though
it's not an object? ...And that's not even getting into the debate
that hit c.s.c a year or so ago, when it seemed like maybe 5 *was*
an object, just not an lvalue... I don't remember the details.)
In C99, an expression with object type is an lvalue,
except that the C99 standard can't possibley mean
what it says there.

I suspect you somehow reversed the logic, see below...
All constants have object type.

N869
6.3.2.1 Lvalues and function designators
[#1] An lvalue is an expression with an object type or an
incomplete type other than void; if an lvalue does not
designate an object when it is evaluated, the behavior is
undefined.

Therefore, the evaluation of any integer constant,
- when used as an lvalue -
yields undefined behavior, in C99,
which makes sense, since a constant doesn't designate an object
(you cannot take its address).
except that the standard can't possibley mean what it says there.

Why not? I read 6.3.2.1#1 like:

An lvalue *has* to be an expression with an object type(...),
*but* only those expressions with object type(...), that
designate objects, are valid lvalues.

Consider footnote 53 in ISO/IEC 9899:1999:
<quote>
The name "lvalue" comes originally from the assignment
expression E1 = E2, in which the left operand E1 is required
to be a (modifiable) lvalue. It is perhaps better considered
as representing an object "locator value". What is
^^^^^^^^^^^^^^^^^^^^^^
sometimes called "rvalue" is in this International Standard
described as the "value of an expression".
</quote>

Since constants do not designate/locate objects, they should not
be used as lvalues, unless you're in need of nasal demons... :)

However, that doesn't affect the behaviour when an integer
constant is used as rvalue (its value is used).

Anybody, please correct me, if I'm mistaken.

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[pete]

Irrwahn Grausewitz wrote:

pete <pf*****@mindspring.com> wrote:

Arthur J. O'Dwyer wrote:

On Mon, 26 Jan 2004, Joe Wright wrote:
>
> The value yielded by the & operator is an address.

Agreed.

> Calling it a pointer is wrong.

Disagreed. (Would you object to my calling 5 an 'int',

I would call 5 an int, 5.0f a float, and 5.0 a double.

In clc-pedantic-mode I would call 5 an integer constant, etc.
;^)

Does that etc. lead to two different terms
whic distinguish 5.0f from 5.0 ?

even though
it's not an object? ...And that's not even getting into the debate
that hit c.s.c a year or so ago, when it seemed like maybe 5 *was*
an object, just not an lvalue... I don't remember the details.)

In C99, an expression with object type is an lvalue,
except that the C99 standard can't possibley mean
what it says there.

I suspect you somehow reversed the logic, see below...

All constants have object type.

N869
6.3.2.1 Lvalues and function designators
[#1] An lvalue is an expression with an object type or an
incomplete type other than void; if an lvalue does not
designate an object when it is evaluated, the behavior is
undefined.

Therefore, the evaluation of any integer constant,

- when used as an lvalue -

The standard says what an lvalue is.
and what happens when it is evaluted.
The standard doesn't say anything about usage
affecting what happens when an lvalue is evaluated.

yields undefined behavior, in C99,

which makes sense, since a constant doesn't designate an object
(you cannot take its address).

except that the standard can't possibley mean what it says there.

Why not? I read 6.3.2.1#1 like:

An lvalue *has* to be an expression with an object type(...),
*but* only those expressions with object type(...), that
designate objects, are valid lvalues.

Consider footnote 53 in ISO/IEC 9899:1999:
<quote>
The name "lvalue" comes originally from the assignment
expression E1 = E2, in which the left operand E1 is required
to be a (modifiable) lvalue. It is perhaps better considered
as representing an object "locator value". What is
^^^^^^^^^^^^^^^^^^^^^^
sometimes called "rvalue" is in this International Standard
described as the "value of an expression".
</quote>

Since constants do not designate/locate objects, they should not
be used as lvalues, unless you're in need of nasal demons... :)

I agree with your advice, but the standard doesn't say that.

--
pete

[Irrwahn Grausewitz]

pete <pf*****@mindspring.com> wrote:

Irrwahn Grausewitz wrote:

pete <pf*****@mindspring.com> wrote: <snip>

>I would call 5 an int, 5.0f a float, and 5.0 a double.
In clc-pedantic-mode I would call 5 an integer constant, etc.
;^)

Does that etc. lead to two different terms
whic distinguish 5.0f from 5.0 ?

Hmm, since the standard refers to any numerical floating point
constant as, ...err... "floating constant", one could use the
following:

single precision floating constant ( 5.0f )
double precision floating constant ( 5.0 )
long double precision floating constant ( 5.0l )

Still, only when being pedantic, of course... :)

<snip>

I suspect you somehow reversed the logic, see below... And somehow I still do.

>N869
> 6.3.2.1 Lvalues and function designators
> [#1] An lvalue is an expression with an object type or an
> incomplete type other than void; if an lvalue does not
> designate an object when it is evaluated, the behavior is
> undefined.
>
>Therefore, the evaluation of any integer constant,

- when used as an lvalue -

The standard says what an lvalue is.

Agreed.
and what happens when it is evaluted. Agreed.
The standard doesn't say anything about usage
affecting what happens when an lvalue is evaluated.

I happen to disagree, see below.

>yields undefined behavior, in C99,

<snip> Since constants do not designate/locate objects, they should not
be used as lvalues, unless you're in need of nasal demons... :)

I agree with your advice, but the standard doesn't say that.

Huh?!? But in 6.3.2.1 the standard /explicitly/ states that
evaluating lvalues that do not designate objects (integer
constants being one example) invokes UB, which is Standardese
for: "Don't do it!"

That however does not affect the behaviour when evaluating the
same expression in a (r)value context [1], which is of course
well defined elsewhere in the standard.

6.3.2.1 defines which "thingies" qualify as candidates for valid
lvalues, not that these "thingies" are always lvalues. Otherwise
the paragraph would start like: "Expressions with object type
(...) are lvalues (...)" - which in turn would lead to the wrong
conclusion that evaluating an integer constant would invoke
undefined behaviour under all circumstances. - Since it doesn't,
it doesn't... ;)

"Thingies" like 5 aren't lvalues in and of itself. They may
appear in lvalue (object) context, but in this case won't do
any good, as we happen to agree.
Consider:

int i;
int p;
int a[5], b[5];

i = 5; /* fine; i is a valid lvalue and 5 a valid rvalue */
ip = &5; /* invalid; 5 is an lvalue here, but you cannot compute
its address: it's an lvalue that doesn't designate
an object and is therefore unsuitable as an operand
to the unary & operator. [2] */
5 = 6; /* invalid; 5 is an lvalue that doesn't designate
an object and is therefore unsuitable as left
operand of an assignment operator [3], whereas 6 is
a valid rvalue. */
ip = &i; /* fine; ip and i are suitable lvalues */
a = b; /* invalid; a is an lvalue designating an object,
but it is not modifiable [3] */
[1] As opposed to object (lvalue) context.

[2] See C99 6.5.3.2#1
<OT> gcc emits "error: invalid lvalue in unary '&'" </OT>

[3] See C99 6.5.16
<OT> gcc emits "error: invalid lvalue in assignment" </OT>

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Dan Pop]

In <0m********************************@4ax.com> Irrwahn Grausewitz <ir*******@freenet.de> writes:

pete <pf*****@mindspring.com> wrote:

Irrwahn Grausewitz wrote:

pete <pf*****@mindspring.com> wrote:<snip> >I would call 5 an int, 5.0f a float, and 5.0 a double.

In clc-pedantic-mode I would call 5 an integer constant, etc.
;^)

Does that etc. lead to two different terms
whic distinguish 5.0f from 5.0 ?

Hmm, since the standard refers to any numerical floating point
constant as, ...err... "floating constant", one could use the
following:

single precision floating constant ( 5.0f )
double precision floating constant ( 5.0 )
long double precision floating constant ( 5.0l )

Still, only when being pedantic, of course... :)

Otherwise, we can use their informal names: float constant, double
constant, long double constant.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[pete]

Irrwahn Grausewitz wrote:

pete <pf*****@mindspring.com> wrote:

Irrwahn Grausewitz wrote:

pete <pf*****@mindspring.com> wrote: <snip> >I would call 5 an int, 5.0f a float, and 5.0 a double.

In clc-pedantic-mode I would call 5 an integer constant, etc.
;^)

Does that etc. lead to two different terms
whic distinguish 5.0f from 5.0 ?

Hmm, since the standard refers to any numerical floating point
constant as, ...err... "floating constant", one could use the
following:

single precision floating constant ( 5.0f )
double precision floating constant ( 5.0 )
long double precision floating constant ( 5.0l )

What int, float and double really are, are types.
Types apply to objects and constants.

--
pete

[Hallvard B Furuseth]

pete wrote:

Hallvard B Furuseth wrote:

pete wrote:

N869
6.3.2.1 Lvalues and function designators
[#1] An lvalue is an expression with an object type or an
incomplete type other than void; if an lvalue does not
designate an object when it is evaluated, the behavior is
undefined.

Therefore, the evaluation of any integer constant,
yields undefined behavior, in C99,
except that the standard can't possibley mean what it says there.

...unless it means that constants are objects.

ITYM ...unless it means that constants are objects and lvalues.

Do you think that consants are lvalues ?

Oh. Yes. A constant is an expression, at least once you put it in a
program, and it has object type. So it fits the above description.

Everything seems to be lvalues in standard C. I don't know what the
term 'lvalue' is good for anymore.

--
Hallvard

[Hallvard B Furuseth]

Irrwahn Grausewitz wrote:

But in 6.3.2.1 the standard /explicitly/ states that
evaluating lvalues that do not designate objects (integer
constants being one example) invokes UB, which is Standardese
for: "Don't do it!"

I think integer constants are objects, and that what this text refers
to is lvalues like *p where p points to freed memory. That freed
memory is no longer an object.

--
Hallvard

[Hallvard B Furuseth]

Thomas Stegen wrote:

Hallvard B Furuseth wrote:

pete wrote:

The result of the & operator, is a pointer, though not an object.

Are you sure? Where does the standard say this?

I think it falls down to the fact the standard does not say to
much explicitly, but rather on how it uses the term.

Me and Joe Wright had a discussion about this some time back.

If you want to see the arguments made then Message id of starting post
is: <bp**********@ctb-nnrp2.saix.net>

Thanks.

I'm wondering about one thing: Why single out pointers, and the `&'
operator? Do you also think that the result of expressions like `a + b'
are not objects, or is there something special about &?

--
Hallvard

[pete]

Hallvard B Furuseth wrote:

Everything seems to be lvalues in standard C. I don't know what the
term 'lvalue' is good for anymore.

My understanding of lvalues and objects is from C89.
If you want to talk C99,
then I just don't know about those things anymore.

--
pete

[Peter Pichler]

"Hallvard B Furuseth" <h.b.furuseth(nospam)@usit.uio(nospam).no> wrote in
message news:HB**************@bombur.uio.no...

I'm wondering about one thing: Why single out pointers, and the `&'
operator? Do you also think that the result of expressions like `a + b'
are not objects, or is there something special about &?

The thread started with a question about a difference between objects and
pointers and drifted off into a discussion whether all pointers are objets
or not.

[Joe Wright]

Hallvard B Furuseth wrote:

[ snip ]
I think integer constants are objects, and that what this text refers
to is lvalues like *p where p points to freed memory. That freed
memory is no longer an object.

From K&R2 A4 p195
"An object, sometimes called a variable, is a location in storage, and
its interpretation depends on two main attributes: its 'storage class'
and its 'type'."..

That doesn't sound like a constant to me. I must have missed something
important earlier. Give me an example of an integer constant that you
think is an object. Please.
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Joe Wright]

Hallvard B Furuseth wrote:

Thomas Stegen wrote:

Hallvard B Furuseth wrote:

pete wrote:

The result of the & operator, is a pointer, though not an object.

Are you sure? Where does the standard say this?

I think it falls down to the fact the standard does not say to
much explicitly, but rather on how it uses the term.

Me and Joe Wright had a discussion about this some time back.

If you want to see the arguments made then Message id of starting post
is: <bp**********@ctb-nnrp2.saix.net>

Thanks.

I'm wondering about one thing: Why single out pointers, and the `&'
operator? Do you also think that the result of expressions like `a + b'
are not objects, or is there something special about &?

Assuming..

int a = 4;
int b = 5;
int c;

c = a + b;

The variables a, b and c are objects. The value of a is 4. The value of
b is 5. The value of a + b is 9. But 9 is not an object, c is.

--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[E. Robert Tisdale]

Joe Wright wrote:

int a = 4;
int b = 5;
int c;
It is a bad idea to leave a variable undefined.
c = a + b;

It would be better to write:

int a = 4;
int b = 5
int c = a + b;

Or better yet:

const int a = 4; // description of a
const int b = 5; // description of b
const int c = a + b; // description of c

since there is no indication that you need variables
in this context.

[Joe Wright]

E. Robert Tisdale wrote:

Joe Wright wrote:

int a = 4;
int b = 5;
int c;

It is a bad idea to leave a variable undefined.

c = a + b;

It would be better to write:

int a = 4;
int b = 5
int c = a + b;

Or better yet:

const int a = 4; // description of a
const int b = 5; // description of b
const int c = a + b; // description of c

since there is no indication that you need variables
in this context.

Hi Bob. Thanks for joining. I can't tell you how much I appreciate your
critique. Really, I can't. You don't know what you're talking about and
you don't know what I'm talking about. Is a + b an object?
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[pete]

Joe Wright wrote:

c = a + b;

Is a + b an object?

Suppose that a and b are long and larger than int.
It's possible that the value of a + b might computed in parts,
and the representation, constructed in place, in c.
There is just no implication in the code,
that any long type representation of (a + b) ever exists in
memory prior to being in c.
The entire meaning of the statement, is that after the assignment,
c will have the value of (a + b). It doesn't mean anything else.

--
pete

[E. Robert Tisdale]

pete wrote:

Joe Wright wrote:

c = a + b;

Is a + b an object?

Yes.
Suppose that a and b are long and larger than int.
It's possible that the value of a + b might computed in parts,
and the representation, constructed in place, in c.
There is just no implication in the code,
that any long type representation of (a + b) ever exists
in memory prior to being in c.
The entire meaning of the statement is that,
after the assignment,
c will have the value of (a + b).
It doesn't mean anything else.

Consider

int f(void) {
int a = 4;
int b = 5;
int c = a + b;
int d = 6;
int e = c + d;
return e;
}

Does object c actually exist
if your C compiler optimizes away storage for c and evaluates

int e = a + b + d;

directly? Of course it does.

[Martin Dickopp]

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

Consider

int f(void) {
int a = 4;
int b = 5;
int c = a + b;
int d = 6;
int e = c + d;
return e;
}

Does object c actually exist
if your C compiler optimizes away storage for c and evaluates

int e = a + b + d;

directly? Of course it does.

It certainly does in the abstract machine.

Martin

[Irrwahn Grausewitz]

Hallvard B Furuseth <h.b.furuseth(nospam)@usit.uio(nospam).no>
wrote:

Irrwahn Grausewitz wrote:

But in 6.3.2.1 the standard /explicitly/ states that
evaluating lvalues that do not designate objects (integer
constants being one example) invokes UB, which is Standardese
for: "Don't do it!"
I think integer constants are objects,

I don't have enough hard evidence in either direction to answer
the question if integer constants /are/ objects. But: even /if/
they are objects, you can only access the values, but you cannot
locate the objects in memory: an integer constant does not
/designate/ an object. Thus, while integer constants may well
qualify as lvalues (since they are "expressions with object type
[...] other than void"), any attempt to access an object through
them is (at least) a constraint violation or invokes undefined
behaviour (see the references in my previous post).
and that what this text refers
to is lvalues like *p where p points to freed memory. That freed
memory is no longer an object.

If p is a dangling pointer, the behaviour of the unary *
operator is undefined in the first place: you won't make it
to the point in time where it matters if the result of evaluating
the expression *p is a valid lvalue at all: the evaluation itself
is undefined. While the case would of course be covered by C99
6.3.2.1, it is explicitly addressed in C99 6.5.3.2#4 anyway.

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[pete]

E. Robert Tisdale wrote:

pete wrote:

Joe Wright wrote:

> c = a + b;

Is a + b an object?

There is just no implication in the code,
that any long type representation of (a + b) ever exists
in memory prior to being in c.
The entire meaning of the statement is that,
after the assignment,
c will have the value of (a + b).
It doesn't mean anything else.

optimizes

I wasn't talking about optimization.
I was talking about the semantics of
the code on the abstract machine.

--
pete

[Hallvard B Furuseth]

Joe Wright wrote:

Hallvard B Furuseth wrote:

I think integer constants are objects, and that what this text refers
to is lvalues like *p where p points to freed memory. That freed
memory is no longer an object.
From K&R2 A4 p195
"An object, sometimes called a variable, is a location in storage, and
its interpretation depends on two main attributes: its 'storage class'
and its 'type'."..

That doesn't sound like a constant to me. I must have missed something
important earlier.

What you missed is that C is defined by the C standard, not by K&R2.
The sentence you quoted illustrates why: It is wrong. It says that all
objects are variables. So malloced memory, which is not a variable, is
not an object.
Give me an example of an integer constant that you
think is an object. Please.

1

--
Hallvard

[Hallvard B Furuseth]

pete wrote:

Hallvard B Furuseth wrote:

Everything seems to be lvalues in standard C. I don't know what the
term 'lvalue' is good for anymore.

My understanding of lvalues and objects is from C89.
If you want to talk C99,
then I just don't know about those things anymore.

I meant the statement you quoted from C89.

--
Hallvard

[pete]

Hallvard B Furuseth wrote:

pete wrote:

Hallvard B Furuseth wrote:

Everything seems to be lvalues in standard C.
I don't know what the term 'lvalue' is good for anymore.

My understanding of lvalues and objects is from C89.
If you want to talk C99,
then I just don't know about those things anymore.

I meant the statement you quoted from C89.

I haven't quoted C89 yet.

C89 last public draft:
3.2.2.1 Lvalues and function designators
An lvalue is an expression (with an object type or an incomplete
type other than void) that designates an object.

In C99, when they say
"if an lvalue does not designate an object when it is evaluated,
the behavior is undefined."
.... they're talking about something like
char *pointer = NULL;
*pointer;

They felt that was more complete than what C89 said.

--
pete

[E. Robert Tisdale]

Joe Wright wrote:

Hallvard B Furuseth wrote:

[ snip ]

I think integer constants are objects,
and that what this text refers to
is lvalues like *p where p points to freed memory.
That freed memory is no longer an object.

From K&R2 A4 p195
"An object, sometimes called a variable, is a location in storage,
and its interpretation depends on two main attributes:
its 'storage class' and its 'type'."..

That doesn't sound like a constant to me.
I must have missed something important earlier.
Give me an example of an integer constant that you think is an object.

For the definition of the term object,
you should consult an English language dictionary:

http://www.bartleby.com/61/

Brian W. Kernighan and Dennis M. Ritchie weren't trying
to define an object in the "object oriented" sense.
That is still an *unfinished* task which you should ask about
in the comp.object newsgroup if you are interested.

I think that it is safe to assume that Kernighan and Ritchie
meant both constants and variables here --
constants must be *initialized* after all.

What is clear from the K&R definition is that
objects are *data* objects
in the context of the C programming language.
They occupy (or, at least, could occupy)
some sort of memory storage -- registers, virtual memory, etc.
They were not talking about so-called real world objects.

Whether data objects exist or not may be irrelevant
if there is no way to reference them in the current scope.

[Richard Heathfield]

E. Robert Tisdale wrote:

For the definition of the term object,
you should consult an English language dictionary:

Not in comp.lang.c, you don't.

The ISO C Standard defines the term for the purposes of C; where the C
language is the subject of discussion, this local definition overrides any
wider definition.

(I don't expect Tisdale to understand this, given his track record.)

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton