Converting to/from pointer

[Lame Duck]

Hi Group!

I have a vector<floatvariable that I need to pass to a function, but
the function takes a float * arguement. That's OK, I can convert by
doing &MyVector.front(), but when I get back a float * from the
function, how to convert that back to a vector?

Thanks in advance!

[Keith Thompson]

Nick Keighley <ni******************@hotmail.comwrites:
[...]

A recent example. This was proposed (simplified from actual code)

typedef struct
{
size_t size;
unsigned char data[0];
} Msg_t;

That's the "struct hack"; see question 2.6 in the comp.lang.c FAQ,
<http://www.c-faq.com/>. A more nearly portable version uses [1]
rather than [0].

I pointed out this was undefined by the standard and I provided
an example of a compiler that issued a warning of the use of an
extension. I was also curious as what they expected sizeof(Msg_t)
to return.

If you're going to use the struct hack, don't depend on sizeof
yielding anything meaningful.

The proposed fix was:-

typedef struct
{
size_t size;
unsigned char *data;
} Msg_t;

The struct hack has the advantage of keeping the data in one piece --
which is why C99 added flexible array members to replace it.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[osmium]

"Nick Keighley" wrote:

I pointed out at 11

-that Australia is not on the opposite side of the earth from Britain
(I considered New Zealand to be a better answer)

You should fit right in here.

[Default User]

Nick Keighley wrote:

On 4 Jun, 19:02, Johan Bengtsson <[e-mail]:

Mark McIntyre wrote:

Since when did "asking for help" include correcting the advice you
were given? Do you normally correct your teacher?

Perhaps not normally, but sometimes the teacher is wrong (not
implying that it was the case here, just as a general statement). I
have on occasion when I was at school corrected my teacher simply
because he was wrong. It does happen.

I pointed out at 11
-that the moon was not a planet

A fair number of astronomers would consider your "correction" to be
incorrect. Many consider the Earth/Moon system to be a double planet,
based on the relative sizes and proximity of the two bodies.


Brian

[Mark McIntyre]

On Tue, 05 Jun 2007 00:51:48 -0700, in comp.lang.c , Nick Keighley
<ni******************@hotmail.comwrote:

>On 4 Jun, 19:02, Johan Bengtsson <[e-mail]:

>Mark McIntyre wrote:

Since when did "asking for help" include correcting the advice you
were given? Do you normally correct your teacher?

Perhaps not normally, but sometimes the teacher is wrong (not implying
that it was the case here, just as a general statement). I have on
occasion when I was at school corrected my teacher simply because he was
wrong. It does happen.

I pointed out at 11
-that the moon was not a planet
-that Australia is not on the opposite side of the earth from Britain
(I considered New Zealand to be a better answer)

Regarding the latter, you were incorrect. Both NZ and Aus are on the
"opposite side" since they're more than 90degs away round a great
circle... :-)
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Old Wolf]

Nick Keighley <[e-mail]:

-that Australia is not on the opposite side of the earth from
Britain

If 'side of the earth' means half of the surface,
then Australia certainly is on the opposite side
to Britain.

(I considered New Zealand to be a better answer)

NZ is directly opposite Spain. The southernmost
part of NZ is 47 deg South (not including
small uninhabited offshore islands), whereas London
is 51 deg North.

Australia is directly opposite the North Atlantic;
I don't think it overlaps any major land mass.

[Richard Tobin]

In article <11**********************@i38g2000prf.googlegroups .com>,
Old Wolf <ol*****@inspire.net.nzwrote:

>-that Australia is not on the opposite side of the earth from
Britain

>If 'side of the earth' means half of the surface,
then Australia certainly is on the opposite side
to Britain.

But that's not how it's usually interpreted; if it was, the Philipines
and Falklands would also be on the opposite side of the earth from
Britain.

It is interesting to see how little land there is on the hemisphere
centred on the antipodes of London:

http://www.garwood-voigt.com/catalog...uthThomson.jpg

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[CBFalconer]

Fr************@googlemail.com wrote:

>

.... snip ...

>
I think that thinking of a block returned by malloc as a dynamically-
allocated array, even while not literally true since we all know that
array is a precisely-defined concept in C, is absolutely the right
thing to do. Pushing this one step further, identifying an ordered
collection of m vectors of length n with an m x n matrix (i.e. 2-
dimensional array) is equally sound conceptually.

How many times do we have to tell you - C does not have vectors.
Please observe the follow-up and cease cross-posting to c.l.c and
c.l.c++.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Mark McIntyre wrote:

Richard <rg****@gmail.comwrote:

.... snip ...

>

>This is a help group. People pop in for help and leave.

Since when did "asking for help" include correcting the advice you
were given? Do you normally correct your teacher?

Yes. Obviously one of us is mistaken, and it is high time to work
out who that is and why. At least one of us will learn something.
Normally it will be me.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Malcolm McLean wrote:

>

.... snip ...

>
<RANT>
Except to Microsoft's new platform. They have broken my entire
code base.
</RANT>

So don't use it. See the links below also.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Fr************@googlemail.com wrote:

>>

... snip ...

