Why do so few people know the difference between arrays and pointers.

[Me]

Just a question/observation out of frustration.

I read in depth the book by Peter Van Der Linden entitled
"Expert C Programming" (Deep C Secrets). In particular the
chapters entitled:
4: The Shocking Truth: C Arrays and Pointers Are NOT the Same!
9: More about Arrays
10: More about Pointers

What blows me out of the water is the fact that 'every' programmer
comming out of college that I've interviewed thinks that pointers
and arrays are the same thing.

They go so far as to tell me that, in the following code, 'arr' is
a pointer to an array of integers. Or they tell me that 'arr' is a
pointer to an 'int'. When this is not the case at all.

int arr[100];

The variable 'arr' IS and array of 100 integers...THATS ITS TYPE MAN.
Just like the TYPE of 'i' in the following is 'int'.

int i;

and the type of 'ch' in the following is 'char *'.

char *ch = "string";

The TYPE of 'arr' above is 'an array of 100 integers'. That's WHY you
have to declare a pointer to it as follows:

int (*p)[100];

p = &arr; // Valid
p = arr; // Invalid (compiler will warn you) but works because the
address happens to be the same.

Note: When you use an array in an expression or as an R-Value, the result
of the
operation yields a pointer to the first element in the array. Thus:

int *ip = arr; // Valid: arr turns into an int pointer (a pointer to the
first element in the array)
// Not because ip is an 'int *' be because the array 'arr' is being
used in an expression
// as an R-Value.

Man the C teachers in college aren't doing their job!

--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

[Keith Thompson]

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

Arthur J. O'Dwyer wrote:

On Thu, 10 Jun 2004, E. Robert Tisdale wrote:

Mike Wahler wrote:

IOW objects represent values, but not all values are objects.

Can you give us an example of a value that is *not* an object?

(int)42.

Wrong.

That's an object of type int with the [constant] value of 42.

C99 3.14 defines the word "object" as "region of data storage in the
execution environment, the contents of which can represent values".

There is no "region of data storage" necessarily associated with the
expression (int)42. It's an expression, and it has a value, but it's
not an object.

Evaluation of the expression may or may not involve an int-size region
of storage containing the value 42; that's an implementation detail,
irrelevant to C's definition of "object".

If that doesn't convince you, how about this:
int x = 41;
x + 1;

x + 1 is an expression whose value is 42. There is no object with
that value.

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

[E. Robert Tisdale]

Joe Laughlin wrote:

At the university I recently graduated from,
the professors didn't "teach" languages.
You don't need professors to teach programming languages.
You can get a lecturer, maybe a graduate student, to do that.
You don't need to teach programming languages
to computer science students.
Computer science students are usually smart enough
to pick up programming languages on their own as needed.
When computer programming languages are offered at a University
to computer science students they are considered "remedial".
They used languages to show various CS concepts.
Primarily, it was done in C++,
although the networking and OS classes used C.
I think this is rather typical.

Also, there seems to be a shift towards software engineering
and away from general computer science. Dunno if this is good or not.
I don't think so. Software Engineering is a field in Computer Science.
What you are witnessing is not a shift away from computer science
but rapid relative growth in a field of computer science
that has long been neglected and is exploding now only because
there are finally computers fast enough with enough memory and storage
that it is practical to design and implement
*very* large software packages.
As a recent graduate (this last week), I just started a new job,
and I've found out that I'm pretty rusty on pointers,
bit-shifting/byte-packing techniques, big/little-endians, etc.
However, I feel that I'm pretty good at software design,
object-oriented programming, project management, etc.

Unfortunately, programming has almost nothing to do
with software engineering as you well know.
A software engineer is *not* just a glorified computer programmer.

[Stephen Sprunk]

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

Joe Laughlin wrote:

At the university I recently graduated from,
the professors didn't "teach" languages.

You don't need professors to teach programming languages.
You can get a lecturer, maybe a graduate student, to do that.
You don't need to teach programming languages
to computer science students.
Computer science students are usually smart enough
to pick up programming languages on their own as needed.
When computer programming languages are offered at a University
to computer science students they are considered "remedial".

