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/

"Me" <bogus@bogus.com> wrote in message
>
> " The Shocking Truth: C Arrays and Pointers Are NOT the
> Same!
>
Array labels decay to pointers, so

void foo(int *ptr);

void bar(void)
{
  int arr[100];

  foo(arr);
}

calls foo with a pointer to an array of integers.

This ia all you need to know about C array pointer equivalence.

If you start using multi-dimensional arrays and fancy declarations you
deserve all that is coming to you.

Something that calls itself Me wrote:

> 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

Obvious hyperbole.

> 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 *' 
>                      // but 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!

Do you feel better now that you got that off your chest?

On Tue, 8 Jun 2004 22:30:49 +0100, Malcolm  
<malcolm@55bank.freeserve.co.uk> wrote:

> "Me" <bogus@bogus.com> wrote in message
>>
>> " The Shocking Truth: C Arrays and Pointers Are NOT the
>> Same!
>>
> Array labels decay to pointers, so
>
> void foo(int *ptr);
>
> void bar(void)
> {
>   int arr[100];
>
>   foo(arr);
> }
>
> calls foo with a pointer to an array of integers.

Actually you are mistaken...probably you just mis-typed.

It calls foo with a pointer to an int.... not a pointer to an array of  
ints.
It just so happens that what the pointer is pointing to is the first int in
the allocated array of 100 ints, but 'foo' doesn't know that. foo() just  
thinks
it is an 'int' pointer.

>
> This ia all you need to know about C array pointer equivalence.
>
> If you start using multi-dimensional arrays and fancy declarations you
> deserve all that is coming to you.
>
>



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

Me wrote:
> 
> 
> Malcolm wrote:
> 
>> Array labels decay to pointers, so
>>
>>      void foo(int *ptr);
>>
>>      void bar(void) {
>>        int arr[100];
>>        foo(arr);
>>        }
>>
>> calls foo with a pointer to an array of integers.
> 
> Actually you are mistaken...probably you just mis-typed.
> 
> It calls foo with a pointer to an int.... 
> not a pointer to an array of ints.

Correct.

> It just so happens that what the pointer is pointing to
> is the first int in the allocated array of 100 ints,

I'm pretty sure that you don't mean to imply that
it is just an accident that arr is converted
into a pointer to the first element of arr.

> but 'foo' doesn't know that.
> foo() thinks [that] it is just an 'int' pointer.

Me wrote:
> 
.... snip ...
> 
> 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.

When I got out of college in nineteen-<mumble> I certainly didn't
think so. :-)

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

"Me" <bogus@bogus.com> wrote in message
news:opr9anp8huabpysj@danocdhcp011136.americas.nokia.com...
>
> 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!

I'm currently teaching my self C from books and the internet and when I
first started learning, constant mentions of the "equivalence" of arrays and
pointers confused the hell out of me because based on what I understood
(correctly) about pointers and arrays, there is nothing equivalent about
them, they're completely different although related things. What would have
saved me a bunch of headscratching would be definitions of an array and a
pointer and then statements of the following facts:

An array, when referenced without an element number decays into a pointer to
that array's first element (without needing to use the & operator)

#include <stdio.h>
int main (void) {
    int foo[10];
    int *bar;
    bar = foo;
    printf("%i",bar[1]);      /* is equivalent to the following */
    printf("%i",*(bar+1));  /* both will output the contents of foo[1] */
    return 0;
}

Based on a understanding of pointers and arrays, this explains all that
needs to be explained without using the words "arrays and pointers are
equivalent" or similar which I've seen in several places and are just
blatantly wrong.

Excuse me and please do correct me if I've used any incorrect terminology
here, as I said, I'm still learning.

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

And somewhere around the time of 06/08/2004 14:10, the world stopped and
listened as Me contributed the following to humanity:

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

Yes and no.  An array is a list of data of some type.  A pointer is a
reference that points to some data in memory.

Internally, the array identifier acting as the base address, coupled
with the index * data size, generates a pointer to that data element in
memory.  All of this is internal to the compiler/linker and is usually
transparent to the programmer, at least that's what my expeiriance has been.

-- 
Daniel Rudy

Email address has been encoded to reduce spam.
Remove all numbers, then remove invalid, email, no, and spam to reply.

"Malcolm" <malcolm@55bank.freeserve.co.uk> wrote in message
news:ca5b0d$tse$1@news7.svr.pol.co.uk...
> "Me" <bogus@bogus.com> wrote in message
> >
> > " The Shocking Truth: C Arrays and Pointers Are NOT the
> > Same!
> >
> Array labels decay to pointers, so
>
> void foo(int *ptr);
>
> void bar(void)
> {
>   int arr[100];
>
>   foo(arr);
> }
>
> calls foo with a pointer to an array of integers.

Wrong.  Calls 'foo()' with a pointer to an 'int'.
(type 'int*').  Pointer-to-int and pointer-to-array-of-ints
are not the same type.

int *p;         /* pointer to int */
int (*pa)[100]; /* pointer to array of 100 ints */


> This ia all you need to know about C array pointer equivalence.

I don't think one should 'know' incorrect information.
>
> If you start using multi-dimensional arrays and fancy declarations you
> deserve all that is coming to you.

What's 'wrong' with using multi-dimensional arrays,
and what will come to me if I use one?

I won't ask what you consider a 'fancy' declaration.

-Mike

hi all; i'm a self-taught C-hobbyst; i want to sing k&r's praises: their
book was somewhat hard for me, i proceeded slowly, sometimes at the "speed"
of few pages/week, but it's impossible to confuse pointer with arrays then;
the problem is C needs a non-superficial study