>>
I think that thinking of a block returned by malloc as a dynamically-
allocated array, even while not literally true since we all know that
array is a precisely-defined concept in C, is absolutely the right
thing to do. Pushing this one step further, identifying an ordered
collection of m vectors of length n with an m x n matrix (i.e. 2-
dimensional array) is equally sound conceptually.

How many times do we have to tell you - C does not have vectors.
Please observe the follow-up and cease cross-posting to c.l.c and
c.l.c++.

Though this thread started with a question about C++ vectors, I don't
believe Francine was using the word in that sense.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Francine.Neary]

On Jun 6, 3:09 am, Keith Thompson <[e-mail]:

CBFalconer <[e-mail]:

[e-mail] wrote:

... snip ...

I think that thinking of a block returned by malloc as a dynamically-
allocated array, even while not literally true since we all know that
array is a precisely-defined concept in C, is absolutely the right
thing to do. Pushing this one step further, identifying an ordered
collection of m vectors of length n with an m x n matrix (i.e. 2-
dimensional array) is equally sound conceptually.

How many times do we have to tell you - C does not have vectors.
Please observe the follow-up and cease cross-posting to c.l.c and
c.l.c++.

Though this thread started with a question about C++ vectors, I don't
believe Francine was using the word in that sense.

Certainly not! In context I see why the word was an unfortunate choice
- to be honest this thread has gotten so far out of control that I'd
forgotten its murky origins :)

Let's try to analyze my abuses of language...

I think that thinking of a block returned by malloc as a dynamically-
allocated array, even while not literally true since we all know that
array is a precisely-defined concept in C, is absolutely the right
thing to do.

At this stage, I'm using "array" to cover two different concepts: a
bona fide C array, and a block of memory dynamically allocated by
malloc, which we can think of conceptually as an array even though it
isn't an array as far as C is concerned, and we need to be careful not
to burn our fingers with sizeof etc.

Pushing this one step further, identifying an ordered

collection of m vectors of length n with an m x n matrix (i.e. 2-
dimensional array) is equally sound conceptually.

Here we need to distinguish between 1-dimensional arrays and 2-
dimensional arrays, where some linguistic tangles are helpful... I
intended vector to be a synonym for array, where array has the loose
sense of the previous paragraph, and matrix to mean "2-dimensional
array, which is an array (in the loose sense above) of vectors (in the
sense just defined)". Of course, you could also take a matrix (in this
sense) to be a single array (in the loose sense above) and keep track
yourself of rows and columns in a single index.

--
Keith Thompson (The_Other_Keith) [e-mail] <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Nick Keighley]

On 5 Jun, 10:03, Keith Thompson <[e-mail]:

Nick Keighley<[e-mail]:

A recent example [of problems arising from assuming an array
is a pointer]. This was proposed (simplified from actual code)

typedef struct
{
size_t size;
unsigned char data[0];
} Msg_t;

That's the "struct hack"; see question 2.6 in the comp.lang.c FAQ,
<http://www.c-faq.com/>. A more nearly portable version uses [1]
rather than [0].

yes, I know. That was what I proposed.

I pointed out this was undefined by the standard and I provided
an example of a compiler that issued a warning of the use of an
extension. I was also curious as what they expected sizeof(Msg_t)
to return.

If you're going to use the struct hack, don't depend on sizeof
yielding anything meaningful.

um. Well sizeof(Msg_t) yields something meaningful. Somehow you have
to work out what value to supply to malloc().

The proposed fix was:-

typedef struct
{
size_t size;
unsigned char *data;
} Msg_t;

The struct hack has the advantage of keeping the data in one piece --
which is why C99 added flexible array members to replace it.

my point was that the person who proposed this thought two versions
were
equivalent. Because "arrays are the same as pointers".
--
Nick Keighley

Your colleagues have been successfully briefed for years on
the progress of Special Projects without their ever having
any idea what they actually are.

[CBFalconer]

Fr************@googlemail.com wrote:

>

.... snip ...

>
At this stage, I'm using "array" to cover two different concepts:
a bona fide C array, and a block of memory dynamically allocated
by malloc, which we can think of conceptually as an array even
though it isn't an array as far as C is concerned, and we need to
be careful not to burn our fingers with sizeof etc.

Ah, but they both are (or can be) arrays. Just to make things
murkier. You may need to maintain a separate 'size' variable. :-)

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Mark McIntyre]

On Mon, 04 Jun 2007 19:14:02 -0400, in comp.lang.c , CBFalconer
<cb********@yahoo.comwrote:

>Mark McIntyre wrote:

>Richard <rg****@gmail.comwrote:

... snip ...

>>

>>This is a help group. People pop in for help and leave.

Since when did "asking for help" include correcting the advice you
were given? Do you normally correct your teacher?

Yes. Obviously one of us is mistaken, and it is high time to work
out who that is and why.

Thank heavens for someone posting a sensible answer to the question...

>At least one of us will learn something.
Normally it will be me.

:-)
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On 5 Jun 2007 23:44:34 GMT, in comp.lang.c , ri*****@cogsci.ed.ac.uk
(Richard Tobin) wrote:

>In article <11**********************@i38g2000prf.googlegroups .com>,
Old Wolf <ol*****@inspire.net.nzwrote:

>>-that Australia is not on the opposite side of the earth from
Britain

>>If 'side of the earth' means half of the surface,
then Australia certainly is on the opposite side
to Britain.