Unfortunately many educational institutions disagree. I dropped my CS major
because of this, actually; the entire undergrad program was dedicated to
teaching me things I already knew or could have picked up on my own, and all
the classes I wanted to take to learn REAL computer science were
post-graduate level.

Also, there seems to be a shift towards software engineering
and away from general computer science. Dunno if this is good or not.

I don't think so. Software Engineering is a field in Computer Science.

I've always considered "sciences" to be about building on existing ideas to
create and validate (or invalidate) new ideas, whereas "engineering" is more
an application of existing ideas to real-world problems. In programming
this is a bit blurred, but one can surely see the distinction between trying
to find new compiler optimizations vs. coding some commercial database app.

As a recent graduate (this last week), I just started a new job,
and I've found out that I'm pretty rusty on pointers,
bit-shifting/byte-packing techniques, big/little-endians, etc.
However, I feel that I'm pretty good at software design,
object-oriented programming, project management, etc.

Unfortunately, programming has almost nothing to do
with software engineering as you well know.
A software engineer is *not* just a glorified computer programmer.

I'd say that software design requires a very different skillset than
software implementation, but both are aspects of software engineering.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

[E. Robert Tisdale]

Keith Thompson wrote:

C99 3.14 defines the word "object"
as "region of data storage in the execution environment,
the contents of which can represent values".

There is no "region of data storage"
necessarily associated with the expression (int)42.
Where is it written that a "region of data storage"
must *necessarily* be associated with the expression (int)42?
It's an expression, and it has a value, but it's not an object.

Evaluation of the expression may or may not involve
an int-size region of storage containing the value 42;
that's an implementation detail,
irrelevant to C's definition of "object".
Are we to infer that
the existence of an object depends upon the implementation?
If that doesn't convince you, how about this:

int x = 41;
x + 1;

x + 1 is an expression whose value is 42.
There is no object with that value.

You are wrong.

If x is a static variable,
it could be initialized with the value 41 by the compiler
but, is x is an automatic variable,
the code emitted by the compiler will need to get the value 41
from some storage somewhere to initialize x.
According to you, then 41 would be an object.
Unless your compiler optimizes away the "x + 1" expression
(perhaps because it is not used),
a temporary object will be allocated (in a register perhaps)
to store the value of x + 1.
Consider, for example,

int x = 41;
int y = x + 1;
int z = 3*y;
// no further references to y

A good optimizing compiler will elide the storage for y
and compute

int z = 3*(x + 1);

directly.

In C, an object is something *could* occupy storage.
Whether it actually does occupy storage or not
may be left up to the optimizer.

[CBFalconer]

"E. Robert Tisdale" wrote:

Mike Wahler wrote:

IOW objects represent values, but not all values are objects.

Can you give us an example of a value that is *not* an object?

You can easily see an object that is not of value. Use a mirror.

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

[Chris Torek]

In article <news:2i************@uni-berlin.de>
Alex Monjushko <mo*******@hotmail.com> writes:

int a = 12;

The identifier 'a' is an object of type int, with the value of 12.
The integer literal 12 has the value of 12 but is not an object.

More precisely, the identifier is the name of (or "a label for")
an object of type int. The object itself is the "region of storage":

3.15 Object

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

(from a C99 draft).

No constant is an object, and no object is ever a constant, in C
(here C differs markedly from C++, where "const" variables *are*
constants, yet can be C-style objects). Note that I use the
ANSI C definition of the term "constant" here:

constant:
floating-constant
integer-constant
enumeration-constant
character-constant

(same C99 draft, but uchanged from C89). These differ from a
"constant-expression"; for instance, while (1+2) is a
"constant-expression", it is not a "constant".

String literals (except when used as initializers for character
arrays) are a special case: they create objects that have static
duration. The address of *any* static-duration object -- not just
those from string literals -- has a "constant address", which can
be computed at compile and/or link time in most cases, but this
does not make it a "constant", or even a "constant-expression",
in C. You *can* use them as initializers for other static-duration
variables though:

static char *p = "string literal";

or:

static double pi = 2.718281828459045235360287; /* [%] */
static double *dp = &pi;

[% A rather precise pi, but not very accurate. :-) ]

Hence, the concept of "constant" in C is somewhat peculiar and
subtle.

In C89, with one kind-of-broken exception, arrays are never values,
only objects. C99 attemps to correct the problem, which occurs
with struct-valued functions in which the struct contains (or
even consists of) an array:

struct S { int a[20]; };
struct S f(void);
...
... f().a ...

Here f().a appears as a sub-expression, yet because it part of a
returned struct, the array "a" is not an object with automatic,
static, or allocated duration. In effect, it is an array value,
instead of an array object. The problem is that you cannot take
the address of a value in C:

int *p = &42; /* invalid -- diagnostic required */

Array subscripting works, at least conceptually, by taking the
address of the array's first element, so f().a[i] needs to "take
the address" of f().a -- an address that does not exist. C99's
solution to this problem in C89 wound up re-defining "lvalue" badly.
(I am not sure that there *is* any good solution to this. The
approach I would probably have taken is to define all structure-valued
functions as returning an "automatically-dereferenced pointer" to
a "very-short-duration object", but describing the storage duration
of that object is itself problematic. This pointer would allow
computing &(f().a), and even &(f()), and using it until the object's
duration expires. Depending on the lifetime, passing &(f()) to
memcpy() might become valid, for instance. I suspect the right
duration might be "until the next sequence point", though, and the
sequence point before the call to memcpy() would invalidate the
pointer. But then consider calls of the form: g(f(), f()), where
g() is a function taking a "struct S" -- are they defined, or not?)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[E. Robert Tisdale]

Chris Torek wrote:

[snip]

No constant is an object, and no object is ever a constant,
in C (here C differs markedly from C++,
where "const" variables *are* constants, yet can be C-style objects).
[snip]
Hence, the concept of "constant" in C is somewhat peculiar and subtle.
And flawed.
In C89, with one kind-of-broken exception, arrays are never values,
only objects.
[snip]
C99's solution to this problem in C89 wound up re-defining "lvalue" badly.

These are symptoms of serious design flaws and muddled thinking.
You can't fix these problems be redefining words or "overloading"
the meaning of words. These are just *weasel* words or meanings.
The introduction of one weasel word creates problems
that require the introduction of other weasel words
until you can't keep up any more.

[Dan Pop]

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

Keith Thompson wrote:

C99 3.14 defines the word "object"
as "region of data storage in the execution environment,
the contents of which can represent values".

There is no "region of data storage"
necessarily associated with the expression (int)42.

Where is it written that a "region of data storage"
must *necessarily* be associated with the expression (int)42?

In the definition of "object". If it isn't, then (int)42 is not an
object. Which you can trivially check by attempting to take the address
of (int)42. If you succeed, then you have an object, if you don't, you
were merely spitting bullshit, as usual.

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

[Rufus V. Smith]

"CBFalconer" <cb********@yahoo.com> wrote in message
news:40***************@yahoo.com...

"E. Robert Tisdale" wrote:

Mike Wahler wrote:

IOW objects represent values, but not all values are objects.

Can you give us an example of a value that is *not* an object?

You can easily see an object that is not of value. Use a mirror.

Uncalled for, but it did make me laugh...

[Mike Wahler]

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

Keith Thompson wrote:

C99 3.14 defines the word "object"
as "region of data storage in the execution environment,
the contents of which can represent values".

There is no "region of data storage"
necessarily associated with the expression (int)42.
Where is it written that a "region of data storage"
must *necessarily* be associated with the expression (int)42?

Nowhere. Exactly as Keith says. Read again what he wrote above.

the existence of an object depends upon the implementation?

If that doesn't convince you, how about this:

int x = 41;
x + 1;

x + 1 is an expression whose value is 42.
There is no object with that value.
You are wrong.

If x is a static variable,
it could be initialized with the value 41 by the compiler
but, is x is an automatic variable,
the code emitted by the compiler will need to get the value 41
from some storage somewhere to initialize x.