"Kieran Simkin" <kieran@digital-crocus.com> writes:
[...]
> An array, when referenced without an element number decays into a pointer to
> that array's first element (without needing to use the & operator)

An array name (an identifer that refers to an array object) decays
into a pointer to the first element whenever it appears in an
expression, unless it's the operand of a sizeof or unary "&" operator.

Note that the decay even occurs in an indexing expression:

    int array_obj[10];
    int x;
    ...
    x = array_obj[5];

In the assignment, the name "array_obj" decays to a pointer to the
first element of the array object.  The indexing operator takes two
operands, a pointer and an integer.

Read section 6 of the C FAQ.

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

Cheerio,


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

If it helps you feel better: We have a finite element code we are
working with, written in C, largely undocumented, many thousand lines,
and are looking for students to work for us.
We get many applications from so-called software engineering students
in their final year. Every single interview came to the point that
they did not "know" any programming language at all while boasting
knowledge of a multitude. We never ever did even get to the point
where such "fine details" like the differences between arrays and
pointers would have played a role. Same thing when we were looking
for someone doing some things in Matlab for us.
So, do not tell me about frustration ;-)


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

Based on my sad experiences, I am at the moment teaching C to
beginners in order to get someone able to work with us.
I did never tell anyone that pointers and arrays were equivalent,
in fact, I only started with "&array[0]" and came up with the "idea"
of using "array" later on, explained exactly what pointers are,
what arrays are, how they relate -- nonetheless, "pointer equals array"
is exactly the sort of idea I see them using in their assignments.
I try to exorcise it in the next lesson but somehow it sticks. I
suggested a couple of C books to the students but somehow I never
caught anyone reading one of them. They just get the cheapest C books
off Amazon thinking this will do... :-/
Seeing my efforts having no effect for at least ten percent of my
students, I can only say: Maybe, the fault is not only in the teachers.

Another thing is that you have to learn some things entirely by
yourself. Only after you made a serious mistake or saw the outcome
of some mistake you will remember it by heart. A friend of mine
for example needed to find out by himself that a quadratic time
complexity is _much_ worse than linear time complexity of an
algorithm - even though he theoretically knew it beforehand.
Looking at myself and at my colleagues as well, I'd say that every
year I am still learning quite a lot of things in all the programming
languages I am using.



Just my two cents
  Michael

"Keith Thompson" <kst-u@mib.org> wrote in message news:lnvfi1maew.fsf@nuthaus.mib.org...
> "Kieran Simkin" <kieran@digital-crocus.com> writes:
> [...]
> > An array, when referenced without an element number decays into a pointer to
> > that array's first element (without needing to use the & operator)
>
> An array name (an identifer that refers to an array object) decays
> into a pointer to the first element whenever it appears in an
> expression, unless it's the operand of a sizeof or unary "&" operator.
>

.... and when a character string literal is used to initialize an array.


> Note that the decay even occurs in an indexing expression:
>
>     int array_obj[10];
>     int x;
>     ...
>     x = array_obj[5];
>
> In the assignment, the name "array_obj" decays to a pointer to the
> first element of the array object.  The indexing operator takes two
> operands, a pointer and an integer.
>
> Read section 6 of the C FAQ.
>
> --
> Keith Thompson (The_Other_Keith) kst-u@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.

In article <ca6h4p$elo$1@infosun2.rus.uni-stuttgart.de>,
 Michael Mair <mairRemove_for_mailinG@ians.uni-stuttgart.de> wrote:

> Another thing is that you have to learn some things entirely by
> yourself. Only after you made a serious mistake or saw the outcome
> of some mistake you will remember it by heart. A friend of mine
> for example needed to find out by himself that a quadratic time
> complexity is _much_ worse than linear time complexity of an
> algorithm - even though he theoretically knew it beforehand.
> Looking at myself and at my colleagues as well, I'd say that every
> year I am still learning quite a lot of things in all the programming
> languages I am using.

In my experience, different people learn in different ways. Some prefer 
to actually try out things because it helps them learning. However, 
trying out things is also useful to check if the theory is really 
correct (I once saw a C++ programmer using the quicksort algorithm, but 
for sorting an array of variable sized items, and the underlying methods 
for changing an item took time O (total size of all items) when changing 
the size of an item. The code was not O (N log N), and it was not fast 
enough (noticable delay in the user interface in non-trivial cases)). 

Also, an algorithm with higher time complexity may be faster than one of 
lower complexity up to a certain size. Consider method A taking (N^(2/3) 
log^2 (N)) nanoseconds, and method B taking N^0.7 nanoseconds. For large 
N, method A is faster. For any problem that can be solved in a billion 
years, method A is slower.

Michael Mair <mairRemove_for_mailinG@ians.uni-stuttgart.de> writes:
> > Man the C teachers in college aren't doing their job!
> 
> Based on my sad experiences, I am at the moment teaching C [...]
> I suggested a couple of C books to the students but somehow I never
> caught anyone reading one of them. They just get the cheapest C books
> off Amazon thinking this will do... :-/ Seeing my efforts having no
> effect for at least ten percent of my students, I can only say: Maybe,
> the fault is not only in the teachers.

I don't think it is only the teachers' fault.

While being a student at the Computer Engineering & Informatics
Department here in Patras, Greece, I used to say that about 80% of the
students who enter my department every year are not interested (and,
quite probably, they never will be) in learning anything beyond the
absolutely necessary stuff they have to "put up with" in order to get a
degree.  Only a small number of the remaining 20% has the patience and
perseverance it takes to learn more about the fine details of
programming--regardless of the language in question.

> Another thing is that you have to learn some things entirely by
> yourself.

So very true.

- Giorgos