But that's not how it's usually interpreted;

I disagree. In most of the UK "The other side of the earth" is taken
to mean just that.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Richard Tobin]

In article <05********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:

>>>-that Australia is not on the opposite side of the earth from
Britain

>>>If 'side of the earth' means half of the surface,
then Australia certainly is on the opposite side
to Britain.

>>But that's not how it's usually interpreted;

>I disagree. In most of the UK "The other side of the earth" is taken
to mean just that.

The word was "opposite", not "other".

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Mark McIntyre]

On 6 Jun 2007 22:08:46 GMT, in comp.lang.c , ri*****@cogsci.ed.ac.uk
(Richard Tobin) wrote:

>In article <05********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:

>>>>-that Australia is not on the opposite side of the earth from
Britain

>>>>If 'side of the earth' means half of the surface,
then Australia certainly is on the opposite side
to Britain.

>>>But that's not how it's usually interpreted;

>>I disagree. In most of the UK "The other side of the earth" is taken
to mean just that.

The word was "opposite", not "other".

Same response.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Malcolm McLean]

<Fr************@googlemail.comwrote in message
news:11**********************@w5g2000hsg.googlegro ups.com...

On Jun 6, 3:09 am, Keith Thompson <[e-mail]:

>CBFalconer <[e-mail]:

[e-mail] wrote:

... snip ...

>I think that thinking of a block returned by malloc as a dynamically-
allocated array, even while not literally true since we all know that
array is a precisely-defined concept in C, is absolutely the right
thing to do. Pushing this one step further, identifying an ordered
collection of m vectors of length n with an m x n matrix (i.e. 2-
dimensional array) is equally sound conceptually.

How many times do we have to tell you - C does not have vectors.
Please observe the follow-up and cease cross-posting to c.l.c and
c.l.c++.

Though this thread started with a question about C++ vectors, I don't
believe Francine was using the word in that sense.

Certainly not! In context I see why the word was an unfortunate choice
- to be honest this thread has gotten so far out of control that I'd
forgotten its murky origins :)

No. Obviously we cannot reserve the word "vector" for a particular C++
standard template library object.. It has got a perfectly acceptable meaning
as the opposite of a scalar.

Some regs seem to fall over this point quite frequently. Programming
languages are quite new and do grab certain words for special meanings.
However there is no point trying to avoid those words in other contexts, as
in my distinction between a "function", which calculates something, and a
"procedure" which does something. Unfortunately the C convention is to call
all subroutines "functions", but that is C stretching the English language,
not me.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Charlton Wilbur]

>>>>"MML" == Malcolm McLean <re*******@btinternet.comwrites:

MMLIn this case the instructor is probably simplifying for
MMLpedagogical purposes. You have to do that.

Yes, but you must do it *responsibly.* You don't say "arrays and
pointers are the same thing"; you say "arrays and pointers are alike
in a lot of ways." It is substantially more difficult to unlearn
something wrong and relearn it correctly than it is to learn correctly
in the first place; any pedagogue who thinks he's doing the students a
favor by teaching them things that are oversimplified ought to be sued
for malpractice.

Charlton
--
Charlton Wilbur
cw*****@chromatico.net

[Johan Bengtsson]

Keith Thompson wrote:

The truth about arrays and pointers *isn't that hard to understand*.
It's only difficult because some instructors try to "simplify" it.

My standard response to anyone who's confused about this is:

Arrays are not pointers. Pointers are not arrays. Read section 6
of the comp.lang.c FAQ, <http://www.c-faq.com>.

Is that really so difficult that it's necessary to lie to students?

Some teachers are too stupid to understand this themself. Not
necessarily implying that this is the case here.

[James Kanze]

On Jun 7, 10:31 pm, Charlton Wilbur <[e-mail]:

>>>"MML" == Malcolm McLean <[e-mail]:

MMLIn this case the instructor is probably simplifying for
MMLpedagogical purposes. You have to do that.

Yes, but you must do it *responsibly.* You don't say "arrays and
pointers are the same thing"; you say "arrays and pointers are alike
in a lot of ways."

You don't even say that, because it's just as wrong. Arrays and
pointers are not even vaguely alike. The only relationship is
that an array will implicitly convert to pointer in certain
circumstances (all of which are in an expression---outside of an
expression, there is no relationship whatsoever).

Note that in order to use an array or a pointer in an
expression, you must first declare or define one. In other
words, you must be able to use them in a context where they are
not at all related before using them in a context where the
implicit conversion creates an appearance of similarity.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Army1987]

"Johan Bengtsson" <qw*******@hotmail.comha scritto nel messaggio
news:Ys***************@newsb.telia.net...

Mark McIntyre wrote:

>Since when did "asking for help" include correcting the advice you
were given? Do you normally correct your teacher?

Perhaps not normally, but sometimes the teacher is wrong (not implying
that it was the case here, just as a general statement). I have on
occasion when I was at school corrected my teacher simply because he was
wrong. It does happen.

And usually the teacher answers "I did it on purpose, I wanted to
check wheter you were paying enough attention"... :-)

[Army1987]

"Default User" <de***********@yahoo.comha scritto nel messaggio
news:5c*************@mid.individual.net...

Nick Keighley wrote:

>On 4 Jun, 19:02, Johan Bengtsson <[e-mail]:

Mark McIntyre wrote:
Since when did "asking for help" include correcting the advice you
were given? Do you normally correct your teacher?

Perhaps not normally, but sometimes the teacher is wrong (not
implying that it was the case here, just as a general statement). I
have on occasion when I was at school corrected my teacher simply
because he was wrong. It does happen.

I pointed out at 11
-that the moon was not a planet

A fair number of astronomers would consider your "correction" to be
incorrect. Many consider the Earth/Moon system to be a double planet,
based on the relative sizes and proximity of the two bodies.

But the center of mass of the system is well below Earth's
surface...

[Army1987]

"Richard Tobin" <ri*****@cogsci.ed.ac.ukha scritto nel messaggio
news:f4***********@pc-news.cogsci.ed.ac.uk...

In article <11**********************@i38g2000prf.googlegroups .com>,
Old Wolf <ol*****@inspire.net.nzwrote:

>>-that Australia is not on the opposite side of the earth from
Britain

>>If 'side of the earth' means half of the surface,
then Australia certainly is on the opposite side
to Britain.

But that's not how it's usually interpreted; if it was, the Philipines
and Falklands would also be on the opposite side of the earth from
Britain.

It is interesting to see how little land there is on the hemisphere
centred on the antipodes of London:

http://www.garwood-voigt.com/catalog...uthThomson.jpg

see also http://en.wikipedia.org/wiki/Image:W...hAntipodes.png

[Army1987]

"Malcolm McLean" <re*******@btinternet.comha scritto nel messaggio
news:nb******************************@bt.com...

>
"Richard Tobin" <ri*****@cogsci.ed.ac.ukwrote in message
news:f4**********@pc-news.cogsci.ed.ac.uk...

>In article <Qt*********************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>>Nevertheless, either he was mistaken or you misunderstood him. No matter
what his expertise, the language specification always trumps an
instructor.

Only if your aim is to have a comprehensive graps of the details of C.
I don't know what kind of class the poster was taking, but that aim
should be rather low on the list of priorities for a university
course.

In this case the instructor is probably simplifying for pedagogical
purposes. You have to do that. You don't throw quantum physics at nine
year olds, but you can show them models made out of balls and sticks. One
problem is that they often get the idea that atoms are coloured. However
that's better than thinking that atoms are something that only clever
people can know anything about.

"An array always evalues ("decays") to a constant pointer to its
first element, except as the operand of sizeof or of the unary &.
For example, given:
int arr[100];
int * const ptr = &arr[0];
Every expression containing arr will have the same identical value
that it would have if arr were replaced with ptr, unless arr is
used as the operand of & or sizeof."

Too complicated for students? If so, you'd better teach those
students some other language.

[Army1987]

"Barry Schwarz" <sc******@doezl.netha scritto nel messaggio
news:38********************************@4ax.com...

On Mon, 4 Jun 2007 18:54:57 -0700, Clark Cox <cl*******@gmail.com>
wrote:

>>On 2007-06-04 17:00:59 -0700, "Malcolm McLean" <re*******@btinternet.com>
said:

snip

>>Then finally the syntax for passing a 2D array to a function is too
complex.

It's not complex, it's non-existent. Functions cannot accept arrays as
parameters.

Of course they can. Or are you referring to the fact that the
argument evaluates to a pointer so the function never really sees it
as an array (but nevertheless has no trouble treating it as an array)?

And the syntax is only two characters more complex than passing a 1D
array.

void func(int[][N], int);
int array[M][N] = {...};
func(array, M);

Only if N is a compile-time constant.

[Army1987]

"Barry Schwarz" <sc******@doezl.netha scritto nel messaggio
news:tm********************************@4ax.com...

On Sun, 3 Jun 2007 17:09:08 +0200, "Army1987" <pl********@for.it>
wrote:

>>
"Lame Duck" <no****@nospam.comha scritto nel messaggio
news:sl*******************@nospam.com...

>>No, a pointer to a float is the same as an array of float.

#include <stdio.h>
int main(void)
{
float array[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
float *pointer = array;

printf("%lu %lu\n", sizeof array, sizeof pointer);

It would be better to cast the last two arguments so someone whose
system did not #define size_t as unsigned long would not invoke
undefined behavior.

Yes, I've forgotten to do that. (But on my system size_t is
unsigned long, so my point still holds.)

>

> return 0;
}

Displays "40 4" on my system. So? They're the same but one is ten times
bigger? :-)

At least now we know what the original poster meant by superset.
Remove del for email

[anon]

Richard Heathfield wrote:

James Kanze said:

>On Jun 3, 1:00 am, Mark McIntyre <[e-mail]:

>>On Sun, 03 Jun 2007 00:07:36 +0200, in comp.lang.c , Richard
<[e-mail]:

>>>>I find it hilarious that you feel the need to tell Richard
Heathfield that. (hint, he knows full well what happens)
Why? The poster, while wrong, doesn't know who or what Richard
Heathfield is.
True, but if they had followed usenet etiquette and lurked,

It depends. The original poster apparently cross-posted

<snip>

>You can lurk for a long time in clc++, and not know who Richard
Heathfield is.

Strange but true.

So, who is Richard Heathfield???