No, it need not.
According to you, then 41 would be an object.
No, according to Keith's explanation, it would not.
Read again what he wrote above.
Unless your compiler optimizes away the "x + 1" expression
(perhaps because it is not used),
Optimization has nothing to do with it.
a temporary object will be allocated (in a register perhaps)
to store the value of x + 1.
Consider, for example,

int x = 41;
int y = x + 1;
int z = 3*y;
// no further references to y

A good optimizing compiler will elide the storage for y
and compute

int z = 3*(x + 1);

directly.

In C, an object is something *could* occupy storage.
This assertion directly contradicts the C standard,
which specifically defines an object as a region of
storage. It *is* a region of storage, not 'might be'
or 'could be'.
Whether it actually does occupy storage or not
may be left up to the optimizer.

Huh? Again, 'optimizers', have nothing to do with it.
No storage, no object.

-Mike

[E. Robert Tisdale]

Mike Wahler wrote:

E. Robert Tisdale wrote:

Consider, for example,

int x = 41;
int y = x + 1;
int z = 3*y;
// no further references to y

A good optimizing compiler will elide the storage for y
and compute

int z = 3*(x + 1);

directly.

In C, an object is something *could* occupy storage.
This assertion directly contradicts the C standard,

The standard be damned.
which specifically defines an object as a region of storage.
It *is* a region of storage, not 'might be' or 'could be'.

You ignored my example above. Is y an object or not?
Is y [still] an object if the C compiler optimizes it away
and computes

int z = 3*(x + 1);

directly?

[Keith Thompson]

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

Keith Thompson wrote:

[...]

It's an expression, and it has a value, but it's not an object.
Evaluation of the expression may or may not involve
an int-size region of storage containing the value 42;
that's an implementation detail,
irrelevant to C's definition of "object".

Are we to infer that
the existence of an object depends upon the implementation?

No, the existence of an object depends on the definition in the
standard.

For a declared object, such as "int y;", the standard says y is an
object. An implementation is allowed not to allocate storage for it,
if this optimization doesn't change the effect of the program, but
it's still an object in the abstract machine.

For an expression such as 42, the standard does not say that there is
an object associated with the value of the expression. An
implementation may allocate an int-sized region of storage holding the
value 42, but there's still no object in the abstract machine.

Optimization does not affect whether something is an object as defined
by the standard.

(I'm writing this for the benefit of other readers, since ERT is
unlikely to be convinced by anything I write.)

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

[Alex Monjushko]

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

Mike Wahler wrote:

E. Robert Tisdale wrote:

Consider, for example,

int x = 41;
int y = x + 1;
int z = 3*y;
// no further references to y

A good optimizing compiler will elide the storage for y
and compute

int z = 3*(x + 1);

directly.

In C, an object is something *could* occupy storage.

This assertion directly contradicts the C standard, The standard be damned. which specifically defines an object as a region of storage.
It *is* a region of storage, not 'might be' or 'could be'.

You ignored my example above. Is y an object or not?
Is y [still] an object if the C compiler optimizes it away
and computes int z = 3*(x + 1); directly?

I believe that in this case the "as if" rule comes into effect.
It makes absolutely no difference whether 'y' is optimized away
or not. In a context where it would make a difference the optimizer
can't get rid of it.

Therefore, 'y' is an object, as far as you can tell in terms of
the C standard. Assembler output notwithstanding.

--
Alex Monjushko (mo*******@hotmail.com)

[Keith Thompson]

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

Mike Wahler wrote:

E. Robert Tisdale wrote: [...]

In C, an object is something *could* occupy storage.

This assertion directly contradicts the C standard,

The standard be damned.

That's a perfectly valid attitude. If you don't like the standard, or
if you just want to ignore it, you're absolutely free to do so. If
you want to program in some non-standard dialect of C, or of some
C-like language, go right ahead. There are over 6 billion people on
this planet; probably at least 5.9 billion of them aren't even aware
that the C standard exists (and if those numbers are off, the point is
still valid).

What mystifies me is why you choose to hang out here in comp.lang.c,
where we discuss the C programming language as defined by that damned
standard.