Michael Mair wrote:
> 
>> 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.
> 
> If it helps you feel better: We have a finite element code we are
> working with, written in C, largely undocumented, many thousand lines,
> and are looking for students to work for us.
> We get many applications from so-called software engineering students
> in their final year. Every single interview came to the point that
> they did not "know" any programming language at all while boasting
> knowledge of a multitude. We never ever did even get to the point
> where such "fine details" like the differences between arrays and
> pointers would have played a role. Same thing when we were looking
> for someone doing some things in Matlab for us.
> So, do not tell me about frustration ;-)
> 
>> Man the C teachers in college aren't doing their job!
> 
> Based on my sad experiences, I am at the moment teaching C to
> beginners in order to get someone able to work with us.

Maybe you are looking at the wrong end of the age spectrum?

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Hi CBFalconer,


>>>Man the C teachers in college aren't doing their job!
>>
>>Based on my sad experiences, I am at the moment teaching C to
>>beginners in order to get someone able to work with us.
> 
> Maybe you are looking at the wrong end of the age spectrum?

Well, that might be true - however, I have only money for
students at my hands, and they do not come in arbitrary ages.
When I learned C, I took to it quick enough -- of course,
I needed another five years to get a deeper understanding
but the basics were clear rather quickly.

However, I am confident that about a third of my students will
be able to work with our code after a short introduction to the
general layout, concepts and ideas.


Cheers,
  Michael

Hello Christian,


> In my experience, different people learn in different ways. Some prefer 
> to actually try out things because it helps them learning. However, 
> trying out things is also useful to check if the theory is really 
> correct (I once saw a C++ programmer using the quicksort algorithm, but 
> for sorting an array of variable sized items, and the underlying methods 
> for changing an item took time O (total size of all items) when changing 
> the size of an item. The code was not O (N log N), and it was not fast 
> enough (noticable delay in the user interface in non-trivial cases)). 

True enough - especially when creating your own algorithmss you cannot
do without :-)
(As to the complexity: Can happen. Some things you have to write down on
a sheet of paper first in order to have the full overview of what 
happens when, how often and with what relation to N...)


> Also, an algorithm with higher time complexity may be faster than one of 
> lower complexity up to a certain size. Consider method A taking (N^(2/3) 
> log^2 (N)) nanoseconds, and method B taking N^0.7 nanoseconds. For large 
> N, method A is faster. For any problem that can be solved in a billion 
> years, method A is slower.

Nice example, thanks :-)
However, I was talking about linear and quadratic complexity with the 
highest leading constant for the linear algorithm being about two to 
four times higher than for the quadratic one. Here, you get a noticeable
difference for several thousands of objects...


Cheers,
  Michael

"Mike Wahler" <mkwahler@mkwahler.net> wrote in message
news:1kyxc.7648$uX2.4414@newsread2.news.pas.earthlink.net...
>

> What's 'wrong' with using multi-dimensional arrays,
> and what will come to me if I use one?
>
> I won't ask what you consider a 'fancy' declaration.
>
> -Mike
>
I think what confuses people learning C is that if you declare two arrays:

int a[10]
int b[10][10]

then a[0] is integer and b[0] is a pointer to integer.
-Jyrki

JV <n.n@n.com.invalid> scribbled the following:
> "Mike Wahler" <mkwahler@mkwahler.net> wrote in message
> news:1kyxc.7648$uX2.4414@newsread2.news.pas.earthlink.net...
>> What's 'wrong' with using multi-dimensional arrays,
>> and what will come to me if I use one?
>>
>> I won't ask what you consider a 'fancy' declaration.
>>
> I think what confuses people learning C is that if you declare two arrays:

> int a[10]
> int b[10][10]

> then a[0] is integer and b[0] is a pointer to integer.

It would confuse them, yes. Fortunately it's not true. b[0] is an
array of ten integers.

-- 
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers."   
   - Bill Gates

In <opr9anp8huabpysj@danocdhcp011136.americas.nokia.com> Me <bogus@bogus.com> writes:


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

The root of the problem is the fact that most C books don't explain 
"the rule" right.  This is one of the few places where the text of the
C standard itself is more clear than the usual tutorial book.  Even K&R2
contains statements like:

    Since the name of an array is a synonym for the location of the 
    initial element...

that are much more misleading than helpful.  After reading K&R1, I
conceptualised arrays as constant pointers (or pointer constants) to
an unnamed storage area, rather than the storage area itself, whose
name gets automatically converted to a pointer to its first element
in most contexts.  This explained why you cannot assign anything to
an array, but didn't scale well conceptually to arrays of arrays.
It was the c.l.c FAQ that finally clarified the issue for me.

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

"JV" <n.n@n.com.invalid> wrote in message
news:qqExc.18575$k4.371496@news1.nokia.com...
>
> "Mike Wahler" <mkwahler@mkwahler.net> wrote in message
> news:1kyxc.7648$uX2.4414@newsread2.news.pas.earthlink.net...
> >
>
> > What's 'wrong' with using multi-dimensional arrays,
> > and what will come to me if I use one?
> >
> > I won't ask what you consider a 'fancy' declaration.
> >
> > -Mike
> >
> I think what confuses people learning C is that if you declare two arrays:
>
> int a[10]
> int b[10][10]
>
> then a[0] is integer and b[0] is a pointer to integer.

No.  b[0] is not a pointer.  It's an array, of type 'int[10]'

A pointer is not an array.
An array is not a pointer.

I've said this a zillion times here, I suppose I'll
never be able to stop. :-)

-Mike