[Richard Heathfield]

anon said:

Richard Heathfield wrote:

>James Kanze said:

>>You can lurk for a long time in clc++, and not know who Richard
Heathfield is.

Strange but true.

So, who is Richard Heathfield???

No idea. Try asking in alt.fan.heathfield

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

"Army1987" <pl********@for.itwrites:
[...]

"An array always evalues ("decays") to a constant pointer to its
first element, except as the operand of sizeof or of the unary &.
For example, given:
int arr[100];
int * const ptr = &arr[0];
Every expression containing arr will have the same identical value
that it would have if arr were replaced with ptr, unless arr is
used as the operand of & or sizeof."

Too complicated for students? If so, you'd better teach those
students some other language.

You forgot one case: a string literal used to initialize an array
doesn't decay to a pointer.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[James Kanze]

On Jun 8, 9:28 pm, Keith Thompson <[e-mail]:

"Army1987" <[e-mail]:

[...]

"An array always evalues ("decays") to a constant pointer to its
first element, except as the operand of sizeof or of the unary &.
For example, given:
int arr[100];
int * const ptr = &arr[0];
Every expression containing arr will have the same identical value
that it would have if arr were replaced with ptr, unless arr is
used as the operand of & or sizeof."

Too complicated for students? If so, you'd better teach those
students some other language.

You forgot one case: a string literal used to initialize an array
doesn't decay to a pointer.

Sort of. He did say "evalues". Maybe (probably?) he meant by
that "when used in an expression". After all, the first use of
arr in his example doesn't decay to a constant pointer; "int
arr[100]" is a very different beast than "int *const arr;". And
initialization of an array of char with a string literal is
arguably a special case, where the initializer is not an
expression (although that's not quite the way I'd explain it).

Anyway, my point is that you can't talk about arrays and
pointers in expressions without first talking about declaring
them, so you have to start with their being different things;
you can't avoid it.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Malcolm McLean]

"Army1987" <pl********@for.itwrote in message
news:f4**********@tdi.cu.mi.it...

>
"An array always evalues ("decays") to a constant pointer to its
first element, except as the operand of sizeof or of the unary &.
For example, given:
int arr[100];
int * const ptr = &arr[0];
Every expression containing arr will have the same identical value
that it would have if arr were replaced with ptr, unless arr is
used as the operand of & or sizeof."

Too complicated for students? If so, you'd better teach those
students some other language.

The students are just learning what the terms "array" and "pointer" mean.
Then you are throwing "operand", sizeof, and "unary &" at them.
It is a classic case of defining something rather than explaining it.

The better students will of course learn despite poor teaching. The problem
is that the marginal ones may decide that C is not for them, when in fact it
could have been a useful skill not too hard to acquire.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Johan Bengtsson]

Army1987 wrote:

"Johan Bengtsson" <qw*******@hotmail.comha scritto nel messaggio
news:Ys***************@newsb.telia.net...

>Mark McIntyre wrote:

>>Since when did "asking for help" include correcting the advice you
were given? Do you normally correct your teacher?

Perhaps not normally, but sometimes the teacher is wrong (not implying
that it was the case here, just as a general statement). I have on
occasion when I was at school corrected my teacher simply because he was
wrong. It does happen.

And usually the teacher answers "I did it on purpose, I wanted to
check wheter you were paying enough attention"... :-)

I have used that answer myself ocassionaly (as a teacher obviously) at
in some cases it was true, in some cases it was not true and in yet some
cases (actually more of those) I have admitted that I did wrong.

That answer is usually not satisfactory however when a test is judged
wrong and I actually had to physically prove my solution right before it
was accepted. - That was one of the cases when it happened to me at
school that I still remember clearly. (A physics test concerning how a
NPN transistor works)

[Johan Bengtsson]

Richard Heathfield wrote:

anon said:

>Richard Heathfield wrote:
So, who is Richard Heathfield???

No idea. Try asking in alt.fan.heathfield

I cant find any newsgroup with that name!

[Richard Heathfield]

Johan Bengtsson said:

Richard Heathfield wrote:

>anon said:

>>Richard Heathfield wrote:
So, who is Richard Heathfield???

No idea. Try asking in alt.fan.heathfield

I cant find any newsgroup with that name!

So start one. It's long overdue.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Clark Cox]

On 2007-06-08 15:31:04 -0700, James Kanze <ja*********@gmail.comsaid:

On Jun 8, 9:28 pm, Keith Thompson <[e-mail]:

>"Army1987" <[e-mail]:

>[...]

>>"An array always evalues ("decays") to a constant pointer to its
first element, except as the operand of sizeof or of the unary &.
For example, given:
int arr[100];
int * const ptr = &arr[0];
Every expression containing arr will have the same identical value
that it would have if arr were replaced with ptr, unless arr is
used as the operand of & or sizeof."

>>Too complicated for students? If so, you'd better teach those
students some other language.

>You forgot one case: a string literal used to initialize an array
doesn't decay to a pointer.

Sort of. He did say "evalues". Maybe (probably?) he meant by
that "when used in an expression".

The right side of the equals sign in an initialization *is* an
expression; and it *is* evaluated.