If you want to leave, nobody here is going to try to stop you. We'll
be fine. Really.

Bye.

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

[CBFalconer]

"Rufus V. Smith" wrote:

"CBFalconer" <cb********@yahoo.com> wrote in message

"E. Robert Tisdale" wrote:

Mike Wahler wrote:

IOW objects represent values, but not all values are objects.

Can you give us an example of a value that is *not* an object?

You can easily see an object that is not of value. Use a mirror.

Uncalled for, but it did make me laugh...

You haven't suffered through Trollsdale postings ad nauseam.

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

[E. Robert Tisdale]

Keith Thompson wrote:

E. Robert Tisdale writes:

Are we to infer that
the existence of an object depends upon the implementation?
No, the existence of an object depends on
the definition in the standard.

I suppose that it also depends upon the code.
For a declared object, such as "int y;",
the standard says y is an object.
An implementation is allowed not to allocate storage for it,
if this optimization doesn't change the effect of the program,
but it's still an object in the abstract machine.
This appears to be consistent with my assertion that
"and object is a value that *could* occupy storage.
For an expression such as 42, the standard does not say that
there is an object associated with the value of the expression.
An implementation may allocate an int-sized region of storage
holding the value 42,
but there's still no object in the abstract machine.
int x = 42;

How does the "abstract machine" know that
x is initialized with the value 42?

A C program is correspondence from the programmer to the C compiler
and not any underlying abstract [or concrete] machine.
Optimization does not affect
whether something is an object as defined by the standard.

According to Brian W. Kernighan and Dennis M. Ritchie,
"The C Programming Language", Appendix A: C Reference Manual,
Section 5. Objects and lvalues:
" An object is a manipulatable region of storage;
an lvalue is an expression referring to an object.
An obvious example of an lvalue expression is an identifier.
There are operators which yield lvalues: for example,
if E is an expression of pointer type,
then *E is an lvalue expression
referring to the object to which E points.
The name ``lvalue'' comes from the assignment expression E1 = E2
in which the left operand E1 must be an lvalue expression."

Notice that K&R don't specify that constants are not objects.
The term ``object'' is introduced to help explain
the notion of ``lvalue'' but it is flawed.
It appears to imply that objects are *always* variables
which was true in the original definition of C.
Constants were always *literal* constants.
The C 89 standard introduced the ``const'' keyword
to qualify "read-only" storage and the const variable oxymoron.
This is a fundamental flaw in the design of the C language.
No redefinition of ordinary English words like object
is going to resolve it.
C programmers are *not* true believers.
The C standards documents are *not* religious dogma.
They were *not* carved in stone by God
and brought down from Mount Sinai by Moses.
They were written by human beings and, in cases like this,
they expose the muddled thinking of those human beings.
They deserve the same critical skepticism that you apply
to articles submitted to the comp.lang.c newsgroup.

[E. Robert Tisdale]

Keith Thompson wrote:

[Love it or leave it.]

Religious intolerance?

[CBFalconer]

Keith Thompson wrote:

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

The standard be damned.

.... snip ...
If you want to leave, nobody here is going to try to stop you.
We'll be fine. Really.

Maybe we should take a straw vote. Three options:

a. Want to stop ERT from leaving:
b. Encourage ERT to leave :
c. Indifferent to ERT existence :

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

[Kelsey Bjarnason]

[snips]

On Fri, 11 Jun 2004 13:43:51 -0700, E. Robert Tisdale wrote:

For an expression such as 42, the standard does not say that
there is an object associated with the value of the expression.
An implementation may allocate an int-sized region of storage
holding the value 42,
but there's still no object in the abstract machine.
int x = 42;

How does the "abstract machine" know that
x is initialized with the value 42?

Could be any number of ways. You're thinking in terms of the following
sequence of operations:

x dw (?)
mov [x], 42

In the binary, then, we might see a byte sequence along the lines of:

....
00 00 00 00 [storage space for x]
....
2a 00 00 00 [value of 42]

The code reads the literal value 42 and stores it into the space reserved
for x. 42 is thus "separate" from x in some sense. On the other hand,
the byte sequence could simply be:

.....
2a 00 00 00 [storage space for x, with the 42 hardcoded in place]
.....

Now there's no conceptual separation of the 42 and x - no separately
stored values. In the former case, you could, if you wanted, modify the
bits in the value for 42 *without* affecting the value in x; in the latter
case you can't, as the two are in no manner whatsoever separate entities.

That is to say, the 42 is not an object; it has no independant storage, no
address to be taken, nothing. It simply does not exist except as the
(current) value of x.

A C program is correspondence from the programmer to the C compiler and
not any underlying abstract [or concrete] machine.
The standard is a contract, of sorts; the developer writes according to
its rules, the compiler compiles according to its rules. The standard
defines how operations occur in relation to an abstract machine.
" An object is a manipulatable region of storage;
You can't manipulate 42; you can only assign from it.
C programmers are *not* true believers. The C standards documents are
*not* religious dogma.
No, they're not - they are the set of rules which compilers are expected
to follow to produce correct results, and which developers are expected to
follow to get the correct results.
brought down from Mount Sinai by Moses. They were written by human
beings and, in cases like this, they expose the muddled thinking of
those human beings.

There's not much unclear here.

[Kelsey Bjarnason]

[snips]

On Fri, 11 Jun 2004 11:33:18 -0700, E. Robert Tisdale wrote:

This assertion directly contradicts the C standard,

The standard be damned.

The VB channel is down the hall.

[Joona I Palaste]

Kelsey Bjarnason <ke*****@xxnospamyy.lightspeed.bc.ca> scribbled the following:

On Fri, 11 Jun 2004 13:43:51 -0700, E. Robert Tisdale wrote:

C programmers are *not* true believers. The C standards documents are
*not* religious dogma.

No, they're not - they are the set of rules which compilers are expected
to follow to produce correct results, and which developers are expected to
follow to get the correct results. brought down from Mount Sinai by Moses. They were written by human
beings and, in cases like this, they expose the muddled thinking of
those human beings.

There's not much unclear here.

I think ERT fails to understand the concept of a standard.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Outside of a dog, a book is a man's best friend. Inside a dog, it's too dark
to read anyway."
- Groucho Marx

[E. Robert Tisdale]

Kelsey Bjarnason wrote:

E. Robert Tisdale wrote:

int x = 42;

How does the "abstract machine" know that
x is initialized with the value 42?

Could be any number of ways. You're thinking in terms of the following
sequence of operations:

x dw (?)
mov [x], 42

In the binary, then, we might see a byte sequence along the lines of:

....
00 00 00 00 [storage space for x]
....
2a 00 00 00 [value of 42]

The code reads the literal value 42 and stores it into the space reserved
for x. 42 is thus "separate" from x in some sense.
On the other hand, the byte sequence could simply be:

.....
2a 00 00 00 [storage space for x, with the 42 hardcoded in place]
.....

Now there's no conceptual separation of the 42 and x - no separately
stored values. In the former case, you could, if you wanted, modify the
bits in the value for 42 *without* affecting the value in x; in the latter
case you can't, as the two are in no manner whatsoever separate entities.

That is to say, the 42 is not an object;
it has no independant storage, no address to be taken, nothing.
It simply does not exist except as the (current) value of x.

Only if x is a static variable.
Not if x is an *automatic* variable.
In this function:

int f(void) {
static
int x = 42;
return x + 1;
}

x may be initialized by the compiler as you suggest above
but, in this function:

int f(void) {
int x = 42;
return x + 1;
}

x must be re-initialized to the value 42
*every* time that the function f(void) is invoked.
If 42 is small enough,
the compiler can store it in a "load immediate" instruction
as you have suggested above,
but it *must* store the value 42 somewhere.
If the fact that storage is reserved for a value makes it an object,
then 42 is an object.

[Kelsey Bjarnason]

[snips]

On Sat, 12 Jun 2004 18:41:27 -0700, E. Robert Tisdale wrote:

That is to say, the 42 is not an object;
it has no independant storage, no address to be taken, nothing.
It simply does not exist except as the (current) value of x.
Only if x is a static variable.

