difference

[Ramkumar R K]

what is the difference between objects and pointers?

[Jack Klein]

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

In 'comp.lang.c', Richard Heathfield <in*****@addres s.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.l earn.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********@ear thlink.net> wrote in comp.lang.c:

Richard Heathfield wrote:

Richard Bos wrote:

ra********@indi atimes.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.l earn.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*****@addres s.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*****@mindsp ring.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*******@free net.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*****@mindsp ring.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*****@mindsp ring.com> wrote:

Irrwahn Grausewitz wrote:

pete <pf*****@mindsp ring.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: "Expression s 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*******@free net.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*******@free net.de> writes:

pete <pf*****@mindsp ring.com> wrote:

Irrwahn Grausewitz wrote:

pete <pf*****@mindsp ring.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