After all, the first use of
arr in his example doesn't decay to a constant pointer; "int
arr[100]" is a very different beast than "int *const arr;". And
initialization of an array of char with a string literal is
arguably a special case, where the initializer is not an
expression (although that's not quite the way I'd explain it).

How is it not an expression? And if it isn't an expression, then what is it?

C:
From 6.5.1 4:
"A string literal is a primary expression."

C++
From [expr.prim] 2:
"A literal is a primary expression. Its type depends on its form
(2.13). A string literal is an lvalue; all other
literals are rvalues."

Seems pretty clear to me in both languages.

--
Clark S. Cox III
cl*******@gmail.com

[Flash Gordon]

Malcolm McLean wrote, On 09/06/07 08:54:

>
"Army1987" <pl********@for.itwrote in message
news:f4**********@tdi.cu.mi.it...

>>
"An array always evalues ("decays") to a constant pointer to its
first element, except as the operand of sizeof or of the unary &.
For example, given:
int arr[100];
int * const ptr = &arr[0];
Every expression containing arr will have the same identical value
that it would have if arr were replaced with ptr, unless arr is
used as the operand of & or sizeof."

Too complicated for students? If so, you'd better teach those
students some other language.

The students are just learning what the terms "array" and "pointer"
mean. Then you are throwing "operand", sizeof, and "unary &" at them.

If you have not explained what an operand is before getting on to arrays
and pointers then you are doing something VERY wrong. sizeof can easily
be explained prior to doing arrays and pointers, it is not difficult.
Then you just have the unary & to explain when starting on pointers
which is not exactly difficult.

It is a classic case of defining something rather than explaining it.

The better students will of course learn despite poor teaching. The
problem is that the marginal ones may decide that C is not for them,
when in fact it could have been a useful skill not too hard to acquire.

I'm not sure whether you are in favour of claiming that arrays and
pointers are very similar or not, only that you don't favour explaining
arrays decaying to pointers at the start of explaining arrays and pointer.

Personally I would explain arrays and pointers completely separately and
only go on to arrays decaying to pointers once arrays and pointers are
understood.
--
Flash Gordon

[Army1987]

"James Kanze" <ja*********@gmail.comha scritto nel messaggio
news:11*********************@p77g2000hsh.googlegro ups.com...
On Jun 8, 9:28 pm, Keith Thompson <[e-mail]:

"Army1987" <[e-mail]:

[...]

"An array always evalues ("decays") to a constant pointer to its
first element, except as the operand of sizeof or of the unary &.
For example, given:
int arr[100];
int * const ptr = &arr[0];
Every expression containing arr will have the same identical value
that it would have if arr were replaced with ptr, unless arr is
used as the operand of & or sizeof."

Too complicated for students? If so, you'd better teach those
students some other language.

You forgot one case: a string literal used to initialize an array
doesn't decay to a pointer.

Sort of. He did say "evalues". Maybe (probably?) he meant by
that "when used in an expression".

Yeah. I meant that. Obviously an array doesn't decay to anything
when it is not used at all, but I forgot about the way an array can
be "used" other than within an expression (i.e. in a declaration).
And the syntax says
initializer:
assignment-expression
{ initializer-list }
{ initializer-list , }
expression:
assignment-expression
expression , assignment-expression
so a string literal used to initialize an array *is* an expression,
so it *is* an exception to "an array within an expression decays to
a pointer to its beginning" which I did forget to mention.

[Army1987]

"Malcolm McLean" <re*******@btinternet.comha scritto nel messaggio
news:GY******************************@bt.com...

>
"Army1987" <pl********@for.itwrote in message
news:f4**********@tdi.cu.mi.it...

>>
"An array always evalues ("decays") to a constant pointer to its
first element, except as the operand of sizeof or of the unary &.
For example, given:
int arr[100];
int * const ptr = &arr[0];
Every expression containing arr will have the same identical value
that it would have if arr were replaced with ptr, unless arr is
used as the operand of & or sizeof."

Too complicated for students? If so, you'd better teach those
students some other language.

The students are just learning what the terms "array" and "pointer" mean.
Then you are throwing "operand", sizeof, and "unary &" at them.
It is a classic case of defining something rather than explaining it.

The better students will of course learn despite poor teaching. The
problem is that the marginal ones may decide that C is not for them, when
in fact it could have been a useful skill not too hard to acquire.

So: first I'd teach them what an array is and how to use it, telling that
they can't assign to an array or compare two arrays with ==. Then (maybe
even weeks later) I'd explain them what a pointer is, including what & does.
Then I would tell them about the
fact that arrays decay into pointers as above.

[pete]

Army1987 wrote:

So: first I'd teach them what an array is and how to use it,
telling that
they can't assign to an array or compare two arrays with ==.
Then (maybe even weeks later)
I'd explain them what a pointer is, including what & does.
Then I would tell them about the
fact that arrays decay into pointers as above.

I don't know much about pedagogy,
but I think that before that, I would teach that
sizeof((char)0 + (char)0 + (char)0) equals sizeof(int).

--
pete

[Malcolm McLean]

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:9e************@news.flash-gordon.me.uk...

Malcolm McLean wrote, On 09/06/07 08:54:

>>
"Army1987" <pl********@for.itwrote in message
news:f4**********@tdi.cu.mi.it...