Thus demonstrating that 42 is not an object, as if it were, it would
_always_ be an object. Yes, and?

x may be initialized by the compiler as you suggest above but, in this
function:

int f(void) {
int x = 42;
return x + 1;
}
}

So the compiler generates a hardcoded value of 42 at the address of x, as
I noted in the second case, copying x to modifiable memory on write.
Still no problem, still not even conceptually an object for 42.

[Mike Wahler]

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

Mike Wahler wrote:

E. Robert Tisdale wrote:

Consider, for example,

int x = 41;
int y = x + 1;
int z = 3*y;
// no further references to y

A good optimizing compiler will elide the storage for y
and compute

int z = 3*(x + 1);

directly.

In C, an object is something *could* occupy storage.
This assertion directly contradicts the C standard,

The standard be damned.

Well, this ends the discussion. The language I'm discussing
is *defined* by that standard. If that language isn't
what you're referring to, this discussion is pointless.

which specifically defines an object as a region of storage.
It *is* a region of storage, not 'might be' or 'could be'.
You ignored my example above. Is y an object or not?

Yes.
Is y [still] an object if the C compiler optimizes it away
I'm talking about the C language, not any compiler. From
the perspective of the language, 'y' is an object, created
by the statement which defines it. What an implementation
does with it doesn't matter.
and computes

int z = 3*(x + 1);

directly?

The statement:

int y = x + 1;

Creates an object (with or without the initializer).

-Mike

[Mike Wahler]

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

Keith Thompson wrote:

E. Robert Tisdale writes:

Are we to infer that
the existence of an object depends upon the implementation?
No, the existence of an object depends on
the definition in the standard.

I suppose that it also depends upon the code.

For a declared object, such as "int y;",
the standard says y is an object.
An implementation is allowed not to allocate storage for it,
if this optimization doesn't change the effect of the program,
but it's still an object in the abstract machine.

This appears to be consistent with my assertion that
"and object is a value that *could* occupy storage.

No. No. No. An object is *not* a value. As a matter of fact,
an object can exist which does not represent a value.

int main()
{
int i; /* an object with no value */

return 0;
}

For an expression such as 42, the standard does not say that
there is an object associated with the value of the expression.
An implementation may allocate an int-sized region of storage
holding the value 42,
but there's still no object in the abstract machine.
int x = 42;

How does the "abstract machine" know that
x is initialized with the value 42?

Because the source code stated so in a way compliant
with the language definition.
A C program is correspondence from the programmer to the C compiler
and not any underlying abstract [or concrete] machine.
No. The communication is from the coder to the abstract machine.
The C language's existence does not depend upon the existence
of any implementations. (though its usefulness does).

Optimization does not affect
whether something is an object as defined by the standard.

According to Brian W. Kernighan and Dennis M. Ritchie,

The rest is such blatant trolling, I'll just delete it.

-Mike

[Irrwahn Grausewitz]

Amongst other crap

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

This appears to be consistent with my assertion that
"and object is a value that *could* occupy storage.

"Mike Wahler" <mk******@mkwahler.net> correctly replied:
No. No. No. An object is *not* a value. As a matter of fact,
an object can exist which does not represent a value.
Agreed: an object is not a value, it's a region of storage that /can/
hold a value, but /may/ hold a bit pattern that does not represent a
valid value with respect to the type of the object.
int main()
{
int i; /* an object with no value */

But I'm not sure this comment is entirely correct from a pedant's
point of view: the standard postulates that the value is
indeterminate. An indeterminate value is defined as "either an
unspecified value or a trap representation" (C99 3.17.2). The
uninitialized object designated by i might actually hold a value;
alas, one cannot check without invoking undefined behaviour.

Not that it really matters, practically.

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html

[Arthur J. O'Dwyer]

On Mon, 14 Jun 2004, Irrwahn Grausewitz wrote:

"Mike Wahler" <mk******@mkwahler.net> correctly replied:

[inside a function]

int i; /* an object with no value */

But I'm not sure this comment is entirely correct from a pedant's
point of view: the standard postulates that the value is
indeterminate. An indeterminate value is defined as "either an
unspecified value or a trap representation" (C99 3.17.2). The
uninitialized object designated by i might actually hold a value;
alas, one cannot check without invoking undefined behaviour.

So by the as-if rule, it is correct both that "i has no value"
*and* that "i has a value." ;-) Nice attribution line [snipped],
BTW. ;-))