"Vijay Kumar R Zanvar" <vijoeyz@globaledgesoft.com> wrote in message
news:2io02qFouh1sU1@uni-berlin.de...
>
> "Keith Thompson" <kst-u@mib.org> wrote in message
news:lnvfi1maew.fsf@nuthaus.mib.org...
> > "Kieran Simkin" <kieran@digital-crocus.com> writes:
> > [...]
> > > An array, when referenced without an element number decays into a
pointer to
> > > that array's first element (without needing to use the & operator)
> >
> > An array name (an identifer that refers to an array object) decays
> > into a pointer to the first element whenever it appears in an
> > expression, unless it's the operand of a sizeof or unary "&" operator.
> >
>
> ... and when a character string literal is used to initialize an array.

In that case, the array's name is not being used an an expression.

-Mike

"*a" <_w___k___@____p_.it> wrote in message
news:Jsyxc.434169$rM4.17956251@news4.tin.it...
> hi all; i'm a self-taught C-hobbyst; i want to sing k&r's praises: their
> book was somewhat hard for me, i proceeded slowly, sometimes at the
"speed"
> of few pages/week, but it's impossible to confuse pointer with arrays
then;

> the problem is C needs a non-superficial study

I think this remark hits the mark exactly.

It seems the concise syntax and 'smalless' of C's language
proper leads many to believe it's 'simple', thus they often
don't see the need for deeper study, practice, and experimentation.
But of course C is not really very 'simple' at all.  It is indeed
powerful, though.

$.02,
-Mike

"Mike Wahler" <mkwahler@mkwahler.net> wrote
>
> > void bar(void)
> > {
> >   int arr[100];
> >
> >   foo(arr);
> > }
> >
> > calls foo with a pointer to an array of integers.
>
> Wrong.  Calls 'foo()' with a pointer to an 'int'.
> (type 'int*').  Pointer-to-int and pointer-to-array-of-ints
> are not the same type.
>
> int *p;         /* pointer to int */
> int (*pa)[100]; /* pointer to array of 100 ints */
>
That's the difference between C usage and English usage. C doesn't
distinguish between a pointer to an area of memory containing a single
integer, or an area containing an array of integers. It is correct to say
that bar receives a pointer to 100 integers, and since they are in an array,
it is also correct to say that it receives a pointer to an array of 100
integers. However it is also correct to say that this is false.
>
> What's 'wrong' with using multi-dimensional arrays,
> and what will come to me if I use one?
>
The syntax is horrible and they have few real applications (most 2d arrays
have at least one variable dimension). Your code will be hard to read and
the use of multi-dimension constructs will suggest to the reader that you
don't have much experience with C. Consequently when bugs appear in your
code, as happens to us all from time to time, it will be re-written from
scratch instead of mended. This will cause your employers to question the
value of your continued employment, and in a tight market because of
outsourcing to India you will not be able to find another job, and if you
have few skills outside It you will be forced to take a position at Burger
King where the other staff will laugh at you for being too middle class, so
you will leave and hit the streets, and end your days as a tramp or beggar.

On Wed, 9 Jun 2004, Malcolm wrote:
>
> "Mike Wahler" <mkwahler@mkwahler.net> wrote
[Malcolm himself wrote:]
> > >
> > >   foo(arr);
> > >
> > > calls foo with a pointer to an array of integers.
> >
> > Wrong.  Calls 'foo()' with a pointer to an 'int'.
> > (type 'int*').  Pointer-to-int and pointer-to-array-of-ints
> > are not the same type.
>
> That's the difference between C usage and English usage. C doesn't
> distinguish between a pointer to an area of memory containing a single
> integer, or an area containing an array of integers. It is correct to say
> that bar receives a pointer to 100 integers, and since they are in an array,
> it is also correct to say that it receives a pointer to an array of 100
> integers. However it is also correct to say that this is false.

  The simplest way out of this dilemma, in the context of the C
programming language (which is always the context in this newsgroup),
is to reserve the use of the word "pointer" for the C language's
pointers, and to use the English term "address" for what you seem
to be calling a "pointer."  Thus:

  'main' calls the function 'foo' with an argument which is a pointer
to an 'int'.
  'main' calls 'foo' with a pointer to 'int'.
  'main' calls 'foo' with a pointer which holds the address of the
array 'bar'.
  'bar' is an array[100] of 'int'.
  The address of 'bar' is also the address of the first element of 'bar'.
  The expression 'bar' decays to a pointer to the first element of 'bar'.
  All pointer values have associated types.
  Addresses do not have types.
  The unary '&' operator yields a pointer to the operand object.
  The unary '&' operator yields the address of the operand object
as a value of type "pointer to quux."

All clear, no?

-Arthur

In <ca74or$e1m$1@oravannahka.helsinki.fi> Joona I Palaste <palaste@cc.helsinki.fi> writes:

>JV <n.n@n.com.invalid> scribbled the following:
>> "Mike Wahler" <mkwahler@mkwahler.net> wrote in message
>> news:1kyxc.7648$uX2.4414@newsread2.news.pas.earthlink.net...
>>> What's 'wrong' with using multi-dimensional arrays,
>>> and what will come to me if I use one?
>>>
>>> I won't ask what you consider a 'fancy' declaration.
>>>
>> I think what confuses people learning C is that if you declare two arrays:
>
>> int a[10]
>> int b[10][10]
>
>> then a[0] is integer and b[0] is a pointer to integer.
>
>It would confuse them, yes. Fortunately it's not true. b[0] is an
>array of ten integers.

Which *immediately* decays into ... unless used as the operand of the
sizeof or unary & operators.  This is the confusing bit.

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