>>>
"An array always evalues ("decays") to a constant pointer to its
first element, except as the operand of sizeof or of the unary &.
For example, given:
int arr[100];
int * const ptr = &arr[0];
Every expression containing arr will have the same identical value
that it would have if arr were replaced with ptr, unless arr is
used as the operand of & or sizeof."

Too complicated for students? If so, you'd better teach those
students some other language.

The students are just learning what the terms "array" and "pointer" mean.
Then you are throwing "operand", sizeof, and "unary &" at them.

If you have not explained what an operand is before getting on to arrays
and pointers then you are doing something VERY wrong. sizeof can easily be
explained prior to doing arrays and pointers, it is not difficult. Then
you just have the unary & to explain when starting on pointers which is
not exactly difficult.

>It is a classic case of defining something rather than explaining it.

The better students will of course learn despite poor teaching. The
problem is that the marginal ones may decide that C is not for them, when
in fact it could have been a useful skill not too hard to acquire.

I'm not sure whether you are in favour of claiming that arrays and
pointers are very similar or not, only that you don't favour explaining
arrays decaying to pointers at the start of explaining arrays and pointer.

Personally I would explain arrays and pointers completely separately and
only go on to arrays decaying to pointers once arrays and pointers are
understood.

One problem is that when we take this example

int x;
int *ptr = &x;

it is quite hard to explain the advantage of the operation.

Pointers don't actually make much sense until you've got a reasonable amount
of code. Then the increment rule is so fundamental that really you must
introduce pointers to arrays very quickly.

So it should be arrays, then function calls, and then pointers and how to
pass arrays to functions. sizeof() doesn't make much sense outside of a
pointer context. Introduce when you come to malloc(), which has to be after
pointers to arrays are mastered.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[CBFalconer]

pete wrote:

Army1987 wrote:

>So: first I'd teach them what an array is and how to use it,
telling that they can't assign to an array or compare two arrays
with ==. Then (maybe even weeks later) I'd explain them what a
pointer is, including what & does. Then I would tell them about
the fact that arrays decay into pointers as above.

I don't know much about pedagogy,
but I think that before that, I would teach that
sizeof((char)0 + (char)0 + (char)0) equals sizeof(int).

I believe you are wrong here, in that the number of terms in the
expression doesn't matter, provided there is at least one term.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[peter koch]

On 9 Jun., 19:28, CBFalconer <[e-mail]:

pete wrote:

Army1987 wrote:

So: first I'd teach them what an array is and how to use it,
telling that they can't assign to an array or compare two arrays
with ==. Then (maybe even weeks later) I'd explain them what a
pointer is, including what & does. Then I would tell them about
the fact that arrays decay into pointers as above.

I don't know much about pedagogy,
but I think that before that, I would teach that
sizeof((char)0 + (char)0 + (char)0) equals sizeof(int).

I believe you are wrong here, in that the number of terms in the
expression doesn't matter, provided there is at least one term.

I believe that the poster wanted to tell about the difference between
C and C++ wrt. sizeof('a').

/Peter

[Harald van =?UTF-8?B?RMSzaw==?=]

CBFalconer wrote:

pete wrote:

>Army1987 wrote:

>>So: first I'd teach them what an array is and how to use it,
telling that they can't assign to an array or compare two arrays
with ==. Then (maybe even weeks later) I'd explain them what a
pointer is, including what & does. Then I would tell them about
the fact that arrays decay into pointers as above.

I don't know much about pedagogy,
but I think that before that, I would teach that
sizeof((char)0 + (char)0 + (char)0) equals sizeof(int).

I believe you are wrong here, in that the number of terms in the
expression doesn't matter, provided there is at least one term.

If there is exactly one term, the usual arithmetic conversions aren't
necessarily performed. If there are multiple terms, they are.

sizeof((char)0) is always 1, because if there is exactly one term, such as
(char)0 here, it does not get promoted. sizeof((char)0 + (char)0) is always
sizeof(int), because the integer promotions are applied to both terms.

[Keith Thompson]

Clark Cox <cl*******@gmail.comwrites:
[...]

The right side of the equals sign in an initialization *is* an
expression; and it *is* evaluated.

It's not an expression if it's enclosed in curly braces; for example:

struct foo obj = { 10, 20 };

That doesn't contradict your main point, though.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

"Malcolm McLean" <re*******@btinternet.comwrites:
[...]

One problem is that when we take this example

int x;
int *ptr = &x;

it is quite hard to explain the advantage of the operation.

I'm not convinced that the student has to understand why each concept
is useful at the time that it's presented. The "hello, world" program
isn't particularly useful by itself; I think most students can
understand that it's leading to something else.

Pointers don't actually make much sense until you've got a reasonable
amount of code. Then the increment rule is so fundamental that really
you must introduce pointers to arrays very quickly.

I assume you're referring to the fact that an array can be accessed
via a pointer to its first element. Actual pointers to arrays are
rarely useful.

So it should be arrays, then function calls, and then pointers and how
to pass arrays to functions. sizeof() doesn't make much sense outside
of a pointer context.

sizeof makes perfect sense; it yields the size in bytes of its
argument. The *usefulness* of sizeof isn't quite as obvious.

Introduce when you come to malloc(), which has
to be after pointers to arrays are mastered.