And another reminder to people not to feed the trolls once their
errors have been satisfactorily rebuffed already in one thread.
Thanks.

-Arthur

[Richard Bos]

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message

If I send a letter to you, should I care whether you live in a
detached house or in a flat? Of course not - as long as I have
your correct address, the letter will arrive fine.
But you need to know whether you are sending one gas bill (to the detached
house) or many (to each resident of the block of flats).

You already do; you've either written one bill or many. Post as many
bills as you have to as many addresses.
IOW: you either do an operation on a block of memory or on a single
object. You need to know whether you can have several objects or not
when you design the algorithm, not just when your running program first
sees the pointer.
If "int *ptr;" were a pointer to an integer, period,

Nobody said it was. It's an object of type "pointer to int". That is, it
points to an int object, or possibly to several. It does not point to an
entire array. It _may_ point to one of the array's members, possibly the
first one, but it does not point to the entire array at once.

Richard

[Andy Green]

"Stephen Sprunk" <st*****@sprunk.org> wrote in message news:<35******************************@news.terane ws.com>...

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

Joe Laughlin wrote:

At the university I recently graduated from,
the professors didn't "teach" languages.

You don't need professors to teach programming languages.
You can get a lecturer, maybe a graduate student, to do that.
You don't need to teach programming languages
to computer science students.
Computer science students are usually smart enough
to pick up programming languages on their own as needed.
When computer programming languages are offered at a University
to computer science students they are considered "remedial".

Unfortunately many educational institutions disagree. I dropped my CS major
because of this, actually; the entire undergrad program was dedicated to
teaching me things I already knew or could have picked up on my own, and all
the classes I wanted to take to learn REAL computer science were
post-graduate level.

Also, there seems to be a shift towards software engineering
and away from general computer science. Dunno if this is good or not.

I don't think so. Software Engineering is a field in Computer Science.

I've always considered "sciences" to be about building on existing ideas to
create and validate (or invalidate) new ideas, whereas "engineering" is more
an application of existing ideas to real-world problems. In programming
this is a bit blurred, but one can surely see the distinction between trying
to find new compiler optimizations vs. coding some commercial database app.

As a recent graduate (this last week), I just started a new job,
and I've found out that I'm pretty rusty on pointers,
bit-shifting/byte-packing techniques, big/little-endians, etc.
However, I feel that I'm pretty good at software design,
object-oriented programming, project management, etc.

Unfortunately, programming has almost nothing to do
with software engineering as you well know.
A software engineer is *not* just a glorified computer programmer.

I'd say that software design requires a very different skillset than
software implementation, but both are aspects of software engineering.

S

I am no expert. But I know that an when you declare an array, that
array is an address that starts somewhere in memory and is reserved
for physical storage stof elements. The first element starts at the
address. A pointer, is just an element that stores an adress and that
is it, it is like a variable but it contains an address. So what is so
complicated?. What am I missing?

[Dan Pop]

In <a7**************************@posting.google.com > an*******@optonline.net (Andy Green) writes:

I am no expert. But I know that an when you declare an array, that
array is an address that starts somewhere in memory and is reserved
for physical storage stof elements. The first element starts at the
address. A pointer, is just an element that stores an adress and that
is it, it is like a variable but it contains an address. So what is so
complicated?. What am I missing?

Two things:

sizeof array
&array

The name of the array doesn't refer to any address, it refers to the
object itself. However, in most contexts, references to arrays are
automatically *converted* to pointers to their first elements. The
exceptions are listed above: sizeof array gives the size of the whole
array and not the size of a pointer to its first element and &array is
a pointer to the whole array, not to the first element of the array
(this is a change from K&R C), which is relevant in pointer contexts,
even if the address of the whole array coincides with the address of
its first element.

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