"Malcolm" <malcolm@55bank.freeserve.co.uk> wrote in message
news:ca7kp0$cgf$1@news5.svr.pol.co.uk...
>
> "Mike Wahler" <mkwahler@mkwahler.net> wrote
> >
> > > void bar(void)
> > > {
> > >   int arr[100];
> > >
> > >   foo(arr);
> > > }
> > >
> > > calls foo with a pointer to an array of integers.
> >
> > Wrong.  Calls 'foo()' with a pointer to an 'int'.
> > (type 'int*').  Pointer-to-int and pointer-to-array-of-ints
> > are not the same type.
> >
> > int *p;         /* pointer to int */
> > int (*pa)[100]; /* pointer to array of 100 ints */
> >
> That's the difference between C usage and English usage.

Lacking explicit qualification to the contrary,
C meanings take precedence here.

> C doesn't
> distinguish between a pointer to an area of memory containing a single
> integer, or an area containing an array of integers.

Actually, yes it does.  The types are not the same (nor need
their sizes be the same) Also, the types yielded by dereferencing
those two different type pointers are not the same, nor are their
sizes -- except in the case of a pointer to an array of one element
-- that is, their sizes would be the same, but their types still
would not).

> It is correct to say
> that bar receives a pointer to 100 integers,

No it's not.  The name of an array, when passed to a function,
decays to a pointer to its first element.  The type passed
is 'pointer-to-array-element-type'.

>and since they are in an array,

That doesn't matter.

> it is also correct to say that it receives a pointer to an array of 100
> integers.

No, it is not correct.  Again:

Pointer to array of 100 ints:

int (*pa)[100];

Pointer to int:

int *p;

Those two types are *not* the same.  If they were, then this
would be valid:

void foo(int (*arg)[100])
{
}

void bar(void)
{
    int arr[100];
    foo(arr);
}

... but it doesn't.


>However it is also correct to say that this is false.

Huh?

> >
> > What's 'wrong' with using multi-dimensional arrays,
> > and what will come to me if I use one?
> >
> The syntax is horrible

A matter of opinion.  I have no trouble with the syntax.

>and they have few real applications (most 2d arrays
> have at least one variable dimension).

Subjective assesment.  You're limiting your view to
only those applications you can conceive.  Your phrase
'most 2d arrays' is without context, so hasn't any
useful meaning..

>Your code will be hard to read

Subjective opinion again.

>and
> the use of multi-dimension constructs will suggest to the reader that you
> don't have much experience with C.

That made me laugh out loud.

> Consequently when bugs appear in your
> code,

So you're saying that simply by using a 2d array has
the effect of creating bugs?  Oh, please.

>as happens to us all from time to time,

Yes, being human, everyone makes mistakes occasionally
(or perhaps even frequently).  But the use of a particular
(valid) construct is not a direct cause.  What create bugs
are carelessness and/or insufficient knowledge.

>it will be re-written from
> scratch instead of mended.

Depending upon how 'broken' a program is, sometimes
a rewrite is indeed the superior choice.  This has
indeed been the case a few times in my experience
(both with my own code, and that of others).  But
the cause was never the use of a valid language
construct.  Sometimes I'll see that a particular
construct was not the best solution, but that's
a case of poor design, not 'bugs'.

> This will cause your employers to question the
> value of your continued employment,

Any employer/client I might wish to work with will
judge my value by that of what I produce.  The value
of those products is determined by a consumer market,
not anyone's opinions about whether I understand C or not.

> and in a tight market because of
> outsourcing to India you will not be able to find another job,

Being an unabashed capitalist, I gladly welcome competition
from anyone, anywhere.  I don't blame others for any problems
I might have, I take responsibility for solving them.

>and if you
> have few skills outside It you will be forced to take a position at Burger
> King where the other staff will laugh at you for being too middle class,
> so
> you will leave and hit the streets, and end your days as a tramp or
> beggar.

There is nothing dishonorable about working in the food service
industry, or any other value-producing profession.  Nor do I allow
derision of others to dictate my actions.

You sir, are a snob.

-Mike

Dan Pop wrote:

> Joona I Palaste writes:
> 
> 
>>JV scribbled the following:
>>
>>>Mike Wahler wrote:
>>>
>>>>What's 'wrong' with using multi-dimensional arrays,
>>>>and what will come to me if I use one?
>>>>
>>>>I won't ask what you consider a 'fancy' declaration.
>>>
>>>I think what confuses people learning C is that if you declare two arrays:
>>
>>>int a[10]
>>>int b[10][10]
>>
>>>then a[0] is integer and b[0] is a pointer to integer.
>>
>>It would confuse them, yes. Fortunately it's not true. 
>>b[0] is an array of ten integers.

         > cat main.c
         #include <stdio.h>

         int main(int argc, char* argv[]) {
           int b[10][10];
           printf("%u = sizeof(b[4])\n", sizeof(b[4]));
           return 0;
           }

         > gcc -Wall -std=c99 -pedantic -o main main.c
         > ./main
         40 = sizeof(b[4])

> Which *immediately* decays into ... 
> unless used as the operand of the sizeof or unary & operators.
> This is the confusing bit.

I know what you mean
but "decay" or "decays into" is inaccurate and confusing.
It seems to imply some sort of *spontaneous* reaction
which certainly does *not* occur in properly functioning C programs.
The correct way to think of this is an *implicit conversion*
from a reference to an array to a pointer to it's first element.

Dan Pop <Dan.Pop@cern.ch> scribbled the following:
> In <ca74or$e1m$1@oravannahka.helsinki.fi> Joona I Palaste <palaste@cc.helsinki.fi> writes:
>>JV <n.n@n.com.invalid> scribbled the following:
>>> "Mike Wahler" <mkwahler@mkwahler.net> wrote in message
>>> news:1kyxc.7648$uX2.4414@newsread2.news.pas.earthlink.net...
>>>> What's 'wrong' with using multi-dimensional arrays,
>>>> and what will come to me if I use one?
>>>>
>>>> I won't ask what you consider a 'fancy' declaration.
>>>>
>>> I think what confuses people learning C is that if you declare two arrays:
>>
>>> int a[10]
>>> int b[10][10]
>>
>>> then a[0] is integer and b[0] is a pointer to integer.
>>
>>It would confuse them, yes. Fortunately it's not true. b[0] is an
>>array of ten integers.