Pointers to structures can be used to build linked lists and other
dynamic data structures. (I'm not sure that such things should be
introduced before arrays, though.)

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

peter koch <pe***************@gmail.comwrites:

On 9 Jun., 19:28, CBFalconer <[e-mail]:

>pete wrote:

Army1987 wrote:
So: first I'd teach them what an array is and how to use it,
telling that they can't assign to an array or compare two arrays
with ==. Then (maybe even weeks later) I'd explain them what a
pointer is, including what & does. Then I would tell them about
the fact that arrays decay into pointers as above.

I don't know much about pedagogy,
but I think that before that, I would teach that
sizeof((char)0 + (char)0 + (char)0) equals sizeof(int).

I believe you are wrong here, in that the number of terms in the
expression doesn't matter, provided there is at least one term.

I believe that the poster wanted to tell about the difference between
C and C++ wrt. sizeof('a').

I believe both of you missed the point.

pete's statement that

sizeof((char)0 + (char)0 + (char)0) equals sizeof(int)

is correct in both C and C++. (char)0 is of type char, but it's
promoted to int when used in an expression. (It could be promoted to
unsigned int in some exotic implementations, but sizeof(unsigned int)
== sizeof(int), so that wouldn't affect the truth of the statement.)

It's true that C and C++ treat character constants differently, but
there are no character constants in pete's code.

What *I'm* missing is why pete thinks this particular odd fact should
be taught before teaching arrays and pointers.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[pete]

Keith Thompson wrote:

>
peter koch <pe***************@gmail.comwrites:

On 9 Jun., 19:28, CBFalconer <[e-mail]:

pete wrote:
Army1987 wrote:
So: first I'd teach them what an array is and how to use it,
telling that they can't assign to an array or compare two arrays
with ==. Then (maybe even weeks later) I'd explain them what a
pointer is, including what & does. Then I would tell them about
the fact that arrays decay into pointers as above.

I don't know much about pedagogy,
but I think that before that, I would teach that
sizeof((char)0 + (char)0 + (char)0) equals sizeof(int).

I believe you are wrong here, in that the number of terms in the
expression doesn't matter, provided there is at least one term.

((char)0) is an expression of type char.
((char)0 + (char)0) is an expression of type int or type unsigned.

I believe that the poster wanted to tell
about the difference between
C and C++ wrt. sizeof('a').

I believe both of you missed the point.

pete's statement that

sizeof((char)0 + (char)0 + (char)0) equals sizeof(int)

is correct in both C and C++. (char)0 is of type char, but it's
promoted to int when used in an expression.

"used in an expression" is insufficient to cause the conversion
of low ranking integer type expressions.
Array types and function types,
are the only types that the standard describes as
being always converted except in certain circumstances.

If the right operand of a shift operator is of type char,
it won't be converted.

(It could be promoted to
unsigned int in some exotic implementations, but sizeof(unsigned int)
== sizeof(int), so that wouldn't affect the truth of the statement.)

It's true that C and C++ treat character constants differently, but
there are no character constants in pete's code.

What *I'm* missing is why pete thinks this particular odd fact should
be taught before teaching arrays and pointers.

The particular odd fact is relevant to
the topic of implicit conversions, which is the juicy part
of the relationship between arrays and pointers.

This statement by Army1987:

Then I would tell them about
the fact that arrays decay into pointers as above.

made me wonder if the topics of
expressions and types and implicit conversions,
might be best presented before the topic of "array decay".

--
pete

[pete]

pete wrote:

>
Keith Thompson wrote:

I believe both of you missed the point.

pete's statement that

sizeof((char)0 + (char)0 + (char)0) equals sizeof(int)

is correct in both C and C++. (char)0 is of type char, but it's
promoted to int when used in an expression.

"used in an expression" is insufficient to cause the conversion
of low ranking integer type expressions.
Array types and function types,
are the only types that the standard describes as
being always converted except in certain circumstances.

If the right operand of a shift operator is of type char,
it won't be converted.

Oops. That's wrong.
But the point that I was trying to get at is that
the integer promotions are described as "only"
taking place under certain circumstances
and that

"used in an expression" is insufficient to cause the conversion
of low ranking integer type expressions.

N869
6.3.1.3 Signed and unsigned integers

42)The integer promotions are applied only: as part of the
usual arithmetic conversions, to certain argument
expressions, to the operands of the unary +, -, and ~
operators, and to both operands of the shift operators,
as specified by their respective subclauses.

This statement by Army1987:

Then I would tell them about
the fact that arrays decay into pointers as above.

made me wonder if the topics of
expressions and types and implicit conversions,
might be best presented before the topic of "array decay".

--
pete

[CBFalconer]

Keith Thompson wrote:

peter koch <pe***************@gmail.comwrites:

>CBFalconer <[e-mail]:

>>pete wrote:

.... snip ...

>>>
I don't know much about pedagogy,
but I think that before that, I would teach that
sizeof((char)0 + (char)0 + (char)0) equals sizeof(int).

I believe you are wrong here, in that the number of terms in the
expression doesn't matter, provided there is at least one term.

I believe that the poster wanted to tell about the difference
between C and C++ wrt. sizeof('a').

I believe both of you missed the point.

I didn't. Read what I wrote again.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com