By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,656 Members | 1,327 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,656 IT Pros & Developers. It's quick & easy.

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

P: n/a
Me

Just a question/observation out of frustration.

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

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

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

int arr[100];

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

int i;

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

char *ch = "string";

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

int (*p)[100];

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

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

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

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

--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Nov 14 '05 #1
Share this Question
Share on Google+
79 Replies


P: n/a
"Me" <bo***@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.
Nov 14 '05 #2

P: n/a
Me


On Tue, 8 Jun 2004 22:30:49 +0100, Malcolm
<ma*****@55bank.freeserve.co.uk> wrote:
"Me" <bo***@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/
Nov 14 '05 #3

P: n/a
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?
Nov 14 '05 #4

P: n/a
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.

Nov 14 '05 #5

P: n/a
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?
Nov 14 '05 #6

P: n/a
"Me" <bo***@bogus.com> wrote in message
news:op**************@danocdhcp011136.americas.nok ia.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/

Nov 14 '05 #7

P: n/a
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.
Nov 14 '05 #8

P: n/a

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:ca**********@news7.svr.pol.co.uk...
"Me" <bo***@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
Nov 14 '05 #9

P: n/a
*a
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
Nov 14 '05 #10

P: n/a
"Kieran Simkin" <ki****@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) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #11

P: n/a
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

Nov 14 '05 #12

P: n/a

"Keith Thompson" <ks***@mib.org> wrote in message news:ln************@nuthaus.mib.org...
"Kieran Simkin" <ki****@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) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Nov 14 '05 #13

P: n/a
In article <ca**********@infosun2.rus.uni-stuttgart.de>,
Michael Mair <ma********************@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.
Nov 14 '05 #14

P: n/a
Michael Mair <ma********************@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

Nov 14 '05 #15

P: n/a
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?

Nov 14 '05 #16

P: n/a
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

Nov 14 '05 #17

P: n/a
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

Nov 14 '05 #18

P: n/a
JV

"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:1k*****************@newsread2.news.pas.earthl ink.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
Nov 14 '05 #19

P: n/a
JV <n.*@n.com.invalid> scribbled the following:
"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:1k*****************@newsread2.news.pas.earthl ink.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 (pa*****@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
Nov 14 '05 #20

P: n/a
In <op**************@danocdhcp011136.americas.nokia.c om> Me <bo***@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: Da*****@ifh.de
Nov 14 '05 #21

P: n/a

"JV" <n.*@n.com.invalid> wrote in message
news:qq*******************@news1.nokia.com...

"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:1k*****************@newsread2.news.pas.earthl ink.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
Nov 14 '05 #22

P: n/a

"Vijay Kumar R Zanvar" <vi*****@globaledgesoft.com> wrote in message
news:2i************@uni-berlin.de...

"Keith Thompson" <ks***@mib.org> wrote in message

news:ln************@nuthaus.mib.org...
"Kieran Simkin" <ki****@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
Nov 14 '05 #23

P: n/a

"*a" <_w___k___@____p_.it> wrote in message
news:Js***********************@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
Nov 14 '05 #24

P: n/a

"Mike Wahler" <mk******@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.
Nov 14 '05 #25

P: n/a

On Wed, 9 Jun 2004, Malcolm wrote:

"Mike Wahler" <mk******@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
Nov 14 '05 #26

P: n/a
In <ca**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
JV <n.*@n.com.invalid> scribbled the following:
"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:1k*****************@newsread2.news.pas.earthl ink.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: Da*****@ifh.de
Nov 14 '05 #27

P: n/a
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:ca**********@news5.svr.pol.co.uk...

"Mike Wahler" <mk******@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

Nov 14 '05 #28

P: n/a
Dan Pop <Da*****@cern.ch> scribbled the following:
In <ca**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
JV <n.*@n.com.invalid> scribbled the following:
"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:1k*****************@newsread2.news.pas.earthl ink.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 (pa*****@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
Nov 14 '05 #29

P: n/a
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.
Nov 14 '05 #30

P: n/a

"Mike Wahler" <mk******@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.

Nov 14 '05 #31

P: n/a
On Wed, 9 Jun 2004 22:00:11 +0100, "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote:

"Mike Wahler" <mk******@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>>
Nov 14 '05 #32

P: n/a
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:
"Mike Wahler" <mk******@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
Nov 14 '05 #33

P: n/a
JV

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:ca**********@oravannahka.helsinki.fi...
JV <n.*@n.com.invalid> scribbled the following:
"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:1k*****************@newsread2.news.pas.earthl ink.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 (pa*****@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
Nov 14 '05 #34

P: n/a
JV wrote:
"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
JV <n.*@n.com.invalid> scribbled the following:
"Mike Wahler" <mk******@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 (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Nov 14 '05 #35

P: n/a

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:ca**********@news5.svr.pol.co.uk...

"Mike Wahler" <mk******@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
Nov 14 '05 #36

P: n/a

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:ca**********@oravannahka.helsinki.fi...
Dan Pop <Da*****@cern.ch> scribbled the following:
In <ca**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
JV <n.*@n.com.invalid> scribbled the following:
"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:1k*****************@newsread2.news.pas.earthl ink.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
Nov 14 '05 #37

P: n/a
"JV" <n.*@n.com.invalid> wrote in message
news:pW*******************@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
Nov 14 '05 #38

P: n/a
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.

Nov 14 '05 #39

P: n/a

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

If I send a letter to you, should I care whether you live in a
detached house or in a flat? Of course not - as long as I have
your correct address, the letter will arrive fine.

But you need to know whether you are sending one gas bill (to the detached
house) or many (to each resident of the block of flats).

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

ptr[100] = x

would be illegal.
Nov 14 '05 #40

P: n/a
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?
Nov 14 '05 #41

P: n/a

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
Nov 14 '05 #42

P: n/a
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"
Nov 14 '05 #43

P: n/a
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

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

If I send a letter to you, should I care whether you live in a
detached house or in a flat? Of course not - as long as I have
your correct address, the letter will arrive fine.

But you need to know whether you are sending one gas bill (to the detached
house) or many (to each resident of the block of flats).

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 (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
Nov 14 '05 #44

P: n/a

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:ca**********@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
Nov 14 '05 #45

P: n/a

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:ca**********@newsg1.svr.pol.co.uk...

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

If I send a letter to you, should I care whether you live in a
detached house or in a flat? Of course not - as long as I have
your correct address, the letter will arrive fine.

But you need to know whether you are sending one gas bill (to the detached
house) or many (to each resident of the block of flats).


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
Nov 14 '05 #46

P: n/a
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.
Nov 14 '05 #47

P: n/a
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
Nov 14 '05 #48

P: n/a
E. Robert Tisdale <E.**************@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 (mo*******@hotmail.com)
Nov 14 '05 #49

P: n/a
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.
Nov 14 '05 #50

79 Replies

This discussion thread is closed

Replies have been disabled for this discussion.