> Which *immediately* decays into ... unless used as the operand of the
> sizeof or unary & operators.  This is the confusing bit.

Yes, I agree. It is the same situation with a one-dimensional array, so
arrays of arrays don't have any magical properties.
One way to understand the difference is to think of the raw bytes
comprising the objects. An array is simply several values (ints in
this case) put immediately after each other. Nothing more. There are
no array-specific bits or bytes involved.
A pointer, OTOH, is a value that constitutes the address of another
value. This address value is stored in the object, but the actual
values (ints in this case) it points to can be stored pretty much
anywhere. A pointer definitely has extra pointer-specific bits or
bytes involved - otherwise it wouldn't know where to point.
Arrays can't coincide or overlap each other, any more than normal
values (ints in this case) can. However, several pointers can point
at the same place, or inside each other's defined pointing range.
As usual, I may have been inaccurate at some points. Corrections are
welcome.

-- 
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It's not survival of the fattest, it's survival of the fittest."
   - Ludvig von Drake

"Mike Wahler" <mkwahler@mkwahler.net> wrote in message
> > C doesn't distinguish between a pointer to an area of memory
> > containing a single integer, or an area containing an array of
> > integers.
>
> Actually, yes it does.  The types are not the same (nor need
> their sizes be the same) Also, the types yielded by dereferencing
> those two different type pointers are not the same, nor are their
> sizes -- except in the case of a pointer to an array of one element
> -- that is, their sizes would be the same, but their types still
> would not).
>
Say we want to write a function to return a cursor position. Any C
programmer would write this

void getcursorxy(int *x, int *y)
{
  *x = xposition;
  *y = yposition;
}

Now imagine a function to calculate a correlation coefficient. Again any C
programmer would write

double correlation(int *xvals, int *yvals, int N)

> Pointer to array of 100 ints:
>
> int (*pa)[100];
>
> Pointer to int:
>
> int *p;
>
> Those two types are *not* the same.
>
No, but int *p is not constrained to pointing at a memory object containing
only one integer.

On Wed, 9 Jun 2004 22:00:11 +0100, "Malcolm"
<malcolm@55bank.freeserve.co.uk> wrote:

>
>"Mike Wahler" <mkwahler@mkwahler.net> wrote in message
>> > C doesn't distinguish between a pointer to an area of memory
>> > containing a single integer, or an area containing an array of
>> > integers.
>>
>> Actually, yes it does.  The types are not the same (nor need
>> their sizes be the same) Also, the types yielded by dereferencing
>> those two different type pointers are not the same, nor are their
>> sizes -- except in the case of a pointer to an array of one element
>> -- that is, their sizes would be the same, but their types still
>> would not).
>>
>Say we want to write a function to return a cursor position. Any C
>programmer would write this
>
>void getcursorxy(int *x, int *y)
>{
>  *x = xposition;
>  *y = yposition;
>}
>
>Now imagine a function to calculate a correlation coefficient. Again any C
>programmer would write
>
>double correlation(int *xvals, int *yvals, int N)
>
>> Pointer to array of 100 ints:
>>
>> int (*pa)[100];
>>
>> Pointer to int:
>>
>> int *p;
>>
>> Those two types are *not* the same.
>>
>No, but int *p is not constrained to pointing at a memory object containing
>only one integer.

int *p, when properly initialized, points to a single int by
definition.  The fact that p+1 may also be the address of an int is a
function of the program design and not an inherent property of p.


<<Remove the del for email>>

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

> "Mike Wahler" <mkwahler@mkwahler.net> wrote in message
> > > C doesn't distinguish between a pointer to an area of memory
> > > containing a single integer, or an area containing an array of
> > > integers.
> >
> > Actually, yes it does.  The types are not the same (nor need
> > their sizes be the same) Also, the types yielded by dereferencing
> > those two different type pointers are not the same, nor are their
> > sizes -- except in the case of a pointer to an array of one element
> > -- that is, their sizes would be the same, but their types still
> > would not).
> >
> Say we want to write a function to return a cursor position. Any C
> programmer would write this
> 
> void getcursorxy(int *x, int *y)
> {
>   *x = xposition;
>   *y = yposition;
> }

Erm... I'd almost certainly not write it like that. Even if the global
values would be unavoidable (and I would try to avoid them), I'd be more
likely to write

struct coords getcursorxy()
{
  struct coords t;
 
  t.x=global_x;
  t.y=global_y;

  return t;
}

> Now imagine a function to calculate a correlation coefficient. Again any C
> programmer would write
> 
> double correlation(int *xvals, int *yvals, int N)

Yes, in this case I probably would.

I fail to see the problem, btw. I see your point (that any given int
pointer can point at memory the size of one int, two ints, or a
gazillion ints); but I do not see why this is a problem to you. For any
given function, a pointer can point at
- one object (possibly part of a larger memory area) - in this case, you
  use *ptr, and the rest of the memory, if any, is irrelevant;
- a number of objects, which can be as low as one and as high as the
  sky, or possibly even zero - in which case, you need to pass in the
  number of elements in any case, no matter whether there happens to be
  just one object in this single call or not.

Someone who does not understand this will have problems programming in
C, yes. So what? Let him "program" in HTML; should suit him fine.

> > Pointer to array of 100 ints:
> >
> > int (*pa)[100];
> >
> > Pointer to int:
> >
> > int *p;
> >
> > Those two types are *not* the same.
> >
> No, but int *p is not constrained to pointing at a memory object containing
> only one integer.

Again: so what? If you expect one int, other ints which happen to be
positioned next to your int in memory are irrelevant.
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.

Richard

"Joona I Palaste" <palaste@cc.helsinki.fi> wrote in message
news:ca74or$e1m$1@oravannahka.helsinki.fi...
> JV <n.n@n.com.invalid> scribbled the following:
> > "Mike Wahler" <mkwahler@mkwahler.net> wrote in message
> > news:1kyxc.7648$uX2.4414@newsread2.news.pas.earthlink.net...
> >> What's 'wrong' with using multi-dimensional arrays,
> >> and what will come to me if I use one?
> >>
> >> I won't ask what you consider a 'fancy' declaration.
> >>
> > I think what confuses people learning C is that if you declare two
arrays:
>
> > int a[10]
> > int b[10][10]
>
> > then a[0] is integer and b[0] is a pointer to integer.
>
> It would confuse them, yes. Fortunately it's not true. b[0] is an
> array of ten integers.
>
> --
> /-- Joona Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
> \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
> "The obvious mathematical breakthrough would be development of an easy way
to
> factor large prime numbers."
>    - Bill Gates

Hmm,  it seems that I still have to work on how to present my ideas
clearly:). So lets say that you can use notation b[0] as a pointer to
integer and you can assign   a[0] to integer variable. So you can't tell if
you see expression like a[b] what it actually is without knowing the
declaration.  And I KNOW that arrays are not pointers and still I managed to
get it wrong in my previous post ...
-Jyrki

JV wrote:
> "Joona I Palaste" <palaste@cc.helsinki.fi> wrote in message
>> JV <n.n@n.com.invalid> scribbled the following:
>>> "Mike Wahler" <mkwahler@mkwahler.net> wrote in message
>>>
>>>> What's 'wrong' with using multi-dimensional arrays,
>>>> and what will come to me if I use one?
>>>>
>>>> I won't ask what you consider a 'fancy' declaration.
>>>>
>>> I think what confuses people learning C is that if you declare
>>> two arrays:
>>>
>>> int a[10]
>>> int b[10][10]
>>>
>>> then a[0] is integer and b[0] is a pointer to integer.
>>
>> It would confuse them, yes. Fortunately it's not true. b[0] is
>> an array of ten integers.
> 
> Hmm,  it seems that I still have to work on how to present my
> ideas clearly:). So lets say that you can use notation b[0] as
> a pointer to integer and you can assign   a[0] to integer
> variable. So you can't tell if you see expression like a[b] what
> it actually is without knowing the declaration.  And I KNOW that
> arrays are not pointers and still I managed to get it wrong in
> my previous post ...

You also need to work on your snipping technique and delineation
of your sig (with "-- ").  This has minimal snippage, but compare
it to your actual article.

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

"Malcolm" <malcolm@55bank.freeserve.co.uk> wrote in message
news:ca7tiu$l7o$1@news5.svr.pol.co.uk...
>
> "Mike Wahler" <mkwahler@mkwahler.net> wrote in message
> > > C doesn't distinguish between a pointer to an area of memory
> > > containing a single integer, or an area containing an array of
> > > integers.
> >
> > Actually, yes it does.  The types are not the same (nor need
> > their sizes be the same) Also, the types yielded by dereferencing
> > those two different type pointers are not the same, nor are their
> > sizes -- except in the case of a pointer to an array of one element
> > -- that is, their sizes would be the same, but their types still
> > would not).
> >
> Say we want to write a function to return a cursor position. Any C
> programmer would write this
>
> void getcursorxy(int *x, int *y)
> {
>   *x = xposition;
>   *y = yposition;
> }
>
> Now imagine a function to calculate a correlation coefficient. Again any C
> programmer would write
>
> double correlation(int *xvals, int *yvals, int N)
>
> > Pointer to array of 100 ints:
> >
> > int (*pa)[100];
> >
> > Pointer to int:
> >
> > int *p;
> >
> > Those two types are *not* the same.
> >
> No, but int *p is not constrained to pointing at a memory object
containing
> only one integer.

Thank you for participating in this interview.
We have your resume on file.  Don't call us,
we'll call you.

-Mike

"Joona I Palaste" <palaste@cc.helsinki.fi> wrote in message
news:ca7sd3$nf1$1@oravannahka.helsinki.fi...
> Dan Pop <Dan.Pop@cern.ch> scribbled the following:
> > In <ca74or$e1m$1@oravannahka.helsinki.fi> Joona I Palaste
<palaste@cc.helsinki.fi> writes:
> >>JV <n.n@n.com.invalid> scribbled the following:
> >>> "Mike Wahler" <mkwahler@mkwahler.net> wrote in message
> >>> news:1kyxc.7648$uX2.4414@newsread2.news.pas.earthlink.net...
> >>>> What's 'wrong' with using multi-dimensional arrays,
> >>>> and what will come to me if I use one?
> >>>>
> >>>> I won't ask what you consider a 'fancy' declaration.
> >>>>
> >>> I think what confuses people learning C is that if you declare two
arrays:
> >>
> >>> int a[10]
> >>> int b[10][10]
> >>
> >>> then a[0] is integer and b[0] is a pointer to integer.
> >>
> >>It would confuse them, yes. Fortunately it's not true. b[0] is an
> >>array of ten integers.
>
> > Which *immediately* decays into ... unless used as the operand of the
> > sizeof or unary & operators.  This is the confusing bit.
>
> Yes, I agree. It is the same situation with a one-dimensional array, so
> arrays of arrays don't have any magical properties.
> One way to understand the difference is to think of the raw bytes
> comprising the objects. An array is simply several values (ints in
> this case) put immediately after each other. Nothing more. There are
> no array-specific bits or bytes involved.
> A pointer, OTOH, is a value that constitutes the address of another
> value. This address value is stored in the object, but the actual
> values (ints in this case) it points to can be stored pretty much
> anywhere. A pointer definitely has extra pointer-specific bits or
> bytes involved - otherwise it wouldn't know where to point.
> Arrays can't coincide or overlap each other, any more than normal
> values (ints in this case) can. However, several pointers can point
> at the same place, or inside each other's defined pointing range.
> As usual, I may have been inaccurate at some points. Corrections are
> welcome.

The only thing above I (mildly) object to is this part:

> A pointer, OTOH, is a value that constitutes the address of another
> value. This address value is stored in the object, but the actual
> values ...

I'd change that to:

 A pointer, OTOH, is an object that can represent the address of another
 object. This address value is stored in the pointer object, but the actual
 objects ...

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

-Mike

"JV" <n.n@n.com.invalid> wrote in message
news:pWTxc.18619$k4.372262@news1.nokia.com...

> So you can't tell if
> you see expression like a[b] what it actually is without knowing the
> declaration.

Correct, and this is the case with any statement referring
to an object, array or not.

i = j; /* we need to see declarations of 'i' and 'j' to
          know what they are */

> And I KNOW that arrays are not pointers and still I managed to
> get it wrong in my previous post ...

Yes, slee can be a sippery slubject. :-)

-Mike

Me wrote:

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

At the university I recently graduated from, the professors didn't "teach"
languages.  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.  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.

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?

"Richard Bos" <rlb@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).

If "int *ptr;" were a pointer to an integer, period, then

ptr[100] = x

would be illegal.

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.

-Arthur,
signing off

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.

E. Robert Tisdale wrote:
> Can you give us an example of a value that is *not* an object?

1.  (With or without the decimal point.)

-- 
++acr@,ka"

"Malcolm" <malcolm@55bank.freeserve.co.uk> wrote:
>
>"Richard Bos" <rlb@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).
>
>If "int *ptr;" were a pointer to an integer, period, then
>
>ptr[100] = x
>
>would be illegal.

Since  ptr[100]  is just shorthand for  (*((ptr)+(100))) , why should 
it be illegal?  Array subscripting is plain old pointer arithmetic 
wrapped up in a nice syntactic construct, and it doesn't matter at 
all, if it's performed on a 'genuine' pointer or on one yielded by
'array decay'.  In your example ptr *is* a pointer to an integer - no
more, no less.  Period. 

Regards
-- 
Irrwahn Grausewitz (irrwahn33@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

"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> wrote in message
news:caacgt$89v$1@nntp1.jpl.nasa.gov...
> 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?

Any numeric literal.

-Mike

"Malcolm" <malcolm@55bank.freeserve.co.uk> wrote in message
news:caae6v$hn5$1@newsg1.svr.pol.co.uk...
>
> "Richard Bos" <rlb@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).

That's why we must use 'element count' arguments to functions
which use pointer (to element-type) arguments to process arrays.

Start at first flat, deliver bill, move to next flat, deliver bill.

-Mike

Joe Laughlin wrote:

> Also, there seems to be a shift towards software engineering and away from
> general computer science.  


You're going need to define those two terms for meaningful conversation.




Brian Rodenborn

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

-- 
Alex Monjushko (monjushko@hotmail.com)

Default User wrote:
> Joe Laughlin wrote:
>
>> Also, there seems to be a shift towards software
>> engineering and away from general computer science.
>
>
> You're going need to define those two terms for
> meaningful conversation.
>
>
>
>
> Brian Rodenborn

"general computer science" => theory, algorithms, lower-level stuff
"software engineering" => the process of developing a complex software
system

That's how I understand them anyways.

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.

"E. Robert Tisdale" <E.Robert.Tisdale@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) kst-u@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.

In article <news:2is15uFr1rt4U1@uni-berlin.de>
Alex Monjushko <monjushko@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)  +1 801 277 2603
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" <E.Robert.Tisdale@jpl.nasa.gov> wrote in message
news:caan80$etk$1@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

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.

"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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

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.

In <caaqkl$gsf$1@nntp1.jpl.nasa.gov> "E. Robert Tisdale" <E.Robert.Tisdale@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: Dan.Pop@ifh.de

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:40C8CA85.AC4E757A@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...

"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> wrote in message
news:caaqkl$gsf$1@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

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?

"E. Robert Tisdale" <E.Robert.Tisdale@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) kst-u@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 <E.Robert.Tisdale@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 (monjushko@hotmail.com)

"E. Robert Tisdale" <E.Robert.Tisdale@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) kst-u@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.

"Rufus V. Smith" wrote:
> "CBFalconer" <cbfalconer@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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

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.

Keith Thompson wrote:

[Love it or leave it.]

Religious intolerance?

Keith Thompson wrote:
> "E. Robert Tisdale" <E.Robert.Tisdale@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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

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

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

Kelsey Bjarnason <kelseyb@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 (palaste@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

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.

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

"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> wrote in message
news:cactsn$njd$1@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

"E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> wrote in message
news:cad5hg$rtg$1@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

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

> "Richard Bos" <rlb@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

"Stephen Sprunk" <stephen@sprunk.org> wrote in message news:<3555a16450c46a87534b895d6031722d@news.teranews.com>...
> "E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov> wrote in message
> news:caan80$etk$1@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?

In <a77fc336.0406171356.103510d4@posting.google.com> andygreen@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: Dan.Pop@ifh.de