Problem with array objects
Paul
"A pointer-to an array-type object" is not the same as "a pointer to an
array of objects" . Example:
int array[16];
int (*p_arraytype object)[16] = &array; /*(1)*/
int* p_array_of_objects = array; /*(2)*/
More generally the following terms can be used:
1) pointer to an array-type
2) pointer to an array
There are many confused individuals who say "pointer to array", when they
mean "pointer to array-type object". Often they put their opinions across in
such a way that it's a factual statement of an expert, perhaps because they
believe they are experts. As this newsgroup is unmoderated there is no way
to stop an overwhelming flow of bullshit from these self proclaimed experts,
so I would like to advise any beginners to use their brain and understand
how things work, and not to listen to these people with deluded opinions.
Hope this helps to clear up any confusion introduced in my other threads.
TY
Paul.
cg_chas
>After recent discussions I have come to the following conclusion:
priceless.
>
>"A pointer-to an array-type object" is not the same as "a pointer to an
>array of objects" . Example:
And nobody has argued this point that I am aware of. Nevertheless,
congratulations on your epiphany.
>
>int array[16];
>int (*p_arraytype object)[16] = &array; /*(1)*/
>int* p_array_of_objects = array; /*(2)*/
>
>More generally the following terms can be used:
>1) pointer to an array-type
>2) pointer to an array
Sure if you have no regard for technical correctness, but if you do then:
1) pointer to an array of 16 integers
2) pointer to an integer
but don't take my word for it..
"The C++ Programming Language section 5.1"
For a type T, T* is the type "pointer to T". That is, a variable of type T*
holds the address of type T.
Use Bjarne Stroustrup terms and stop attempting to sway the community into
thinking your epiphany has any value to anyone else.
>
>There are many confused individuals who say "pointer to array", when they
>mean "pointer to array-type object". Often they put their opinions across in
>such a way that it's a factual statement of an expert,
LOL, it is called citing an authoritative source!
You should try it some time, it does wonders for your credibility.
>believe they are experts.
> As this newsgroup is unmoderated there is no way
>to stop an overwhelming flow of bullshit
Yes, we know. There was no way to stop you from making the last 6 threads that
you have, of which include "Owned", "Proven Wrong", "You snipped something",
and my personal favorite, "an array is just a pointer".
>from these self proclaimed experts,
I haven't seen anybody claim they are an expert here. I certainly am not, but I
have witnessed you tell people they are confused, people that I would consider
to be experts at discussing the C++ language and who have done so for many
years.
>so I would like to advise any beginners to use their brain and understand
>how things work, and not to listen to these people with deluded opinions.
and I would like to advise beginners to read the FAQ and read highly recommended
C++ books such as those you'll find reviewed by members of accu.org.
>
>Hope this helps to clear up any confusion introduced in my other threads.
>
>TY
>Paul.
Paul, this is not personal, but you are not helping anybody, not even yourself.
crea
> and my personal favorite, "an array is just
> a pointer".
>
Its not just a pointer. Array is a ordered (0,1,2 ...) group data item
(basically any type). Yes, array has a pointer -- to pointing to its first
item and to know where its located in the memory.
So I would say: Array consists of pointer which tells where the array is
located and the content of memory blocks to define the items.
I just made it from my head, but I think this is correct.
Leigh Johnston
An array does not consist of a pointer; an array is convertible to a
pointer.
/Leigh
Paul
"cg_chas" <cg_...@hotmail.com> wrote in message
news:ljrio6hs8ag5o16gh...@4ax.com...
> On Wed, 23 Mar 2011 03:21:48 -0000, "Paul" <pchr...@yahoo.co.uk> wrote:
>
>>After recent discussions I have come to the following conclusion:
> priceless.
>
>>
>>"A pointer-to an array-type object" is not the same as "a pointer to an
>>array of objects" . Example:
> And nobody has argued this point that I am aware of. Nevertheless,
> congratulations on your epiphany.
>
>>
>>int array[16];
>>int (*p_arraytype object)[16] = &array; /*(1)*/
>>int* p_array_of_objects = array; /*(2)*/
>>
>>More generally the following terms can be used:
>>1) pointer to an array-type
>>2) pointer to an array
> Sure if you have no regard for technical correctness, but if you do then:
> 1) pointer to an array of 16 integers
> 2) pointer to an integer
>
int* p_arr = new int[16];
int x;
int p_int = &x;
You terminology is certainly not more technical correct than the terminology
i used. You are just one of those confused self proclaimed experts I was
talking about.
> but don't take my word for it..
>
> "The C++ Programming Language section 5.1"
> For a type T, T* is the type "pointer to T". That is, a variable of type
> T*
> holds the address of type T.
>
> Use Bjarne Stroustrup terms and stop attempting to sway the community into
> thinking your epiphany has any value to anyone else.
>
Bjarne agrees with me, that is a pointer of type T points to an object of
type T, or an array of objects of type T.
You seem to suggest Bjarne is saying that pointer to type T cannot also
point to an array of objects of type T, which ofcourse makes you totally
confused, and rather stupid in the eyes of most people I would think.
>>
>>There are many confused individuals who say "pointer to array", when they
>>mean "pointer to array-type object". Often they put their opinions across
>>in
>>such a way that it's a factual statement of an expert,
> LOL, it is called citing an authoritative source!
> You should try it some time, it does wonders for your credibility.
>
Not much point in citing an autohorative source if you are misinterpreting
him
<snip>
crea
in c++ sense it does. How do you otherwise know where the data is located if
there is no pointer? You have to know the address of the first item
otherwise the array is useless.
crea
Yes, array likeÖ
int arr[10];
then arr is NOT a pointer. Thats true. But still, arr must contain the
address of [0]. Ok , the word "pointer" is not precise, but "address" is.
So:
array is:
- address of the array
- ordered items
Paul
"crea" <n...@invalid.com> wrote in message
news:wBkip.136038$ts7.1...@newsfe14.ams2...
There is a good article about it here, its all explained well, IMO.:
http://c-faq.com/aryptr/aryptr2.html
Paul
not understand the difference between:
1) An array, or an array of objects of type T
2) An array-object.
An array-object *is like* a const pointer to the array, with additional type
info
Leigh Johnston
In C++ an array is not a pointer nor does it "consist" of a pointer; you
do not need a pointer to determine the address of the initial array
element of an array on the stack for example. Whilst an array is
convertible to a pointer (which is probably the source of your
confusion) it is wrong to say that an array "consists" of a pointer as
technical accuracy is quite important (something Paul The Troll doesn't
get).
/Leigh
Leigh Johnston
No; the array doesn't contain an "address" any more than it contains a
pointer: think technical accuracy (i.e. choose a word other than
"contain" and try again).
/Leigh
Paul
"Leigh Johnston" <le...@i42.co.uk> wrote in message
news:4aWdnVfi-5h0cBTQ...@giganews.com...
Leigh please stop acting like you are an authorative source, I would like to
remind you of the previous thread ref: "you snipped something".
WHere it is apparrent you are a complete idiot who doens't know what you're
talking about.
SG
> An array-object *is like* a const pointer to the array,
> with additional type info
Translation: "I was wrong to say 'an array is just a pointer'."
I suppose this is a way of thinking you might end up adopting if you
learn C or C++ by trial-and-error and without any decent books that
teach you the right mental models and terminology.
Another one is: an array-object is an array-object (containing all
elements as subobjects). It is implicitly convertible to a pointer to
its first element (array-to-pointer standard conversion) just like an
int value is implicitly convertible to a double value. This is the way
of thinking the C++ ISO standard suggests and this way of thinking
allows you to avoid the rather magical/vague "with additional type
info" part.
You might want to check again (ISO 14882) clause 3 (basic concepts), 4
(standard conversions), 5 (expressions), and 17.8.2 (template argument
deduction) -- since you came up with a function template for proving
that "an array is just a pointer".
You're welcome.
SG
Paul
"SG" <s.ges...@gmail.com> wrote in message
news:b52b4305-c23d-4cdb...@z20g2000yqe.googlegroups.com...
> On 23 Mrz., 13:34, Paul wrote:
>> An array-object *is like* a const pointer to the array,
>> with additional type info
>
> Translation: "I was wrong to say 'an array is just a pointer'."
Fortunately for me my text does not need any "translations". The only people
wrong here are the likes of you who think that an int* cannot point to an
array of ints.
>
> I suppose this is a way of thinking you might end up adopting if you
> learn C or C++ by trial-and-error and without any decent books that
> teach you the right mental models and terminology.
>
Your philosophy on peoples ways of thinking is, similar to your
understanding of C++, nothing more than utter bollocks TBH.
> Another one is: an array-object is an array-object (containing all
> elements as subobjects). It is implicitly convertible to a pointer to
> its first element (array-to-pointer standard conversion) just like an
> int value is implicitly convertible to a double value. This is the way
> of thinking the C++ ISO standard suggests and this way of thinking
> allows you to avoid the rather magical/vague "with additional type
> info" part.
>
> You might want to check again (ISO 14882) clause 3 (basic concepts), 4
> (standard conversions), 5 (expressions), and 17.8.2 (template argument
> deduction) -- since you came up with a function template for proving
> that "an array is just a pointer".
>
Yeah yeah , make a bunch of random references to the C++ standard and you
must be an authorative figure, seem it all before you obviously don't have
a clue what you are talking about.
Joel C. Salomon
> After recent discussions I have come to the following conclusion:
>
> "A pointer-to an array-type object" is not the same as "a pointer to an
> array of objects" . Example:
>
> int array[16];
> int (*p_arraytype object)[16] = &array; /*(1)*/
> int* p_array_of_objects = array; /*(2)*/
>
> More generally the following terms can be used:
> 1) pointer to an array-type
> 2) pointer to an array
>
We can avoid some more confusion if we eschew the term "pointer to array"
entirely, and instead say "pointer into an array". Consider:
int i, a[16];
int *p0 = &i; /* pointer to int object */
int *p1 = &a[0]; /* pointer to int = pointer *into* int array */
int *p2 = a; /* shortcut for the above */
int (*pa)[16] = &a; /* pointer to array object */
where I use the term "pointer to array object" for what you called "pointer
to array-type".
> Hope this helps to clear up any confusion introduced in my other threads.
I hope so too.
--Joel
Joel C. Salomon
> So I would say: Array consists of pointer which tells where the array is
> located and the content of memory blocks to define the items.
>
> I just made it from my head, but I think this is correct.
Um... That's not your head you're pointing to.
--Joel
cg_chas
The terminology I use is technically correct, not because I say so, but because
it closely follows that of the author of the C++ language. As I said, "Don't
take my word for it."
>>
>> but don't take my word for it..
see?
>>
>> "The C++ Programming Language section 5.1"
>> For a type T, T* is the type "pointer to T". That is, a variable of type
>> T*
>> holds the address of type T.
>>
>> Use Bjarne Stroustrup terms and stop attempting to sway the community into
>> thinking your epiphany has any value to anyone else.
>>
>Bjarne agrees with me, that is a pointer of type T points to an object of
>type T, or an array of objects of type T.
LOL does he?
So tell us all then, which part of:
"For a type T, T* is the type "pointer to T". That is, a variable of type T*
holds the address of type T."
in your mind says: "or an array of objects of type T" ?
Bjarne's statements are a __pointer definition__, as is what all of my responses
to you have been in the context of. By failing to understand a most simple, yet
technically precise pointer definition when you are presented with one, then you
are certainly not competent enough to say what a pointer points to. That is
irrefutable.
>
>You seem to suggest Bjarne is saying that pointer to type T cannot also
>point to an array of objects of type T, which ofcourse makes you totally
>confused, and rather stupid in the eyes of most people I would think.
Your interpretation of what I suggest or what anyone suggests is the very
essence of you comprehension. You fail to realize that I am ONLY asserting the
cases that were given to us by the author of the C++ language. I am not the one
making up new cases that are loose in meaning and imprecise at best.
>
>
>
>>>
>>>There are many confused individuals who say "pointer to array", when they
>>>mean "pointer to array-type object". Often they put their opinions across
>>>in
>>>such a way that it's a factual statement of an expert,
>> LOL, it is called citing an authoritative source!
>> You should try it some time, it does wonders for your credibility.
>>
>Not much point in citing an autohorative source if you are misinterpreting
>him
Nobody here but you is misinterpreting him. A 5th grader could process his
pointer definition. The fact that you are making it some form of array
definition is the quintessential reason why you are not qualified to hold a C++
discussion.
As the list of people who openly disagree with you grows, so does the time you
waste responding without thinking, to each and every one of them. Fortunately
all you have to do is keep calling us all idiots to save face, right?
Paul
"Joel C. Salomon" <jsal...@bgcpartners.com> wrote in message
news:imd1j8$ojp$1...@news.albasani.net...
int* p1 = new int[dim]; /* p1 points to a 1dim array of type int */
int (*p2)[dim2] = new int[dim1][dim2]; /*p2 points to a 2dim array of type
int */
int arr[5] = {1,2,3,4,5};
int (*p3)[dim] = &arr; /*Pointless extra level of indirection [see note]*/
int** p4 = &arr; /*Same as above, but without typeinfo*/
int x = **p3; /*Same as (**p4) */
int* p5 = *p3; /* p5 is a pointer to an array(of objects) of type int */
This is the source of much confusion because many people cannot accept that
a pointer to an array *can* point to both a single element and the array, at
the same time. I emphasise 'can' because a pointer to an array does not need
to point to an element, its allowed to point one past the last element.
I used the analogy before about pointing to a bunch of bananas. If you point
to a banana within a bunch you are also pointing at the bunch of bananas.
Note:: there may be some rare circumstances where this is of reasonable use.
HTH
Paul.
Leigh Johnston
[...]
> int (*p3)[dim] = &arr; /*Pointless extra level of indirection [see note]*/
> int** p4 = &arr; /*Same as above, but without typeinfo*/
Untrue; int (*p3)[dim] is not the same as int** (they are totally
unrelated types).
You need to learn pointer basics from a decent C++ book; obviously your
current C++ reference (a pre-ISO C++ compiler manual) is inadequate.
HTH.
/Leigh
SG
> This is the source of much confusion because many people cannot accept
> that a pointer to an array *can* point to both a single element and
> the array, at the same time.
They cannot accept that because their mental model about arrays,
objects, and pointers does not let them. Their idea of a pointer is
something that points to exactly one thing and one thing only unless
it's a null pointer or a one-past-the-end pointer. And to what kind of
objects their pointers point to is statically controlled by the type
of the pointer. It's a different way of thinking about these things
that is more focused on types and that does not match your way of
thinking. I get that. You don't.
> I used the analogy before about pointing to a bunch of bananas.
...which has been pointed out to be a flawed analogy given their
mental model about arrays, pointers and objects. It's an analogy that
only fits using your way of thinking.
On 23 Mrz., 14:36, Paul wrote:
> SG wrote:
> > On 23 Mrz., 13:34, Paul wrote:
> >> An array-object *is like* a const pointer to the array,
> >> with additional type info
> > Translation: "I was wrong to say 'an array is just a pointer'."
> Fortunately for me my text does not need any "translations".
From what I can tell, your texts need lots of translation and
clarification. That's because you seemingly tend to express your
thoughts on C++ related matters using a different understanding of the
words' meanings. Examples include "pointer to array" as well as "being
part of an object".
In addition you're stating things as fact which are plain wrong.
Examples include "an array is just a pointer". You recently refined
that to be "An array-object *is like* a const pointer to the array,
with additional type info". That's better, I guess. But not much
better. The _precise_ version of this can be found in the C++ ISO
standard:
ISO 14882, §4.2 [array.conv]
----------------------------
"An [expression] of type 'array of N T' or 'array of unknown
bound of T' can be converted to an rvalue of type pointer to
T. The result is a pointer to the first element of the array."
This conversion is again referenced in §17.8.2 when it's about
template argument deduction. You can look it up yourself.
> Your philosophy on peoples ways of thinking is
> [...] nothing more than utter bollocks TBH.
I think you say this because you don't understand what I am talking
about. I think you adopted your way of thinking about arrays and
pointers because you learned C and/or C++ mainly by trial-and-error
and came up with this mental model as explanation for the behaviour
you observed.
> > You might want to check again (ISO 14882) clause 3 (basic concepts), 4
> > (standard conversions), 5 (expressions), and 17.8.2 (template argument
> > deduction) -- since you came up with a function template for proving
> > that "an array is just a pointer".
>
> Yeah yeah, make a bunch of random references to the C++ standard and you
> must be an authorative figure, seem it all before you obviously don't have
> a clue what you are talking about.
I make these broad references because you don't seem to have a firm
grasp on C++ concepts and terminology (as can be found in the ISO
standard). For example, §3 explains to you what lvalues and rvalues
are about. It links lvalues and rvalues to expressions. Something you
should be aware of when reading the following clauses. Clause §4
explains standard conversions, including array-to-pointer conversion.
§5 explains what expressions are about including what the type of an
id-expression is that names a reference, for example. §17.8.2 explains
the rules of template argument deduction including the one that
explains the behaviour of your code examples with a function template
'foo' you presented in order to "prove" that "arrays are just
pointers". However, the observable behaviour of your test programs
does not contradict with the mental model of your "opponents". The
fact that you believe otherwise just suggests that you don't
understand what people are talking about.
SG
Paul
No it doesn't you suggest that the following is not a pointer to an array
but is only a pointer to a single int:
int* p = new int[5];
Bjarne Stroustrup would never suggest such nonsense, and you are incorrect
to say he does.
>>>
>>> but don't take my word for it..
> see?
>>>
>>> "The C++ Programming Language section 5.1"
>>> For a type T, T* is the type "pointer to T". That is, a variable of type
>>> T*
>>> holds the address of type T.
>>>
>>> Use Bjarne Stroustrup terms and stop attempting to sway the community
>>> into
>>> thinking your epiphany has any value to anyone else.
>>>
>>Bjarne agrees with me, that is a pointer of type T points to an object of
>>type T, or an array of objects of type T.
> LOL does he?
Yes he does:
<quote ref: http://www2.research.att.com/~bs/glossary.html>
char* - pointer to a char or an array of char. Typically assumed to point to
a C-style string. Prefer a standard library string over a C-style string
when you can. TC++PL 2.3.3, 13.5.2.
</quote>
> So tell us all then, which part of:
>
> "For a type T, T* is the type "pointer to T". That is, a variable of type
> T*
> holds the address of type T."
>
> in your mind says: "or an array of objects of type T" ?
>
> Bjarne's statements are a __pointer definition__, as is what all of my
> responses
> to you have been in the context of. By failing to understand a most
> simple, yet
> technically precise pointer definition when you are presented with one,
> then you
> are certainly not competent enough to say what a pointer points to. That
> is
> irrefutable.
>
Apparently you are the one who fails to understand.
>>
>>You seem to suggest Bjarne is saying that pointer to type T cannot also
>>point to an array of objects of type T, which ofcourse makes you totally
>>confused, and rather stupid in the eyes of most people I would think.
> Your interpretation of what I suggest or what anyone suggests is the very
> essence of you comprehension. You fail to realize that I am ONLY
> asserting the
> cases that were given to us by the author of the C++ language. I am not
> the one
> making up new cases that are loose in meaning and imprecise at best.
>
I understand you are typing complete bullshit. And I interpet what you say
as it is .. complete bullshit.
>>
>>
>>
>>>>
>>>>There are many confused individuals who say "pointer to array", when
>>>>they
>>>>mean "pointer to array-type object". Often they put their opinions
>>>>across
>>>>in
>>>>such a way that it's a factual statement of an expert,
>>> LOL, it is called citing an authoritative source!
>>> You should try it some time, it does wonders for your credibility.
>>>
>>Not much point in citing an autohorative source if you are misinterpreting
>>him
> Nobody here but you is misinterpreting him. A 5th grader could process
> his
> pointer definition. The fact that you are making it some form of array
> definition is the quintessential reason why you are not qualified to hold
> a C++
> discussion.
>
Nobody here but *YOU* is misinterpreting him.
> As the list of people who openly disagree with you grows, so does the time
> you
> waste responding without thinking, to each and every one of them.
> Fortunately
> all you have to do is keep calling us all idiots to save face, right?
*plonk*
cg_chas
<snip trolling>
>I used the analogy before about pointing to a bunch of bananas. If you point
>to a banana within a bunch you are also pointing at the bunch of bananas.
back to bananas eh? Ok if you insist.
Or the person could be pointing to the mental patient holding the bunch of
bananas. We'll never know because the analogy is replete with failure in that no
strictly defined terms are being used as there are within the context of a
proper C++ discussion.
An equally meaningless and imprecise analogy would be:
If Paul the mental patient was locked away in a mental institution and was
pointing at something in the general direction of the wall, and somebody looked
into the window of his room and asked what he was pointing at, the nurse would
be right to say, "Nobody knows, he just keeps raving about how array types are
not the same as array objects- see the bananas?" ...
>
>Note:: there may be some rare circumstances where this is of reasonable use.
Note: In comp.lang.C++ there will never be a circumstance where your banana
analogy is of any use.
A note on comp.lang.c++ etiquette: Accuracy is valued very highly in this
newsgroup; therefore posts are frequently corrected, sometimes perhaps
too harshly, and often to the annoyance of new posters who consider the
correction trivial. Do not take it personally; the best way to fit in
with comp.lang.c++ is to express gratitude for the correction, move on,
and be more careful next time.
Paul
> On 23/03/2011 16:27, Paul wrote:
> [...]
>> int (*p3)[dim] = &arr; /*Pointless extra level of indirection [see
>> note]*/
>> int** p4 = &arr; /*Same as above, but without typeinfo*/
>
> Untrue; int (*p3)[dim] is not the same as int** (they are totally
> unrelated types).
>
int (*p3)[dim]; /*-- points to an array of int.---*/
int** p4; /* ---- points to an int* ---- */
The followings shows they both point to the same place:
int arr[5]={1,2,3,4,5};
int (*p)[5] = &arr;
int** pp = (int**)&arr;
std::cout<< "value of p:\t"<<p <<"\nvalue of pp:\t" <<pp;
I just forgot the cast.
Leigh Johnston
Using the result of that cast is UB:
std::cout<< **pp;
will probably cause a crash.
Like I said you need to learn pointer basics as you currently have no clue.
/Leigh
SG
> On 23/03/2011 16:27, Paul wrote:
> [...]
>
> > int (*p3)[dim] = &arr; /*Pointless extra level of indirection [see note]*/
> > int** p4 = &arr; /*Same as above, but without typeinfo*/
>
> Untrue; int (*p3)[dim] is not the same as int** (they are totally
> unrelated types).
Good catch! This example speaks volumes. His wrongness apparently goes
beyond terminology issues. If his mental model makes him predict that
the above code will compile then his mental model is obviously wrong.
I'm not surprized, though. He's not the first one to trip over the
rather sneaky
- array-to-pointer standard conversion (§4.2)
- function parameter type transformations (§8.3)
- template argument deduction (§14.8.2)
rules. It's one of dangers of learning C++ via trial-and-error.
SG
Paul
>On 23 Mrz., 17:27, Paul wrote:
>> This is the source of much confusion because many people cannot accept
>> that a pointer to an array *can* point to both a single element and
>> the array, at the same time.
>
>They cannot accept that because their mental model about arrays,
>objects, and pointers does not let them.
You were included when I said "they", therefore you should use the word "we"
when referrring to a group that includes yourself.
>Their idea of a pointer is
>something that points to exactly one thing and one thing only unless
>it's a null pointer or a one-past-the-end pointer. And to what kind of
>objects their pointers point to is statically controlled by the type
>of the pointer. It's a different way of thinking about these things
>that is more focused on types and that does not match your way of
>thinking. I get that. You don't.
>
I understand they/you are wrong, you don't.
>> I used the analogy before about pointing to a bunch of bananas.
>
>...which has been pointed out to be a flawed analogy given their
>mental model about arrays, pointers and objects. It's an analogy that
>only fits using your way of thinking.
>
Their/your mental model is wrong not my analogy.
<snip>
Noah Roberts
> On Wed, 23 Mar 2011 16:27:19 -0000, "Paul"<pchr...@yahoo.co.uk> wrote:
>
> "array types are
There isn't even any such thing as an array object is there? AFAIK
there's not.
Leigh Johnston
> On 3/23/2011 9:54 AM, cg_chas wrote:
>> On Wed, 23 Mar 2011 16:27:19 -0000, "Paul"<pchr...@yahoo.co.uk> wrote:
>>
>> "array types are
>> not the same as array objects" ...
>
> There isn't even any such thing as an array object is there? AFAIK
> there's not.
The term "array object" is present in the C++ Standard; try using search.
/Leigh
SG
>
> The followings shows they both point to the same place:
> int arr[5]={1,2,3,4,5};
> int (*p)[5] = &arr;
> int** pp = (int**)&arr;
>
> std::cout<< "value of p:\t"<<p <<"\nvalue of pp:\t" <<pp;
>
> I just forgot the cast.
How do you access an element of arr using pp? Is (*pp)[3] going to be
an lvalue referring to the fourth element of arr?
SG
cg_chas
p points to the initial int element OF an array.
those are my words.
those are Stroustrup's words.
those are Koenig's words.
I would not be so arrogant as to put any other weight on what anybody might or
might not say beyond what they have already published.
>>>>
>>>> but don't take my word for it..
>> see?
>>>>
>>>> "The C++ Programming Language section 5.1"
>>>> For a type T, T* is the type "pointer to T". That is, a variable of type
>>>> T*
>>>> holds the address of type T.
>>>>
>>>> Use Bjarne Stroustrup terms and stop attempting to sway the community
>>>> into
>>>> thinking your epiphany has any value to anyone else.
>>>>
>>>Bjarne agrees with me, that is a pointer of type T points to an object of
>>>type T, or an array of objects of type T.
>
>> LOL does he?
>
>Yes he does:
><quote ref: http://www2.research.att.com/~bs/glossary.html>
>char* - pointer to a char or an array of char. Typically assumed to point to
>a C-style string. Prefer a standard library string over a C-style string
>when you can. TC++PL 2.3.3, 13.5.2.
></quote>
A meaningful citation finally that is in the context of the discussion. I
congratulate you and give you your due respect, but your application of
semantics are not identical.
There is notable difference between int* and char* if the later is used to form
a c-style string which is why that glossay definition gave the further
elaboration and references as to the meaning.
By definition of c-style string, it is a zero terminated array.
char* chp1 = "string"; // string is an array in memory, but chp1 doesn't know it
char chp2[] = "string"; // string is an array in memory, and chp2 has the type
to assert it
std::cout << "chp1 type is : " << typeid(chp1).name() << std::endl; // char*
std::cout << "chp2 type is : " << typeid(chp2).name() << std::endl; // char[7]
Simple runtime execution shows you the type differences.
the first is a pointer to char
the later is a pointer to an array of char
Back to int* p_arr = new int[16];
This code is very strictly defined as to what it really does.
new allocates an array of 16 int on the heap
the address of the first int element of that array is used to initialize p_arr
which is an int pointer object.
It is no more technically precise or even correct to say that p_arr is a pointer
to an array than it is to say that p_arr is an array pointer, and clearly it is
not an array pointer.
TCPPPL 5.1 and any ISO compliant compiler will give you code at runtime to
support that very assertion.
>
>> So tell us all then, which part of:
>>
>> "For a type T, T* is the type "pointer to T". That is, a variable of type
>> T*
>> holds the address of type T."
>>
>> in your mind says: "or an array of objects of type T" ?
>>
>> Bjarne's statements are a __pointer definition__, as is what all of my
>> responses
>> to you have been in the context of. By failing to understand a most
>> simple, yet
>> technically precise pointer definition when you are presented with one,
>> then you
>> are certainly not competent enough to say what a pointer points to. That
>> is
>> irrefutable.
>>
<snip trolling>
cg_chas
>On 3/23/2011 9:54 AM, cg_chas wrote:
>> On Wed, 23 Mar 2011 16:27:19 -0000, "Paul"<pchr...@yahoo.co.uk> wrote:
>>
>> "array types are
>> not the same as array objects" ...
>
>There isn't even any such thing as an array object is there? AFAIK
>there's not.
Actually there is, but my point was that Paul continues to attempt to make an
argument that there is some distinct difference between an array object and and
object of array type by using loose fitting terminology.
Of course he is wrong, but that is his argument, nevertheless.
cg_chas
with implicit conversion of course TCPPL 5.3
cg_chas
actually, correcting myself again, the address of operator makes it a pointer
(&)
the above comment should be for the later case array of 7 character and the
pointer to that array &chp2 is an array pointer OR pointer to an array.
My bad for the inaccuracy.
Paul
> On 23/03/2011 17:01, Paul wrote:
>>
>> "Leigh Johnston" <le...@i42.co.uk> wrote in message
>> news:gqKdnXPi_rSivBfQ...@giganews.com...
>>> On 23/03/2011 16:27, Paul wrote:
>>> [...]
>>>> int (*p3)[dim] = &arr; /*Pointless extra level of indirection [see
>>>> note]*/
>>>> int** p4 = &arr; /*Same as above, but without typeinfo*/
>>>
>>> Untrue; int (*p3)[dim] is not the same as int** (they are totally
>>> unrelated types).
>>>
>> No they are related types. Related because:
>> int (*p3)[dim]; /*-- points to an array of int.---*/
>> int** p4; /* ---- points to an int* ---- */
>>
>> The followings shows they both point to the same place:
>> int arr[5]={1,2,3,4,5};
>> int (*p)[5] = &arr;
>> int** pp = (int**)&arr;
>> std::cout<< "value of p:\t"<<p <<"\nvalue of pp:\t" <<pp;
>>
>> I just forgot the cast.
>
> Using the result of that cast is UB:
>
> std::cout<< **pp;
>
int* temp = (int*)*p; /* --Convert p to int* first--*/
int** pp = &temp; /* ---Assign address of p to pp---*/
> will probably cause a crash.
>
So what it was an example to explain the extra level of indirection. If
wasn't meant to be compileable code.
I have now shown you how to do it with compileable code and the same context
still applies.
cg_chas
wrote:
>Paul wrote:
>> After recent discussions I have come to the following conclusion:
>>
>> "A pointer-to an array-type object" is not the same as "a pointer to an
>> array of objects" . Example:
>>
>> int array[16];
>> int (*p_arraytype object)[16] = &array; /*(1)*/
>> int* p_array_of_objects = array; /*(2)*/
>>
>> More generally the following terms can be used:
>> 1) pointer to an array-type
>> 2) pointer to an array
>>
>> There are many ... individuals who say "pointer to array", when they
>> mean "pointer to array-type object".
>
>We can avoid some more confusion if we eschew the term "pointer to array"
>entirely,
I agree entirely, but Paul is not going to do that since it is the very center
of his debate.
> and instead say "pointer into an array". Consider:
>
> int i, a[16];
> int *p0 = &i; /* pointer to int object */
> int *p1 = &a[0]; /* pointer to int = pointer *into* int array */
> int *p2 = a; /* shortcut for the above */
> int (*pa)[16] = &a; /* pointer to array object */
>
looks fine to me as TCPPPL 5.3 can corroborate explicitly.
runtime execution agrees
std::cout << "p0 type is : " << typeid(p0).name() << std::endl; // int *
std::cout << "p1 type is : " << typeid(p1).name() << std::endl; // int *
std::cout << "p2 type is : " << typeid(p2).name() << std::endl; // int *
std::cout << "pa type is : " << typeid(pa).name() << std::endl; // int (*)[16]
>where I use the term "pointer to array object" for what you called "pointer
>to array-type".
A perfect example of why Paul should not be discussing C++. No pointer points to
a type. It has been said numerous times now.
kudos
Paul
of indirection I am explaining , there are different ways to properly cast
this and you are just attempting to divert the point.
Leigh Johnston
Why don't you just admit to your mistakes rather than trying to mask
them by writing something different?
You said: int** p4 = &arr;
which was wrong; you tried to correct it with a cast but is was still wrong.
/Leigh
Peter Remmers
>
> int arr[5] = {1,2,3,4,5};
> int** p4 =&arr; /*Same as above, but without typeinfo*/
It definitely is *not* the same. p1 is a pointer to a pointer to int.
That means, the memory location that p4 points to is interpreted as
another pointer value, which it isn't - it contains an int element of
arr. The moment you dereference this false pointer, you invoke UB.
> int x = **p3; /*Same as (**p4) */
Not the same.
Just because you can write p4[foo][bar] does not mean it is equivalent
to arr[foo][bar].
"**p3" works because the result of the first dereference is of type
"int[dim]", and for the second asterisk, that result is first converted
to "int*" and then dereferenced.
> HTH
That doesn't help.
Peter
Leigh Johnston
FAIL.
/Leigh
cg_chas
LOL priceless. This is about as bad as making a statment such as "An array is
just a pointer"
I really think you cannot hear yourself. Man up and stand by what you say, Paul.
>wasn't meant to be compileable code.
What Paul really means is that he prefers to write code into a newsreader
application instead of his compiler because it will serve the greater good of
the C++ community and educate all that need it.
Leigh Johnston
> On Wed, 23 Mar 2011 18:01:25 -0000, "Paul"<pchr...@yahoo.co.uk> wrote:
>> So what it was an example to explain the extra level of indirection. If
>> wasn't meant to be compileable code.
>>
> LOL priceless. This is about as bad as making a statment such as "An array is
> just a pointer"
>
> I really think you cannot hear yourself. Man up and stand by what you say, Paul.
The main problem is that Paul usually *does* stubbornly stand by what he
says ignoring reason and causing much noise in this newsgroup in the
process.
>
>> wasn't meant to be compileable code.
> What Paul really means is that he prefers to write code into a newsreader
> application instead of his compiler because it will serve the greater good of
> the C++ community and educate all that need it.
Indeed. :)
/Leigh
cg_chas
>On 23/03/2011 18:11, cg_chas wrote:
>> On Wed, 23 Mar 2011 18:01:25 -0000, "Paul"<pchr...@yahoo.co.uk> wrote:
>[...]
>>> So what it was an example to explain the extra level of indirection. If
>>> wasn't meant to be compileable code.
>>>
>> LOL priceless. This is about as bad as making a statment such as "An array is
>> just a pointer"
>>
>> I really think you cannot hear yourself. Man up and stand by what you say, Paul.
>
>The main problem is that Paul usually *does* stubbornly stand by what he
>says ignoring reason and causing much noise in this newsgroup in the
>process.
too true.
Paul
>On 23 Mrz., 17:35, Leigh Johnston wrote:
>> On 23/03/2011 16:27, Paul wrote:
>> [...]
>>
>> > int (*p3)[dim] = &arr; /*Pointless extra level of indirection [see
>> > note]*/
>> > int** p4 = &arr; /*Same as above, but without typeinfo*/
>>
>> Untrue; int (*p3)[dim] is not the same as int** (they are totally
>> unrelated types).
>
>Good catch!
As I will demonstrate:
int* ptemp = (int*)*p3; /* --Convert p3 to int* --*/
int** p4 = &ptemp;
And I was saying int** is the same level of indirection as &arr , or
int(*p)[dim].
This just proves how silly you are if you :
a) didn't realise the types can be converted
b) didn't realise I was talking about levels of indirection.
>This example speaks volumes. His wrongness apparently goes
>beyond terminology issues. If his mental model makes him predict that
>the above code will compile then his mental model is obviously wrong.
>
>I'm not surprized, though. He's not the first one to trip over the
>rather sneaky
>- array-to-pointer standard conversion (§4.2)
>- function parameter type transformations (§8.3)
>- template argument deduction (§14.8.2)
>rules. It's one of dangers of learning C++ via trial-and-error.
Once again you fail to demonstrate anything other than obnoxious disregard
for the truth.
SG
Paul
You have a cheek posting in this newsgroup after that other subthread of
yours in this thread.
<snip>
Leigh Johnston
>
>> "SG" <s.ges...@gmail.com> wrote in message
>> news:7ec50850-1116-43a3-a6f3->8b48de...@k7g2000yqj.googlegroups.com...
>> On 23 Mrz., 17:35, Leigh Johnston wrote:
>>> On 23/03/2011 16:27, Paul wrote:
>>> [...]
>>>
>>> > int (*p3)[dim] = &arr; /*Pointless extra level of indirection [see
>>> > note]*/
>>> > int** p4 = &arr; /*Same as above, but without typeinfo*/
>>>
>>> Untrue; int (*p3)[dim] is not the same as int** (they are totally
>>> unrelated types).
>>
>> Good catch!
> This is utter nonsense the types are related and can be properly
> converted. As I will demonstrate:
Looks like two new terms have just entered Paul's world: "related types"
and "type conversion" and of course his understanding of what these
terms mean differs from everybody else's (this is unsurprising given his
track record). We can now expect a huge, tedious thread of bullshit
trying to explain things to someone who is incapable of learning from
others.
/Leigh
cg_chas
A note on comp.lang.c++ etiquette: Accuracy is valued very highly in this
newsgroup; therefore posts are frequently corrected, sometimes perhaps
too harshly, and often to the annoyance of new posters who consider the
correction trivial. Do not take it personally; the best way to fit in
with comp.lang.c++ is to express gratitude for the correction, move on,
and be more careful next time.
Do not take it personally.
You are not the first troll to come along seeking knowledge by way of spewing
tripe and I'm sure you won't be the last.
Now move on and be more careful next time.
Paul
You can't even quote a book properly , let alone understand it.
*plonk*
cg_chas
>On 23/03/2011 18:21, Paul wrote:
>>
>>> "SG" <s.ges...@gmail.com> wrote in message
>>> news:7ec50850-1116-43a3-a6f3->8b48de...@k7g2000yqj.googlegroups.com...
>>> On 23 Mrz., 17:35, Leigh Johnston wrote:
>>>> On 23/03/2011 16:27, Paul wrote:
>>>> [...]
>>>>
>>>> > int (*p3)[dim] = &arr; /*Pointless extra level of indirection [see
>>>> > note]*/
>>>> > int** p4 = &arr; /*Same as above, but without typeinfo*/
>>>>
>>>> Untrue; int (*p3)[dim] is not the same as int** (they are totally
>>>> unrelated types).
>>>
>>> Good catch!
>> This is utter nonsense the types are related and can be properly
>> converted. As I will demonstrate:
>
>Looks like two new terms have just entered Paul's world: "related types"
>and "type conversion"
I have made similar observations with regards to his learning techniques.
Paul's first citation that fit the context of a conversation was today.
He's learning as he goes, much like a baby that took its first steps, he's going
to stumble for another 3-4 years.
Of course, the C++ community is left with cleaning up his vomit every 20 minutes
in the meantime.
>and of course his understanding of what these
>terms mean differs from everybody else's (this is unsurprising given his
>track record). We can now expect a huge, tedious thread of bullshit
>trying to explain things to someone who is incapable of learning from
>others.
>
>/Leigh
Indeed.
cg_chas
You've quoted a snip. You are replete with failure and infinitely regress.
Do I need to put on a raincoat for the monkey feces now?
Paul
explain was the equality in levels of indirection, which is correct.
Paul
something :)
Paul
<quote ref: http://c-faq.com/aryptr/aryptr2.html >
The pointer declaration char *p, on the other hand, requests a place which
holds a pointer, to be known by the name ``p''. This pointer can point
almost anywhere: to any char, or to any contiguous array of chars, or
nowhere .
</quote>
:-)
Paul
complete idiot here.
*shrug*
Paul
"Peter Remmers" <p.re...@expires-2011-03-31.arcornews.de> wrote in message
news:4d8a370f$0$6768$9b4e...@newsspool3.arcor-online.net...
> Am 23.03.2011 17:27, schrieb Paul:
>>
>> int arr[5] = {1,2,3,4,5};
>> int (*p3)[dim] =&arr; /*Pointless extra level of indirection [see note]*/
>> int** p4 =&arr; /*Same as above, but without typeinfo*/
> It definitely is *not* the same.
explaining that &arr is the same as int** in terms of levels of indirection.
I think this has already been discussed :)
cg_chas
>"cg_chas" <cg_...@hotmail.com> wrote in message
>news:5jfko619fr0s8oqag...@4ax.com...
>> On Wed, 23 Mar 2011 18:37:48 -0000, "Paul" <pchr...@yahoo.co.uk> wrote:
>>
>>>
>>>"cg_chas" <cg_...@hotmail.com> wrote in message
>>>news:ii9ko6lakgeq0lg02...@4ax.com...
>>>> On Wed, 23 Mar 2011 16:48:43 -0000, "Paul" <pchr...@yahoo.co.uk>
>>>> wrote:
>>>>
>>><snip>
>>>You can't even quote a book properly , let alone understand it.
>>>
>>>*plonk*
>>
>> You've quoted a snip. You are replete with failure and infinitely
>> regress.
>>
>> Do I need to put on a raincoat for the monkey feces now?
>>
>No level of abuse can change the fact that I have proven you to be a
>complete idiot here.
>
>*shrug*
All that you have proven is that you can start half a dozen threads in a C++
newsgroup and fail to make a single coherent assertion in any of them.
Why?
Because you paste poorly written code snippets and then say,
"It wasn't meant to be compileable code."
And..
Because you start threads like, "An array is just a pointer", then you go on to
try and prove that false statement in five other threads including that one,
just to change your mind and say things like, "I didn't mean it as a statement
of fact".
If telling you the truth makes you feel abused, then I refer you to the FAQ,
A note on comp.lang.c++ etiquette: Accuracy is valued very highly in this
newsgroup; therefore posts are frequently corrected, sometimes perhaps
too harshly, and often to the annoyance of new posters who consider the
correction trivial. Do not take it personally; the best way to fit in
with comp.lang.c++ is to express gratitude for the correction, move on,
and be more careful next time.
Rarely you say anything technically correct because you are limited by your own
level of comprehension, yet you feel abused once you are corrected.
"Do not take it personally; the best way to fit in
with comp.lang.c++ is to express gratitude for the correction, move on,
and be more careful next time."
HTH
Paul
> On Wed, 23 Mar 2011 18:50:05 -0000, "Paul" <pchr...@yahoo.co.uk> wrote:
>>>>>
>>>><snip>
>>>>You can't even quote a book properly , let alone understand it.
>>>>
>>>>*plonk*
>>>
>>> You've quoted a snip. You are replete with failure and infinitely
>>> regress.
>>>
>>> Do I need to put on a raincoat for the monkey feces now?
>>>
>>No level of abuse can change the fact that I have proven you to be a
>>complete idiot here.
>>
>>*shrug*
> All that you have proven is that you can start half a dozen threads in a
> C++
> newsgroup and fail to make a single coherent assertion in any of them.
>
texts but you also misunderstand them.
And by proving this I have also proven that you are wrong to say that p(in
the following example) doesn't point to an array:
int* p = new int[4];
Leigh Johnston
You have been told many times that saying "p points to an array" is
technically inaccurate: p points to the initial element of an array; in
addition saying "p is a pointer to an array" is not just technically
inaccurate it is plain wrong.
/Leigh
Paul
in direct conflict with authorative experts.
<quote ref: http://c-faq.com/aryptr/aryptr2.html>
The pointer declaration char *p, on the other hand, requests a place which
holds a pointer, to be known by the name ``p''. This pointer can point
almost anywhere: to any char, or to any contiguous array of chars, or
nowhere
cg_chas
a matter of technical correctness. read the FAQ.
Once again, we will revisit the simple example and spoon feed you the
irrefutable logic that you will fail to comprehend.
int* p = new int[4];
Your statement is that p points to an array and that saying so is technically as
equally correct as saying p points to a single integer element - yes i've
translated this for you into proper language so everybody knows your position.
If it were as equally precise, or technically correct to say that p points to an
array, then it must also be as equally correct to say that p in an array
pointer. An array pointer is one way of saying array pointer object, of which p
clearly is not.
Your argument would have p be an array pointer object in order for you to be
correct. It is not, so you are not.
My assertion is not a derivation of TCPPPL 5.1 but rather an explicit case usage
of it. Here is an authoritative definition of pointer.
"For a type T, T* is the type "pointer to T". That is, a variable of type T*
holds the address of type T."
T is int.
p is pointer to int.
p holds the address of a variable of type int.
T is not int array.
p is not a pointer to int array.
p does not hold the address of a variable of type int array.
There is no misinterpretation here on my part.
You should read section 5.1 of TCPPPL as well as all of Accelerated C++ because
not only do they define pointer for you, but they gives a whole series of
examples of how to talk about the pointers. In NO case does Stroustrup or
Koenig carelessly give an example using an int* and say that it points to an
array.
If you want to use less precise terminology that is your choice, but if a
question arises as to what you are talking about, then it is your duty to
clarify with technical correctness, something you clearly fail to do
consistently.
Asked and anwered, so kindly move along Paul.
cg_chas
typo. should be "is", not "in".
A. Bolmarcich
> No I have proven that you do not only misinterpret and misquote authorative
> texts but you also misunderstand them.
> And by proving this I have also proven that you are wrong to say that p(in
> the following example) doesn't point to an array:
> int* p = new int[4];
Here is paragraph 5 of section 3.4.5, about the new expression, from the 1998
C++ standard.
"When the allocated object is an array (that is, the direct-new-declarator
syntax is used or the new-type-id or type-id denotes an array type), the
new-expression yields a pointer to the initial element (if any) of the array.
[Note: both new int and new int [10] have type int* and the type of new int[i]
[10] is int (*)[10].]"
According to the standard, p (in the example) doesn't point to an array, that
is, p does not point to an object with an array type.
What p points to is an int. The value of p is the int* value returned by "new
int[4]". That value is a pointer to the first of the four contiguous ints that
were allocated.
Paul
"A. Bolmarcich" <agg...@earl-grey.cloud9.net> wrote in message
news:slrnioplhp....@earl-grey.cloud9.net...
> On 2011-03-23, Paul <pchr...@yahoo.co.uk> wrote:
>> No I have proven that you do not only misinterpret and misquote
>> authorative
>> texts but you also misunderstand them.
>> And by proving this I have also proven that you are wrong to say that
>> p(in
>> the following example) doesn't point to an array:
>> int* p = new int[4];
>
> Here is paragraph 5 of section 3.4.5, about the new expression, from the
> 1998
> C++ standard.
>
> "When the allocated object is an array (that is, the direct-new-declarator
> syntax is used or the new-type-id or type-id denotes an array type), the
> new-expression yields a pointer to the initial element (if any) of the
> array.
> [Note: both new int and new int [10] have type int* and the type of new
> int[i]
> [10] is int (*)[10].]"
>
> According to the standard, p (in the example) doesn't point to an array,
> that
> is, p does not point to an object with an array type.
The standard doesn't say p doesn't point to an array. Quite the opposite, it
clearly states that "When the allocated object is an array". The object it
points to is an array of ints.
You are correct to say it doesn't point to an array-type object, this is
because a pointer to an array of n-dimensions is of type n-1 dimensions.
That is:
A pointer to a 2dim array is of type..... T (*)[dim2]
A pointer to a 1dim array is of type..... T*
Note that a pointed to (n-1) array is a 0dim array.
>
> What p points to is an int. The value of p is the int* value returned by
> "new
> int[4]". That value is a pointer to the first of the four contiguous ints
> that
> were allocated.
>
A pointer of type int* can point to a single int or an array of ints. If you
don't believe that read this:
<quote ref="http://c-faq.com/aryptr/aryptr2.html">
cg_chas
The standard says exactly that. Of course, the section is 5.3.4 not 3.4.5, but
the quote is verbatim.
> Quite the opposite, it
>clearly states that "When the allocated object is an array".
Perhaps you can cite the part of the Standard that you got this quote from?
When I do a search for "When the allocated object is an array" the response I
get is, "No matches were found."
> The object it
>points to is an array of ints.
>You are correct to say it doesn't point to an array-type object, this is
>because a pointer to an array of n-dimensions is of type n-1 dimensions.
>That is:
>A pointer to a 2dim array is of type..... T (*)[dim2]
>A pointer to a 1dim array is of type..... T*
>
>Note that a pointed to (n-1) array is a 0dim array.
>
>>
>> What p points to is an int. The value of p is the int* value returned by
>> "new
>> int[4]". That value is a pointer to the first of the four contiguous ints
>> that
>> were allocated.
>>
>A pointer of type int* can point to a single int or an array of ints. If you
>don't believe that read this:
>
><quote ref="http://c-faq.com/aryptr/aryptr2.html">
>"The pointer declaration char *p, on the other hand, requests a place which
>holds a pointer, to be known by the name ``p''. This pointer can point
>almost anywhere: to any char, or to any contiguous array of chars, or
>nowhere "
></quote>
>
Context is everything.
This citation from the C language FAQ is part of a Q and A. The question asked
in the section of this C FAQ is:
Q "But I heard that char a[] was identical to char *a.
A "Not at all. (What you heard has to do with formal parameters to functions;
see question 6.4.) Arrays are not pointers, though they are closely related (see
question 6.3) and can be used similarly (see questions 4.1, 6.8, 6.10, and
6.14). "
There is your primary context.
The example given for this citation then goes onto say:
"The array declaration char a[6] requests that space for six characters be set
aside, to be known by the name ``a''. That is, there is a location named ``a''
at which six characters can sit. The pointer declaration char *p, on the other
hand, requests a place which holds a pointer, to be known by the name ``p''.
This pointer can point almost anywhere: to any char, or to any contiguous array
of chars, or nowhere [footnote] (see also questions 5.1 and 1.30).
As usual, a picture is worth a thousand words. The declarations
char a[] = "hello";
char *p = "world";
Here is the footnote that you continuously and intentionally neglect to include
in your misplaced citation:
Footnote:
"Don't interpret ``anywhere'' and ``nowhere'' too broadly. To be valid, a
pointer must point to properly allocated memory (see questions 7.1, 7.2, and
7.3); to point definitively nowhere, a pointer must be a null pointer (see
question 5.1). "
You have done just what the footnote said not to do. You are taking a broad
statement out of context from a C-language FAQ and attempting to apply it to a
technical definition that somehow has equal weight to the C++ Standard.
Nice try, but A. Bolmarcich's citation was correct and yours is broad at best,
but clearly not a technical exception to the quoted Standard.
HTH
cg_chas
>The standard doesn't say p doesn't point to an array. Quite the opposite,
We could easily skip to the end of this debate. Look what happens when your
statement is made with too little context.
You are saying:
an int* points to an array
everybody else is saying:
an int* points to an int element of an array
The later is not only clear and technically precise, but the former fails to
distinguish between your abstract view of what an array is and what could be
erronously confused with an array object.
Im sure you will try, but there really is no meaningful argument against
technical correctness in C++.
Paul
>
>> Quite the opposite, it
>>clearly states that "When the allocated object is an array".
> Perhaps you can cite the part of the Standard that you got this quote
> from?
See A. Bolmarcich's quote. Its on the very page, which is why I said it
*clearly* states this.
>
> When I do a search for "When the allocated object is an array" the
> response I
> get is, "No matches were found."
>
I don't care what you search for TBH.
<snip><snip>
> Nice try, but A. Bolmarcich's citation was correct and yours is broad at
> best,
> but clearly not a technical exception to the quoted Standard.
>
Seems like you don't know what you're talking about. TBH you say nothing but
absolute bullshit.
plonk.
Paul
> On Fri, 25 Mar 2011 18:30:21 -0000, "Paul" <pchr...@yahoo.co.uk> wrote:
>
>>The standard doesn't say p doesn't point to an array. Quite the opposite,
> We could easily skip to the end of this debate. Look what happens when
> your
> statement is made with too little context.
>
> You are saying:
> an int* points to an array
>
> everybody else is saying:
> an int* points to an int element of an array
Only a few idiots in here are saying what you are saying that:
An int* points to only a single int and doesn't point to an array.
>
> The later is not only clear and technically precise,
The latter is bullshit and totally incorrect.
<snip>
Leigh Johnston
>
> "cg_chas" <cg_...@hotmail.com> wrote in message
> news:53qpo6p9f7v83tc9n...@4ax.com...
>> On Fri, 25 Mar 2011 18:30:21 -0000, "Paul" <pchr...@yahoo.co.uk> wrote:
>>
>>> The standard doesn't say p doesn't point to an array. Quite the
>>> opposite,
>> We could easily skip to the end of this debate. Look what happens when
>> your
>> statement is made with too little context.
>>
>> You are saying:
>> an int* points to an array
> No I'm saying an int* can point to a single int or an array of integers.
How can it possibly point to anything other than a single int? Its type
is pointer-to-int ergo it can only point to an int (not an array).
>>
>> everybody else is saying:
>> an int* points to an int element of an array
> No everyone else is saying the same as me.
Everyone? Gosh your delusions know no bounds.
> Only a few idiots in here are saying what you are saying that:
> An int* points to only a single int and doesn't point to an array.
If they are saying that (me included) then that does not make them
idiots as what they are saying is correct.
[...]
/Leigh
A. Bolmarcich
>
> "A. Bolmarcich" <agg...@earl-grey.cloud9.net> wrote in message
> news:slrnioplhp....@earl-grey.cloud9.net...
>> On 2011-03-23, Paul <pchr...@yahoo.co.uk> wrote:
>>> No I have proven that you do not only misinterpret and misquote
>>> authorative
>>> texts but you also misunderstand them.
>>> And by proving this I have also proven that you are wrong to say that
>>> p(in
>>> the following example) doesn't point to an array:
>>> int* p = new int[4];
>>
>> Here is paragraph 5 of section 3.4.5, about the new expression, from the
>> 1998
>> C++ standard.
Typo correction: it is section 5.3.4, not 3.4.5.
>>
>> "When the allocated object is an array (that is, the direct-new-declarator
>> syntax is used or the new-type-id or type-id denotes an array type), the
>> new-expression yields a pointer to the initial element (if any) of the
>> array.
>> [Note: both new int and new int [10] have type int* and the type of new
>> int[i]
>> [10] is int (*)[10].]"
>>
>> According to the standard, p (in the example) doesn't point to an array,
>> that
>> is, p does not point to an object with an array type.
>
> The standard doesn't say p doesn't point to an array. Quite the opposite, it
> clearly states that "When the allocated object is an array". The object it
> points to is an array of ints.
> You are correct to say it doesn't point to an array-type object, this is
> because a pointer to an array of n-dimensions is of type n-1 dimensions.
> That is:
> A pointer to a 2dim array is of type..... T (*)[dim2]
> A pointer to a 1dim array is of type..... T*
The standard says that p points to an int, not an array. Accoriding to the
standard "both new int and new int [10] have type int*". After the
initialization, p either points to an int or the value of p is the null
pointer (if the implementaion of new returns the null pointer instead of
throwing a bad_alloc exception).
The int that p points to is an element of an array. An element of an array
is a different entity than the array.
> Note that a pointed to (n-1) array is a 0dim array.
Where does the C++ standard mention array of 0 dimensions?
>>
>> What p points to is an int. The value of p is the int* value returned by
>> "new
>> int[4]". That value is a pointer to the first of the four contiguous ints
>> that
>> were allocated.
>>
> A pointer of type int* can point to a single int or an array of ints. If you
> don't believe that read this:
>
><quote ref="http://c-faq.com/aryptr/aryptr2.html">
> "The pointer declaration char *p, on the other hand, requests a place which
> holds a pointer, to be known by the name ``p''. This pointer can point
> almost anywhere: to any char, or to any contiguous array of chars, or
> nowhere "
></quote>
The faq is not a worded as strictly as a specification. What a char* can
point to is an element of an array of chars, not to an array. Trying to
have a char* point to an array of chars as with
char arr[1];
char *p = &arr;
is a type mismatch.
cg_chas
>
>"cg_chas" <cg_...@hotmail.com> wrote in message
>news:53qpo6p9f7v83tc9n...@4ax.com...
>> On Fri, 25 Mar 2011 18:30:21 -0000, "Paul" <pchr...@yahoo.co.uk> wrote:
>>
>>>The standard doesn't say p doesn't point to an array. Quite the opposite,
>> We could easily skip to the end of this debate. Look what happens when
>> your
>> statement is made with too little context.
>>
>> You are saying:
>> an int* points to an array
>No I'm saying an int* can point to a single int or an array of integers.
Here are the exact words that you have used repeatedly, and I quote:
"If it points to an element in the array then , by definition, it points to
the array."
Not just this quote, seven threads started and filled by you with false
assertions such as this.
>>
>> everybody else is saying:
>> an int* points to an int element of an array
>No everyone else is saying the same as me.
In your mind, who is everyone exactly?
The everyone I refer to is everyone in this discussion that has responded to
you, the words of Stroustrup, the words of Koening, and the words of The C++
Standard, not just myself.
<Paul's insults and vulgarity snipped>
cg_chas
typo: Koenig
Paul
changing the meaning by adding ... "not an array".. to this.
This misinterpreted meaning is compeletly wrong , see my attached quote, and
there are lots of other quotes around from people like Bjarne Stroustrup
that state the same.
> Accoriding to the
> standard "both new int and new int [10] have type int*".
Exaclty , the pointer type int* can point to a single int or an array of
int.
No its bad programming.
char* p = arr;
is how its done.
p points to an array of elements not only a single int, if you don't accept
quotes from recognised autohriities and the C++ standards I don't have
anything more to say.
See the thread titled "You missed something " for the quotes from the
standard I refer to.
cg_chas
He has not changed the meaning, he simply has asserted that the Standard has
given a strict definition of "what is".
It is you that is making the assertion that the Standard also silently implies
this additional other meaning.
<pruned the rest which is predicated on Paul's false assertion>
Garrett Hartshaw
wrote:
The first element of an array *is not* an array.
A pointer to the first element of an array *is not* a pointer to an
array.
A pointer to the first element of an array *is not* an array.
A array *can be converted to* a pointer to the first element of an
array.
Paul
"Garrett Hartshaw" <ghar...@gmail.com> wrote in message
news:almarsoft.2721...@nntp.aioe.org...
an array.
> A pointer to the first element of an array *is not* a pointer to an array.
Yes it is. How can it not point to the array if it points to an element
within the array?
> A pointer to the first element of an array *is not* an array.
Nobody said it was. Its a pointer to an array.
> A array *can be converted to* a pointer to the first element of an array.
An array is a contiguous array of elements in memory, It can be "converted"
to almost anything.
If you cannot understand that an pointer to an element within an array also
points to the array, then you need to give up programming.
plonk
Bo Persson
Paul is right and everybody else is wrong, including the standard.
Live with it! :-)
Bo Persson
Lasse Reichstein Nielsen
> "Garrett Hartshaw" <ghar...@gmail.com> wrote in message
> news:almarsoft.2721...@nntp.aioe.org...
>> The first element of an array *is not* an array.
> The first element of an array is an element of an array. Nobody said
> it was an array.
>
>> A pointer to the first element of an array *is not* a pointer to an array.
> Yes it is. How can it not point to the array if it points to an
> element within the array?
You are using everyday "common" logic here.
If I point at your arm, I also point at you.
That's the everyday meaning of pointing.
This is a technical discussion about a subject (C++) where some common
words have been given more precise meaning.
When medics on the job talk about "shock", they don't mean the same as
the common usage ("I was shocked to discover ..."), but the more
precise medical condition: http://en.wikipedia.org/wiki/Shock_(circulatory)
When computer scientists and programmers talk about "pointing" in C++,
they don't mean the common usage (identifying something by gesturing),
but a more precise and exclusive meaning: having a pointer of a specific
pointer type hold the address of an object of the type pointed to.
So an int pointer points to an int.
An int[4] pointer points to an array of length 4 of ints.
A pointer to the first element of an array of ints points to an int.
It does not point to the array (in the language of C++, which is what
is used here). It can be said to point INTO the array. That's not
the same as pointing to the array, because "pointing to X" has a specific
meaning here.
>> A pointer to the first element of an array *is not* an array.
> Nobody said it was. Its a pointer to an array.
No, it's a pointer to the first element. It's a pointer into the array.
It is not the array.
>> A array *can be converted to* a pointer to the first element of an array.
> An array is a contiguous array of elements in memory, It can be
> "converted" to almost anything.
True, but a variable referring to the array can be converted to a value
that is a pointer to the first element.
> If you cannot understand that an pointer to an element within an array
> also points to the array, then you need to give up programming.
Nope. In *programming*, that's the exact correct thing to say. It's
different from the common usage of "pointing", but "pointer" in C++
isn't a common word. In this context, it's a technical term with a
specific meaning that doesn't mean what the common word "pointer" does
in everyday language.
Just as we, rightly, ridicule geologist that come into non-geology
groups and insist that a "rock" must be between 2.5 and 5 cm in
diameter, otherwise it's called something else[1], for taking their
tecnical jargon into an everyday discussion, it's also wrong to
take everyday speech into a technical discussion. You can do it, but
you won't be understood, because you use words that mean something
different than what you think in the context where you have put them.
/L
[1] As example, I don't remember the exact details, and details might also
be language dependent.
--
Lasse Reichstein Holst Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Paul
"Bo Persson" <b...@gmb.dk> wrote in message
news:8v5v7d...@mid.individual.net...
that.
Paul
"Lasse Reichstein Nielsen" <lrn.u...@gmail.com> wrote in message
news:sjuajf...@gmail.com...
> "Paul" <pchr...@yahoo.co.uk> writes:
>
>> "Garrett Hartshaw" <ghar...@gmail.com> wrote in message
>> news:almarsoft.2721...@nntp.aioe.org...
>
>>> The first element of an array *is not* an array.
>> The first element of an array is an element of an array. Nobody said
>> it was an array.
>>
>>> A pointer to the first element of an array *is not* a pointer to an
>>> array.
>> Yes it is. How can it not point to the array if it points to an
>> element within the array?
>
> You are using everyday "common" logic here.
> If I point at your arm, I also point at you.
> That's the everyday meaning of pointing.
>
> This is a technical discussion about a subject (C++) where some common
> words have been given more precise meaning.
> When medics on the job talk about "shock", they don't mean the same as
> the common usage ("I was shocked to discover ..."), but the more
> precise medical condition:
> http://en.wikipedia.org/wiki/Shock_(circulatory)
>
> When computer scientists and programmers talk about "pointing" in C++,
> they don't mean the common usage (identifying something by gesturing),
> but a more precise and exclusive meaning: having a pointer of a specific
> pointer type hold the address of an object of the type pointed to.
Bollocks a pointer in computer programming is an indirect accessor to a
memory area.
>
> So
So STFU, you are wrong and all the experts agree with me and so does the C++
standard.
> an int pointer points to an int.
> An int[4] pointer points to an array of length 4 of ints.
> A pointer to the first element of an array of ints points to an int.
> It does not point to the array (in the language of C++, which is what
> is used here). It can be said to point INTO the array. That's not
> the same as pointing to the array, because "pointing to X" has a specific
> meaning here.
>
<snip bollocks>
Paul
>
>> "Garrett Hartshaw" <ghar...@gmail.com> wrote in message
>> news:almarsoft.2721...@nntp.aioe.org...
>
>>> The first element of an array *is not* an array.
>> The first element of an array is an element of an array. Nobody said
>> it was an array.
>>
>>> A pointer to the first element of an array *is not* a pointer to an
>>> array.
>> Yes it is. How can it not point to the array if it points to an
>> element within the array?
>
> You are using everyday "common" logic here.
> If I point at your arm, I also point at you.
> That's the everyday meaning of pointing.
>
> This is a technical discussion about a subject (C++) where some common
> words have been given more precise meaning.
> When medics on the job talk about "shock", they don't mean the same as
> the common usage ("I was shocked to discover ..."), but the more
> precise medical condition:
> http://en.wikipedia.org/wiki/Shock_(circulatory)
>
> When computer scientists and programmers talk about "pointing" in C++,
> they don't mean the common usage (identifying something by gesturing),
> but a more precise and exclusive meaning: having a pointer of a specific
> pointer type hold the address of an object of the type pointed to.
Bollocks a pointer in computer programming is an indirect accessor to a
memory area.
>
> So
So STFU, you are wrong and all the experts agree with me and so does the C++
standard.
> an int pointer points to an int.
> An int[4] pointer points to an array of length 4 of ints.
> A pointer to the first element of an array of ints points to an int.
> It does not point to the array (in the language of C++, which is what
> is used here). It can be said to point INTO the array. That's not
> the same as pointing to the array, because "pointing to X" has a specific
> meaning here.
>
<snip bollocks>
A. Bolmarcich
>
> "A. Bolmarcich" <agg...@earl-grey.cloud9.net> wrote in message
> news:slrnioprsv....@earl-grey.cloud9.net...
>> On 2011-03-25, Paul <pchr...@yahoo.co.uk> wrote:
>> The standard says that p points to an int, not an array.
> No it doesn't is says it points to the first element of an array, You are
> changing the meaning by adding ... "not an array".. to this.
> This misinterpreted meaning is compeletly wrong , see my attached quote, and
> there are lots of other quotes around from people like Bjarne Stroustrup
> that state the same.
Yes, it does. Here is the relevant quote from the C++ standard again: "[Note:
both new int and new int [10] have type int* and the type of new int[i][10] is
int (*)[10].]"
The expression "new int [10]" returns a value of type int*. It is a pointer to
an int. It is not a pointer to an array. The expression "new int[i][10]"
returns a pointer to an array.
I did not change the meaning by adding "not an array". I added it to
emphasize that a pointer to an int and a pointer to an array are different
types of pointers.
>> Accoriding to the
>> standard "both new int and new int [10] have type int*".
> Exaclty , the pointer type int* can point to a single int or an array of
> int.
A valid, non null pointer to a type may point only to an object of that
type. It may not also point to a different type. A pointer to an int and a
pointer to an array of int are differnt types of pointers.
<snip>
>> The faq is not a worded as strictly as a specification. What a char* can
>> point to is an element of an array of chars, not to an array. Trying to
>> have a char* point to an array of chars as with
>>
>> char arr[1];
>> char *p = &arr;
>>
>> is a type mismatch.
>
> No its bad programming.
> char* p = arr;
> is how its done.
In that declaration p is a pointer to a char, not a pointer to an array. The
initialization expression undergoes the standard array-to-pointer conversion
described in section 4.2 of the C++ standard. The result of that conversion
is a pointer of type char* to the first element of the array. A pointer to
a char is not a pointer to an array; they are different types of pointers.
> p points to an array of elements not only a single int, if you don't accept
> quotes from recognised autohriities and the C++ standards I don't have
> anything more to say.
No, p points to a char; a pointer to an array is a different type of pointer.
I have posted quotes from the C++ standard relevant to declarations like
"char *p = arr".
> See the thread titled "You missed something " for the quotes from the
> standard I refer to.
As far as I can tell there in no recent thread titled "You missed something";
there is one titled "You snipped something". Quotes you posted there, such as
"If the * operator, either explicitly or implicitly as
a result of subscripting, is applied to this pointer, the result is the
pointedto (n - 1 )dimensional array"
and
"the subscript operator [] is interpreted in such a way that E1[E2] is
identical to *((E1)+(E2))"
have nothing to do with declarations like
int *p = new int[4]
that my posts have been about.
In the quote "If the * operator ..." you omitted the first sentence of the
paragraph: "A consistent rule is followed for multidimensional arrays." What
you quoted applies to multidimensional arrays; it does not apply to arrays of
one dimension.
Öö Tiib
> "Garrett Hartshaw" <gharts...@gmail.com> wrote:
>
> > A array *can be converted to* a pointer to the first element of an array.
>
> An array is a contiguous array of elements in memory, It can be "converted"
> to almost anything.
Similarly a pointer is an address of memory so it can point to almost
anything?
> If you cannot understand that an pointer to an element within an array also
> points to the array, then you need to give up programming.
If you can not communicate with other people normally then you should
give up doing anything ... since you will inevitably fail. Even if
what you say is smart for them it sounds nonsense.
Paul, i have some yes/no questions about your usage of terms. I put
them into example code as comments. I added some asserts into code
that sort of "prove" that all questions should be answered with "yes".
It is unlikely that you find a platform where the assertions are
violated.
#include <cassert>
struct X { int sole; int bag[5]; bool ok; };
int main()
{
X x = {-1, {0,1,2,3,4}, true};
int* p = &x.sole;
// 1) Does p point to value -1?
assert( *p == -1 );
// 2) Does p point to whole stucture x?
assert( (char*)p == (char*)x );
// 3) Does p also point to int array in that structure?
assert( p == &x.bag[-1] );
++p;
// 4) Since we incremented p is it now an array?
assert( p == x.bag );
}
I think that the words are just symbols of communication.
Communication is possible only if all sides understand the meaning in
same way. So you can not "prove" what some sentence means ... all you
can do is to agree about it with rest of participants in discussion.
Öö Tiib
> Â Â Â // 2) Does p point to whole stucture x?
> Â Â Â assert( (char*)p == (char*)x );
fix, should be (char*)&x
Paul
> On 2011-03-25, Paul <pchr...@yahoo.co.uk> wrote:
>>
>> "A. Bolmarcich" <agg...@earl-grey.cloud9.net> wrote in message
>> news:slrnioprsv....@earl-grey.cloud9.net...
>>> On 2011-03-25, Paul <pchr...@yahoo.co.uk> wrote:
> <snip>
>>> The standard says that p points to an int, not an array.
>> No it doesn't is says it points to the first element of an array, You are
>> changing the meaning by adding ... "not an array".. to this.
>> This misinterpreted meaning is compeletly wrong , see my attached quote,
>> and
>> there are lots of other quotes around from people like Bjarne Stroustrup
>> that state the same.
>
> Yes, it does. Here is the relevant quote from the C++ standard again:
> "[Note:
> both new int and new int [10] have type int* and the type of new
> int[i][10] is
> int (*)[10].]"
This says exactly what I have said , that an int* can point to an int or an
array of int.
And also it confirms that, when dereferenced, a pointer to an array returns
a pointed to (n-1)dimensional array.
>
> The expression "new int [10]" returns a value of type int*. It is a
> pointer to
> an int. It is not a pointer to an array.
It is a pointer to a 1dimensional array. It is also a pointer to an int
within the array.
> The expression "new int[i][10]"
> returns a pointer to an array.
This expression returns a pointer to a 2dimensional array.
>
> I did not change the meaning by adding "not an array".
Yes you did.
> I added it to
> emphasize that a pointer to an int and a pointer to an array are different
> types of pointers.
Not when it's a 1dimensional array.
>
>>> Accoriding to the
>>> standard "both new int and new int [10] have type int*".
>> Exaclty , the pointer type int* can point to a single int or an array of
>> int.
>
> A valid, non null pointer to a type may point only to an object of that
> type.
This is rubbish, you disagree with many experts includng Bjarne Stroustrup,
I quote:
<quote ref: http://www2.research.att.com/~bs/glossary.html>
char* - pointer to a char or an array of char.
</quote>
> It may not also point to a different type. A pointer to an int and a
> pointer to an array of int are differnt types of pointers.
Not when its a 1dimensional array.
>
> <snip>
>
>>> The faq is not a worded as strictly as a specification. What a char*
>>> can
>>> point to is an element of an array of chars, not to an array. Trying to
>>> have a char* point to an array of chars as with
>>>
>>> char arr[1];
>>> char *p = &arr;
>>>
>>> is a type mismatch.
>>
>> No its bad programming.
>> char* p = arr;
>> is how its done.
>
> In that declaration p is a pointer to a char, not a pointer to an array.
> The
> initialization expression undergoes the standard array-to-pointer
> conversion
> described in section 4.2 of the C++ standard. The result of that
> conversion
> is a pointer of type char* to the first element of the array. A pointer
> to
> a char is not a pointer to an array; they are different types of pointers.
You disagree with Bjarne Stroustrup and every other C++ programmer, with a
brain, on the planet.
You also disagree with the C++ standards defintion that a dereferenced array
pointer will return the pointed to (n-1)dimension array.
>
>> p points to an array of elements not only a single int, if you don't
>> accept
>> quotes from recognised autohriities and the C++ standards I don't have
>> anything more to say.
>
> No, p points to a char; a pointer to an array is a different type of
> pointer.
> I have posted quotes from the C++ standard relevant to declarations like
> "char *p = arr".
>
>> See the thread titled "You missed something " for the quotes from the
>> standard I refer to.
>
> As far as I can tell there in no recent thread titled "You missed
> something";
> there is one titled "You snipped something". Quotes you posted there,
> such as
>
> "If the * operator, either explicitly or implicitly as
> a result of subscripting, is applied to this pointer, the result is the
> pointedto (n - 1 )dimensional array"
>
> and
>
> "the subscript operator [] is interpreted in such a way that E1[E2] is
> identical to *((E1)+(E2))"
>
> have nothing to do with declarations like
It has everthing to do with it , you say int* cannot point to an array but
the standard says different , the standard says that if a pointer to an
array is dereferneced if returns the pointed to (n-1) array.
1-1 = 0
That is, when dereferneced, a pointer to a 1dimensional array will return a
0dimensional array. Which is exactly what int* does.
In your theory what exactly is a pointer to a 1dimensional array, that
conforms to this rule of the standard?
>
> int *p = new int[4]
>
> that my posts have been about.
>
> In the quote "If the * operator ..." you omitted the first sentence of the
> paragraph: "A consistent rule is followed for multidimensional arrays."
> What
> you quoted applies to multidimensional arrays; it does not apply to arrays
> of
> one dimension.
A "*consistent* rule applies" means "the same rule applies".
cg_chas
>
>"A. Bolmarcich" <agg...@earl-grey.cloud9.net> wrote in message
>news:slrnios40v....@earl-grey.cloud9.net...
>> On 2011-03-25, Paul <pchr...@yahoo.co.uk> wrote:
>>>
>>> "A. Bolmarcich" <agg...@earl-grey.cloud9.net> wrote in message
>>> news:slrnioprsv....@earl-grey.cloud9.net...
>>>> On 2011-03-25, Paul <pchr...@yahoo.co.uk> wrote:
>> <snip>
>>>> The standard says that p points to an int, not an array.
>>> No it doesn't is says it points to the first element of an array, You are
>>> changing the meaning by adding ... "not an array".. to this.
>>> This misinterpreted meaning is compeletly wrong , see my attached quote,
>>> and
>>> there are lots of other quotes around from people like Bjarne Stroustrup
>>> that state the same.
>>
>> Yes, it does. Here is the relevant quote from the C++ standard again:
>> "[Note:
>> both new int and new int [10] have type int* and the type of new
>> int[i][10] is
>> int (*)[10].]"
>
>This says exactly what I have said , that an int* can point to an int or an
>array of int.
Paul, once again you are wrong of course. The Standard addresses this case
explicitly.
From the '03 C++ Standard 5.3.4 5th paragraph
"When the allocated object is an array (that is, the direct-new-declarator
syntax is used or the new-type-id or type-id denotes an array type), the
new-expression yields a pointer to the initial element (if any) of the array.
[Note: both new int and new int[10] have type int* and the type of new
int[i][10] is int (*)[10]. ]"
Specifically: "yields a pointer to the initial element"
Any other implied meanings that you wish to add to this statement are meaningful
in your head and your head only. The _growing_ list of competent C++
programmers who have replied to you seem to agree.
I would reference Öö Tiib's responses in particular. His logic also makes
distinctions that you fail to understand.
It should be noted that "yields a pointer to the initial element" is the
identical language used in TCPPPL and Accelerated C++.
<snipped the rest which is predicated on Paul's feelings as to how the Standard
should be worded versus what the Standard actually says>
Paul
"cg_chas" <cg_...@hotmail.com> wrote in message
news:v0mso65qva5gfoduh...@4ax.com...
It doesn't say the pointer not a pointer to the array, which is what you are
saying . You are the one who is technically inaccurate and incorrect.
>
> Any other implied meanings that you wish to add to this statement are
> meaningful
> in your head and your head only. The _growing_ list of competent C++
> programmers who have replied to you seem to agree.
The only implied meanings that have been added are by you and a few other
idiots who imply this means the pointer is not a pointer to the array.
>
> I would reference Öö Tiib's responses in particular. His logic also makes
> distinctions that you fail to understand.
You can reference whatever the fuck you like , its obvious to anyone , with
a brian , that reads this who fails to understand.
>
> It should be noted that "yields a pointer to the initial element" is the
> identical language used in TCPPPL and Accelerated C++.
It should be noted that you don't know what the fuck you are talking about ,
you are a complete arsehole and an idiot who has no place in any respected
C++ community.
>
> <snipped the rest which is predicated on Paul's feelings as to how the
> Standard
> should be worded versus what the Standard actually says>
No you are one suggesting the pointer does not point to an array.
I shall be deleting your posts without reading them from now on.
Plonk.
cg_chas
My quote is directly from the Standard, what I say is not the point here, what
the Standard says is.
>
>>
>> Any other implied meanings that you wish to add to this statement are
>> meaningful
>> in your head and your head only. The _growing_ list of competent C++
>> programmers who have replied to you seem to agree.
>
>The only implied meanings that have been added are by you and a few other
>idiots who imply this means the pointer is not a pointer to the array.
>
>>
>> I would reference 嘱 Tiib's responses in particular. His logic also makes
>> distinctions that you fail to understand.
>
>You can reference whatever the fuck you like , its obvious to anyone , with
>a brian , that reads this who fails to understand.
I am sure that Brian would agree that your reasoning skills are as equally poor
as your spelling. :)
>
>>
>> It should be noted that "yields a pointer to the initial element" is the
>> identical language used in TCPPPL and Accelerated C++.
>
>It should be noted that you don't know what the fuck you are talking about ,
>you are a complete arsehole and an idiot who has no place in any respected
>C++ community.
>
>>
>> <snipped the rest which is predicated on Paul's feelings as to how the
>> Standard
>> should be worded versus what the Standard actually says>
>
>No you are one suggesting the pointer does not point to an array.
>
>I shall be deleting your posts without reading them from now on.
Please do, but who are we kidding, you'll read my posts :)
Somebody who obviously has a brain recently said, "If you can not communicate
with other people normally then you should give up doing anything ... since you
will inevitably fail. Even if what you say is smart for them it sounds
nonsense."
While you're busy deleting my posts that you will say that haven't read, you
should remember the above quote that you read from this post.
A. Bolmarcich
>
> "A. Bolmarcich" <agg...@earl-grey.cloud9.net> wrote in message
> news:slrnios40v....@earl-grey.cloud9.net...
>> On 2011-03-25, Paul <pchr...@yahoo.co.uk> wrote:
>>>
>>> "A. Bolmarcich" <agg...@earl-grey.cloud9.net> wrote in message
>>> news:slrnioprsv....@earl-grey.cloud9.net...
>>
>> Yes, it does. Here is the relevant quote from the C++ standard again:
>> "[Note:
>> both new int and new int [10] have type int* and the type of new
>> int[i][10] is
>> int (*)[10].]"
>
> This says exactly what I have said , that an int* can point to an int or an
> array of int.
> And also it confirms that, when dereferenced, a pointer to an array returns
> a pointed to (n-1)dimensional array.
The quote says nothing about whether an int* can point to an int or an array
of int. It says
- new int returns an int*
- new int[10] returns an int*
- new int[i][10] returns an int (*)[10]
The quote says nothing about the result of dereferencing an array.
>> The expression "new int[i][10]"
>> returns a pointer to an array.
> This expression returns a pointer to a 2dimensional array.
According to the standard, "new int[i][10]" returns a "int (*)[10]",
a pointer to a 1-dimensional array. An example of a pointer to a
2-dimensional array is "int (*)[1][2]". Note the difference in the
number of square brackets.
>> I did not change the meaning by adding "not an array".
> Yes you did.
>
>> I added it to
>> emphasize that a pointer to an int and a pointer to an array are different
>> types of pointers.
> Not when it's a 1dimensional array.
A pointer to an int (int*) and a pointer to a 1-dimensional array
(int (*)[]) are different types of pointers. The result of
dereferencing the former an int; the result of dereferencing the
latter is an array. Whether the array is 1-dimensional does not
make a difference.
[snip]
>> A valid, non null pointer to a type may point only to an object of that
>> type.
> This is rubbish, you disagree with many experts includng Bjarne Stroustrup,
> I quote:
><quote ref: http://www2.research.att.com/~bs/glossary.html>
> char* - pointer to a char or an array of char.
></quote>
You omitted the following sentences of that glossary entry.
"Typically assumed to point to a C-style string. Prefer a standard
library string over a C-style string when you can. TC++PL 2.3.3,
13.5.2."
The context of the glossary entry is C-style strings. A char* that
points to a C-style string points to the first character of a zero
termainate array of characters.
That glossary does not have a similar entries for any other pointer
type. Those other pointer types are not used in a way similar to
how a char* is used with a C-style string.
>> It may not also point to a different type. A pointer to an int and a
>> pointer to an array of int are differnt types of pointers.
> Not when its a 1dimensional array.
If a pointer to an int and a pointer to a 1-dimensional array of int
were the same type of pointer, given the declaration
int *pi, (*pai)[1];
the assignment
pi = pai
would be allowed, but it isn't. The array being a 1-dimensional
one does not make a difference.
[snip]
>>> No its bad programming.
>>> char* p = arr;
>>> is how its done.
>>
>> In that declaration p is a pointer to a char, not a pointer to an array.
>> The
>> initialization expression undergoes the standard array-to-pointer
>> conversion
>> described in section 4.2 of the C++ standard. The result of that
>> conversion
>> is a pointer of type char* to the first element of the array. A pointer
>> to
>> a char is not a pointer to an array; they are different types of pointers.
> You disagree with Bjarne Stroustrup and every other C++ programmer, with a
> brain, on the planet.
> You also disagree with the C++ standards defintion that a dereferenced array
> pointer will return the pointed to (n-1)dimension array.
With a declaration like that, char *p = arr (where arr is an array of
char), Bjarne Stroustrup and I agree. Here is part of an example on
page 92 of his "The C++ Programmng Language - Special Edition".
char v[] = "Annemarie";
char *p = v; // implicit conversion of char[] to char*
He and I used different words ("implicit conversion" versus "undergoes
the standard array-to-pointer conversion") with the same meaning.
A comment about "a dereferenced array pointer will return the
pointed to (n-1)dimension array" is later in this followup.
[snip]
>>> See the thread titled "You missed something " for the quotes from the
>>> standard I refer to.
>>
>> As far as I can tell there in no recent thread titled "You missed
>> something";
>> there is one titled "You snipped something". Quotes you posted there,
>> such as
>>
>> "If the * operator, either explicitly or implicitly as
>> a result of subscripting, is applied to this pointer, the result is the
>> pointedto (n - 1 )dimensional array"
>>
>> and
>>
>> "the subscript operator [] is interpreted in such a way that E1[E2] is
>> identical to *((E1)+(E2))"
>>
>> have nothing to do with declarations like
[reinsert lines that immediately followed the previous line]
>>
>> int *p = new int[4]
>>
>> that my posts have been about.
[end reinsert]
>
> It has everthing to do with it , you say int* cannot point to an array but
> the standard says different , the standard says that if a pointer to an
> array is dereferneced if returns the pointed to (n-1) array.
> 1-1 = 0
> That is, when dereferneced, a pointer to a 1dimensional array will return a
> 0dimensional array. Which is exactly what int* does.
It has nothing to do with those quotes from the standard because those
quotes are about the unary * operator and the subscript operator [],
but neither of those operators are in the declaration
int *p = new int[4]
What I have said is that a pointer to an int and a pointer to an
array of int are two different pointer types. A pointer to an int
can point to an element of an array of int, but that is not the same
as pointing to an array. A pointer to an array of int has a type of
the form
int (*)[]
which is not the same type as int*.
Where does the C++ standard mention 0-dimensional arrays? As far as
I can tell, arrays in C++ must have at least one dimension.
> In your theory what exactly is a pointer to a 1dimensional array, that
> conforms to this rule of the standard?
The paragraph of the standard that the rule is in starts with: "A
consistent rule is followed for multidimensional arrays." The rule
applies to multidimensional arrays. The following are declarations
of a pointer to a 1-dimensional array of int and a 2-dimensional
array of int.
int (*pa1i)[6], int a2i[2][6];
The standard allows the assignment
pa1i = a2i;
According to the rule, the expression a2i is converted from a
2-dimensional array (of type int[2][6]) to a pointer to a
1-dimensional array (of type int(*)[6]).
>> In the quote "If the * operator ..." you omitted the first sentence of the
>> paragraph: "A consistent rule is followed for multidimensional arrays."
>> What
>> you quoted applies to multidimensional arrays; it does not apply to arrays
>> of
>> one dimension.
>
> A "*consistent* rule applies" means "the same rule applies".
The rule applies to all mulidemsional arrays. A 1-dimensional array is not
a multidimensional array.
Paul
It clearly shows that a pointer to a 1dim array of int, is the same type as
a pointer to a single int.
>>> The expression "new int[i][10]"
>>> returns a pointer to an array.
>> This expression returns a pointer to a 2dimensional array.
>
> According to the standard, "new int[i][10]" returns a "int (*)[10]",
> a pointer to a 1-dimensional array. An example of a pointer to a
> 2-dimensional array is "int (*)[1][2]". Note the difference in the
> number of square brackets.
No the standard doesn't say that a pointer of type int (*)[size] points to a
1dim array. Quite the opposite.
>
>>> I did not change the meaning by adding "not an array".
>> Yes you did.
>>
>>> I added it to
>>> emphasize that a pointer to an int and a pointer to an array are
>>> different
>>> types of pointers.
>> Not when it's a 1dimensional array.
>
> A pointer to an int (int*) and a pointer to a 1-dimensional array
> (int (*)[]) are different types of pointers.
No you are confused by a pointer to object of array-type and a pointer to an
actuall array.
A pointer of type int (*)[size] is a pointer to a 2dim array, it also points
to an object of type int[size].
See the post entitled , "you snipped something" for clarification of how the
C++ standard defines this.
<snip>
.
A. Bolmarcich
>
> "A. Bolmarcich" <agg...@earl-grey.cloud9.net> wrote in message
> news:slrnip1h84....@earl-grey.cloud9.net...
>> On 2011-03-26, Paul <pchr...@yahoo.co.uk> wrote:
>>
>> The quote says nothing about whether an int* can point to an int or an
>> array
>> of int. It says
>>
>> - new int returns an int*
>> - new int[10] returns an int*
>> - new int[i][10] returns an int (*)[10]
>>
>> The quote says nothing about the result of dereferencing an array.
>>
>
> It clearly shows that a pointer to a 1dim array of int, is the same type as
> a pointer to a single int.
If the pointer to a 1-dimensional array of were the same type as a pointer
to a single int, then given the declaration
int *i, ai[4];
Then the following assignment of a pointer to a 1-dimensional array of int
to a pointer to an int would be allowed
i = &ai;
but it is not allowed.
>>
>> According to the standard, "new int[i][10]" returns a "int (*)[10]",
>> a pointer to a 1-dimensional array. An example of a pointer to a
>> 2-dimensional array is "int (*)[1][2]". Note the difference in the
>> number of square brackets.
>
>
> No the standard doesn't say that a pointer of type int (*)[size] points to a
> 1dim array. Quite the opposite.
The type int (*)[size] is a pointer (the * part) to a 1-dimensional array
of size (the [size] part) of int.
>> A pointer to an int (int*) and a pointer to a 1-dimensional array
>> (int (*)[]) are different types of pointers.
> No you are confused by a pointer to object of array-type and a pointer to an
> actuall array.
> A pointer of type int (*)[size] is a pointer to a 2dim array, it also points
> to an object of type int[size].
An object of type int [size] is a 1-dimensional array of int. A pointer to
it, namely int (*)[size], is a pointer to a 1-dimensonal array, not to a
2-dimensional array.
> See the post entitled , "you snipped something" for clarification of how the
> C++ standard defines this.
>
><snip>
I have read that post. Your immediately preceding <snip> snipped lines
that addressed that post. If you want to discuss what I wrote, don't snip
relevant lines in your followup.
Paul
> On 2011-03-28, Paul <pchr...@yahoo.co.uk> wrote:
>>
>> "A. Bolmarcich" <agg...@earl-grey.cloud9.net> wrote in message
>> news:slrnip1h84....@earl-grey.cloud9.net...
>>> On 2011-03-26, Paul <pchr...@yahoo.co.uk> wrote:
>>> [snip]
>>>
>>> The quote says nothing about whether an int* can point to an int or an
>>> array
>>> of int. It says
>>>
>>> - new int returns an int*
>>> - new int[10] returns an int*
>>> - new int[i][10] returns an int (*)[10]
>>>
>>> The quote says nothing about the result of dereferencing an array.
>>>
>>
>> It clearly shows that a pointer to a 1dim array of int, is the same type
>> as
>> a pointer to a single int.
>
> If the pointer to a 1-dimensional array of were the same type as a pointer
> to a single int, then given the declaration
>
> int *i, ai[4];
>
> Then the following assignment of a pointer to a 1-dimensional array of int
> to a pointer to an int would be allowed
>
> i = &ai;
>
> but it is not allowed.
When you take the address of something you introduce another level of
indirection.
int x =5;
int* px = &x;
int** ppx = &px;
int*** pppx = &ppx;
If you try to take the address of an arrayobject you get a pointer type
which is different in levels of indirection.
int arr[6][6]; /*This is an array-object*/
int (*parr)[6] = arr; /*This is a pointer to THE array*/
int (*pparr)[6][6] = &arr; /*This is a pointer to an array-object*/
std::cout<< arr << std::endl << parr << std::endl << pparr;
All point to the same thing.
Each identifier points to the same array, but they are different levels of
indirection.
The same applies to 1dim arrays:
int arr[6]; /*array object*/
int* parr= arr; /*pointer to THE array*/
int (*pparr) =&arr; /*pointer to array object*/
This C++ standard confirms, in section 8.3.4 para 7, that a dereferenced
array object is always (n-1) dimensions of the pointed to array.
If you don't accpet what's in the standards I don't know what more I can
say.
<snip>
A. Bolmarcich
>
> "A. Bolmarcich" <agg...@earl-grey.cloud9.net> wrote in message
> news:slrnip1s22....@earl-grey.cloud9.net...
>> On 2011-03-28, Paul <pchr...@yahoo.co.uk> wrote:
>>
>> If the pointer to a 1-dimensional array of were the same type as a pointer
>> to a single int, then given the declaration
>>
>> int *i, ai[4];
>>
>> Then the following assignment of a pointer to a 1-dimensional array of int
>> to a pointer to an int would be allowed
>>
>> i = &ai;
> No this would yield a pointer type of a different level of indirection.
Applying the unary & operator results in a pointer to its operand. In the
example the operand (ai) is a 1-dimensional array, making the result of
applying the & operator a pointer to a 1-dimensional array.
>>
>> but it is not allowed.
>
> When you take the address of something you introduce another level of
> indirection.
> int x =5;
> int* px = &x;
> int** ppx = &px;
> int*** pppx = &ppx;
>
> If you try to take the address of an arrayobject you get a pointer type
> which is different in levels of indirection.
Right, taking the address of an array gives a pointer to the array.
> int arr[6][6]; /*This is an array-object*/
> int (*parr)[6] = arr; /*This is a pointer to THE array*/
It is a pointer to the first element of an array of 6 int[6] elements.
> int (*pparr)[6][6] = &arr; /*This is a pointer to an array-object*/
It is a pointer to a 2-dimensional (6 by 6) array of int.
> std::cout<< arr << std::endl << parr << std::endl << pparr;
> All point to the same thing.
Right, the addresses are all the same value, but each pointer is a
different type. If you increment parr, the byte address increases by
6*sizeof(int). If you increment pparr, the byte address increases by
6*6*sizeof(int).
> Each identifier points to the same array, but they are different levels of
> indirection.
Each identifier points to the same address, but parr is a pointer to a
1-dimensional array and pparr is a pointer to a 2-dimensional array.
> The same applies to 1dim arrays:
> int arr[6]; /*array object*/
> int* parr= arr; /*pointer to THE array*/
It points to the first element of the array. When the initialization
expression is evaluated, the standard array-to-pointer conversion occurs,
resulting in a pointer to the first element of the array, not a pointer
to the array.
> int (*pparr) =&arr; /*pointer to array object*/
It is a pointer to a 1-dimensional array of 6 ints.
> This C++ standard confirms, in section 8.3.4 para 7, that a dereferenced
> array object is always (n-1) dimensions of the pointed to array.
> If you don't accpet what's in the standards I don't know what more I can
> say.
I accept what is written in the C++ standard. In an earlier followup I
gave an example where that paragraph applied. I also accept what is
written in paragraph 1 of section 4.2:
An lvalue or rvalue of type "array of N T" or "array of unknown
bound of T" can be converted to an rvalue of type "pointer to T."
The result is a pointer to the first element of the array.
An example where the paragraph applies is the initialization expression
in the second of the following two declarations.
int arr[6];
int *parr = arr;
According to the standard, the result of the conversion is a "pointer to the
first element of the array" not a "pointer to the array".
Paul
> On 2011-03-28, Paul <pchr...@yahoo.co.uk> wrote:
>>
>> "A. Bolmarcich" <agg...@earl-grey.cloud9.net> wrote in message
>> news:slrnip1s22....@earl-grey.cloud9.net...
>>> On 2011-03-28, Paul <pchr...@yahoo.co.uk> wrote:
>>>
>>> If the pointer to a 1-dimensional array of were the same type as a
>>> pointer
>>> to a single int, then given the declaration
>>>
>>> int *i, ai[4];
>>>
>>> Then the following assignment of a pointer to a 1-dimensional array of
>>> int
>>> to a pointer to an int would be allowed
>>>
>>> i = &ai;
>> No this would yield a pointer type of a different level of indirection.
>
> Applying the unary & operator results in a pointer to its operand. In the
> example the operand (ai) is a 1-dimensional array, making the result of
> applying the & operator a pointer to a 1-dimensional array.
>
value is no different. It points to exactly the same place.
>>>
>>> but it is not allowed.
>>
>> When you take the address of something you introduce another level of
>> indirection.
>> int x =5;
>> int* px = &x;
>> int** ppx = &px;
>> int*** pppx = &ppx;
>>
>> If you try to take the address of an arrayobject you get a pointer type
>> which is different in levels of indirection.
>
> Right, taking the address of an array gives a pointer to the array.
Yes but you don't seem to accept what I was explaining, that is..It
introduces another level of indirection.
>
>> int arr[6][6]; /*This is an array-object*/
>> int (*parr)[6] = arr; /*This is a pointer to THE array*/
>
> It is a pointer to the first element of an array of 6 int[6] elements.
Its a pointer to the array, It can point to any part of the array becuase
its an l-value.
>
>> int (*pparr)[6][6] = &arr; /*This is a pointer to an array-object*/
>
> It is a pointer to a 2-dimensional (6 by 6) array of int.
This is a different level of indirection. If I dereference this I get an
array-object , not the actual array data.
.
>
>> std::cout<< arr << std::endl << parr << std::endl << pparr;
>> All point to the same thing.
>
> Right, the addresses are all the same value, but each pointer is a
> different type.
They all point to arrays of int-type. They are different levels of
indirection.
> If you increment parr, the byte address increases by
> 6*sizeof(int). If you increment pparr, the byte address increases by
> 6*6*sizeof(int).
>
>> Each identifier points to the same array, but they are different levels
>> of
>> indirection.
>
> Each identifier points to the same address, but parr is a pointer to a
> 1-dimensional array and pparr is a pointer to a 2-dimensional array.
No its not par is a pointer to THE array (the data that is the array), pparr
is not:
par[0][0]; /*returns array data*/
pparr[0][0] /*Is a complete pile of bollocks*/
>
>> The same applies to 1dim arrays:
>> int arr[6]; /*array object*/
>> int* parr= arr; /*pointer to THE array*/
>
> It points to the first element of the array. When the initialization
> expression is evaluated, the standard array-to-pointer conversion occurs,
> resulting in a pointer to the first element of the array, not a pointer
> to the array.
What don't you understand about the fact that they all initially point to
the same address?
Why you seem to think that parr is some kind of r-value is beyond me, what
don't you understand about the fact that it can point to any element of the
array?
>
>> int (*pparr) =&arr; /*pointer to array object*/
>
> It is a pointer to a 1-dimensional array of 6 ints.
>
>> This C++ standard confirms, in section 8.3.4 para 7, that a dereferenced
>> array object is always (n-1) dimensions of the pointed to array.
>> If you don't accpet what's in the standards I don't know what more I can
>> say.
>
> I accept what is written in the C++ standard. In an earlier followup I
> gave an example where that paragraph applied. I also accept what is
> written in paragraph 1 of section 4.2:
No you don't accept it , you said it wasn't relevant.
>
> An lvalue or rvalue of type "array of N T" or "array of unknown
> bound of T" can be converted to an rvalue of type "pointer to T."
> The result is a pointer to the first element of the array.
>
> An example where the paragraph applies is the initialization expression
> in the second of the following two declarations.
>
> int arr[6];
> int *parr = arr;
>
> According to the standard, the result of the conversion is a "pointer to
> the
> first element of the array" not a "pointer to the array".
Why do you think, with three pointers to exactly the same place, they point
to different things?
Its exactly the opposite of what you say because:
int arr[6]; /*r-value , can only point to the first element*/
int* parr=arr; /*l-value , can point to any element*/
int (*pparr)[6] = &arr; /*l-value, can only point to 1st element or 1 past
end.*/
You obviously have very strange ideas about pointers and arrays, I have
already posted information about array types from experts and the C++
standard, if you refuse to accept this thats up to you. Please stop making
statements as if they are statements of factual correctness that are
actually wrong, particularly the one I quote:
<quote>
According to the standard, the result of the conversion is a "pointer to the
first element of the array" not a "pointer to the array".
</quote>
This is a complete misinterpretation of the standards, and incorrect..
A. Bolmarcich
>
> "A. Bolmarcich" <agg...@earl-grey.cloud9.net> wrote in message
> news:slrnip45kk....@earl-grey.cloud9.net...
>> On 2011-03-28, Paul <pchr...@yahoo.co.uk> wrote:
>>> int arr[6][6]; /*This is an array-object*/
>>> int (*parr)[6] = arr; /*This is a pointer to THE array*/
>> Each identifier points to the same address, but parr is a pointer to a
>> 1-dimensional array and pparr is a pointer to a 2-dimensional array.
> No its not par is a pointer to THE array (the data that is the array), pparr
> is not:
> par[0][0]; /*returns array data*/
> pparr[0][0] /*Is a complete pile of bollocks*/
I wrote: "pparr is a pointer to a 2-dimensional array". To get the
same value that arr[0][0] gives, use the expression (*pparr)[0][0]. That
is, dereference the pointer to the array before applying subscript
operators.
>>> The same applies to 1dim arrays:
>>> int arr[6]; /*array object*/
>>> int* parr= arr; /*pointer to THE array*/
>>
>> It points to the first element of the array. When the initialization
>> expression is evaluated, the standard array-to-pointer conversion occurs,
>> resulting in a pointer to the first element of the array, not a pointer
>> to the array.
>
> What don't you understand about the fact that they all initially point to
> the same address?
I never stated that they didn't point to the same address. What I wrote
was about the type of the expression arr. Your comment with the declaration
was "pointer to THE array". I wrote that it was a pointer to the first
element of the array, not a pointer to the array. In the example, the
former is of type int* and the latter is of type int(*)[6].
> Why you seem to think that parr is some kind of r-value is beyond me, what
> don't you understand about the fact that it can point to any element of the
> array?
I never stated that the value of parr is some king of rvalue. It is a
non-const identifier. Its value can be changed to point to any int.
[snip]
>>> This C++ standard confirms, in section 8.3.4 para 7, that a dereferenced
>>> array object is always (n-1) dimensions of the pointed to array.
>>> If you don't accpet what's in the standards I don't know what more I can
>>> say.
>>
>> I accept what is written in the C++ standard. In an earlier followup I
>> gave an example where that paragraph applied. I also accept what is
>> written in paragraph 1 of section 4.2:
> No you don't accept it , you said it wasn't relevant.
I wrote in a previous followup (message
<slrnip1h84....@earl-grey.cloud9.net>) that what your wrote about
section 8.3.4 wasn't relevant to the declaration
int *p = new int[4]
because the declaration did not dereference an array. I accept the
quote I posted from section 4.2 that you silently snipped.
[snip]
> Why do you think, with three pointers to exactly the same place, they point
> to different things?
> Its exactly the opposite of what you say because:
> int arr[6]; /*r-value , can only point to the first element*/
> int* parr=arr; /*l-value , can point to any element*/
> int (*pparr)[6] = &arr; /*l-value, can only point to 1st element or 1 past
> end.*/
They all initially point to the same address, but they have different types.
arr has type array of 6 int. parr has type pointer to int. pparr has type
pointer to array of 6 int.
Incrementing parr adds sizeof(int) to the byte address. Incrementing pparr
adds 6*sizeof(int) to the byte address
> You obviously have very strange ideas about pointers and arrays, I have
> already posted information about array types from experts and the C++
> standard, if you refuse to accept this thats up to you. Please stop making
> statements as if they are statements of factual correctness that are
> actually wrong, particularly the one I quote:
><quote>
> According to the standard, the result of the conversion is a "pointer to the
> first element of the array" not a "pointer to the array".
></quote>
> This is a complete misinterpretation of the standards, and incorrect..
The ideas I have about pointers and arrays are from the standard. Here
is paragraph 1 of section 4.2 of the standard (you silently snipped
the copy that was in my previous post):
An lvalue or rvalue of type "array of N T" or "array of unknown
bound of T" can be converted to an rvalue of type "pointer to T."
The result is a pointer to the first element of the array.
A pointer to the first element of the array is not the same as a pointer to
the array. The former has type pointer to T, that latter has type pointer
to array of N T. If they were the same, given the declaration
int *pi, (*pai)[1];
the assignment
pi = pai;
would be allowed, but it is not allowed.
Paul
array and it only points to only the first element.
> [snip]
>>>> This C++ standard confirms, in section 8.3.4 para 7, that a
>>>> dereferenced
>>>> array object is always (n-1) dimensions of the pointed to array.
>>>> If you don't accpet what's in the standards I don't know what more I
>>>> can
>>>> say.
>>>
>>> I accept what is written in the C++ standard. In an earlier followup I
>>> gave an example where that paragraph applied. I also accept what is
>>> written in paragraph 1 of section 4.2:
>> No you don't accept it , you said it wasn't relevant.
>
> I wrote in a previous followup (message
> <slrnip1h84....@earl-grey.cloud9.net>) that what your wrote about
> section 8.3.4 wasn't relevant to the declaration
>
> int *p = new int[4]
>
> because the declaration did not dereference an array. I accept the
> quote I posted from section 4.2 that you silently snipped.
>
> [snip]
As I said you are trying to say the standards are not relevant when they
are.
>
>> Why do you think, with three pointers to exactly the same place, they
>> point
>> to different things?
>> Its exactly the opposite of what you say because:
>> int arr[6]; /*r-value , can only point to the first element*/
>> int* parr=arr; /*l-value , can point to any element*/
>> int (*pparr)[6] = &arr; /*l-value, can only point to 1st element or 1
>> past
>> end.*/
>
> They all initially point to the same address, but they have different
> types.
> arr has type array of 6 int. parr has type pointer to int. pparr has
> type
> pointer to array of 6 int.
>
They are all int types
arr[6]; /* returns int */
*parr; /*returns int */
*pparr; /*returns int[], which decays to int* */
The third is simply another level of indirection.
So why do you not understand the parr points to the array?
> Incrementing parr adds sizeof(int) to the byte address. Incrementing
> pparr
> adds 6*sizeof(int) to the byte address
>
>> You obviously have very strange ideas about pointers and arrays, I have
>> already posted information about array types from experts and the C++
>> standard, if you refuse to accept this thats up to you. Please stop
>> making
>> statements as if they are statements of factual correctness that are
>> actually wrong, particularly the one I quote:
>><quote>
>> According to the standard, the result of the conversion is a "pointer to
>> the
>> first element of the array" not a "pointer to the array".
>></quote>
>> This is a complete misinterpretation of the standards, and incorrect..
>
> The ideas I have about pointers and arrays are from the standard. Here
> is paragraph 1 of section 4.2 of the standard (you silently snipped
> the copy that was in my previous post):
>
> An lvalue or rvalue of type "array of N T" or "array of unknown
> bound of T" can be converted to an rvalue of type "pointer to T."
> The result is a pointer to the first element of the array.
>
> A pointer to the first element of the array is not the same as a pointer
> to
> the array.
WHere does the standard state this? Or it this your addition to the
standard?
If it points to the first element *OF THE ARRAY* then, by definition , it
points to the array.
<snip>
A. Bolmarcich
>
> "A. Bolmarcich" <agg...@earl-grey.cloud9.net> wrote in message
> news:slrnip6qm7....@earl-grey.cloud9.net...
>> On 2011-03-29, Paul <pchr...@yahoo.co.uk> wrote:
>>>
>>> "A. Bolmarcich" <agg...@earl-grey.cloud9.net> wrote in message
>>> news:slrnip45kk....@earl-grey.cloud9.net...
>>>> On 2011-03-28, Paul <pchr...@yahoo.co.uk> wrote:
> You are a liar you have been constantly stating it doesn't point to the
> array and it only points to only the first element.
What I have been stating is that it, that is, an rvalue or lvalue of
type array of T that undergoes array-to-pointer conversion, results in
a pointer to T that points to the first element of the array. If that
is a lie, then section 4.2 of the C++ specification contains a lie.
It does not point the array because a pointer to an array is a
different type of pointer than a pointer to an element of the array.
(More on this difference later in this followup.)
>>>>> This C++ standard confirms, in section 8.3.4 para 7, that a
>>>>> dereferenced
>>>>> array object is always (n-1) dimensions of the pointed to array.
>>>>> If you don't accpet what's in the standards I don't know what more I
>>>>> can
>>>>> say.
>>>>
>>>> I accept what is written in the C++ standard. In an earlier followup I
>>>> gave an example where that paragraph applied. I also accept what is
>>>> written in paragraph 1 of section 4.2:
>>> No you don't accept it , you said it wasn't relevant.
>>
>> I wrote in a previous followup (message
>> <slrnip1h84....@earl-grey.cloud9.net>) that what your wrote about
>> section 8.3.4 wasn't relevant to the declaration
>>
>> int *p = new int[4]
>>
>> because the declaration did not dereference an array. I accept the
>> quote I posted from section 4.2 that you silently snipped.
>>
>> [snip]
>
> As I said you are trying to say the standards are not relevant when they
> are.
How is a part of the C++ standard that is about dereferencing an
array relevant to a C++ statement in which there is no dereferencing
of an array?
>>> Why do you think, with three pointers to exactly the same place, they
>>> point
>>> to different things?
>>> Its exactly the opposite of what you say because:
>>> int arr[6]; /*r-value , can only point to the first element*/
>>> int* parr=arr; /*l-value , can point to any element*/
>>> int (*pparr)[6] = &arr; /*l-value, can only point to 1st element or 1
>>> past
>>> end.*/
>>
>> They all initially point to the same address, but they have different
>> types.
>> arr has type array of 6 int. parr has type pointer to int. pparr has
>> type
>> pointer to array of 6 int.
>>
> They are all int types
> arr[6]; /* returns int */
> *parr; /*returns int */
> *pparr; /*returns int[], which decays to int* */
> The third is simply another level of indirection.
It is the variables parr and pparr that are being initialized, not
the result of dereferencing them. Those variables have different
types: pointer to int and pointer to array of 6 int, respectively.
Neither of those variables is type int.
> So why do you not understand the parr points to the array?
parr is a pointer to an int; it has type int*. A pointer to an array of
int has of the form int(*)[]. parr does not point to the array because
its type is not that of a pointer to an array.
I demonstrated why they are not the same in lines that you sliently
snipped at this point. Here are the snipped lines:
A pointer to the first element of the array is not the same as a pointer to
the array. The former has type pointer to T, that latter has type pointer
to array of N T. If they were the same, given the declaration
int *pi, (*pai)[1];
the assignment
pi = pai;
would be allowed, but it is not allowed.
The C++ standard allows the right operand of an assignment operator
to be implicitly converted to the type of the left operand. However,
converting from a pointer to an array of N T to a pointer to T is
not a conversion allowed by section 4 of the C++ standard, where
the implicit conversions are specified.
> If it points to the first element *OF THE ARRAY* then, by definition , it
> points to the array.
Such a definition ignores the fact that C++ pointers are typed. The
"it" that points is a pointer with a type. A pointer to an element of
an array and a pointer to an array are two different types of pointers.
Paul
> On 2011-03-30, Paul <pchr...@yahoo.co.uk> wrote:
>>
>> "A. Bolmarcich" <agg...@earl-grey.cloud9.net> wrote in message
>> news:slrnip6qm7....@earl-grey.cloud9.net...
>>> On 2011-03-29, Paul <pchr...@yahoo.co.uk> wrote:
>>>>
>>>> "A. Bolmarcich" <agg...@earl-grey.cloud9.net> wrote in message
>>>> news:slrnip45kk....@earl-grey.cloud9.net...
>>>>> On 2011-03-28, Paul <pchr...@yahoo.co.uk> wrote:
> [snip]
>
>> You are a liar you have been constantly stating it doesn't point to the
>> array and it only points to only the first element.
>
> What I have been stating is that it, that is, an rvalue or lvalue of
> type array of T that undergoes array-to-pointer conversion, results in
> a pointer to T that points to the first element of the array. If that
> is a lie, then section 4.2 of the C++ specification contains a lie.
>
point to the array.
Which does not make sense.
> It does not point the array because a pointer to an array is a
> different type of pointer than a pointer to an element of the array.
> (More on this difference later in this followup.)
>
See there you go again ^^^^^^.
>>>>>> This C++ standard confirms, in section 8.3.4 para 7, that a
>>>>>> dereferenced
>>>>>> array object is always (n-1) dimensions of the pointed to array.
>>>>>> If you don't accpet what's in the standards I don't know what more I
>>>>>> can
>>>>>> say.
>>>>>
>>>>> I accept what is written in the C++ standard. In an earlier followup
>>>>> I
>>>>> gave an example where that paragraph applied. I also accept what is
>>>>> written in paragraph 1 of section 4.2:
>>>> No you don't accept it , you said it wasn't relevant.
>>>
>>> I wrote in a previous followup (message
>>> <slrnip1h84....@earl-grey.cloud9.net>) that what your wrote
>>> about
>>> section 8.3.4 wasn't relevant to the declaration
>>>
>>> int *p = new int[4]
>>>
>>> because the declaration did not dereference an array. I accept the
>>> quote I posted from section 4.2 that you silently snipped.
>>>
>>> [snip]
>>
>> As I said you are trying to say the standards are not relevant when they
>> are.
>
> How is a part of the C++ standard that is about dereferencing an
> array relevant to a C++ statement in which there is no dereferencing
> of an array?
Because it explains that when you derefernece an array it returns a pointed
to (n-1) dimensional array.
>
>>>> Why do you think, with three pointers to exactly the same place, they
>>>> point
>>>> to different things?
>>>> Its exactly the opposite of what you say because:
>>>> int arr[6]; /*r-value , can only point to the first element*/
>>>> int* parr=arr; /*l-value , can point to any element*/
>>>> int (*pparr)[6] = &arr; /*l-value, can only point to 1st element or 1
>>>> past
>>>> end.*/
>>>
>>> They all initially point to the same address, but they have different
>>> types.
>>> arr has type array of 6 int. parr has type pointer to int. pparr has
>>> type
>>> pointer to array of 6 int.
>>>
>> They are all int types
>> arr[6]; /* returns int */
>> *parr; /*returns int */
>> *pparr; /*returns int[], which decays to int* */
>> The third is simply another level of indirection.
>
> It is the variables parr and pparr that are being initialized, not
> the result of dereferencing them. Those variables have different
> types: pointer to int and pointer to array of 6 int, respectively.
> Neither of those variables is type int.
It doesn't matter if its TYPE is int*****.
Its just a different level of indirection. The type of the array is INT.
>
>> So why do you not understand the parr points to the array?
>
> parr is a pointer to an int; it has type int*. A pointer to an array of
> int has of the form int(*)[].
No you are wrong , this is A pointer to an array , this is not THE ONLY type
that points to an array.
> parr does not point to the array because
> its type is not that of a pointer to an array.
They all point to the same array. How can you not understand that, do you
have learning difficulties?
You have demonstrated nothing.
> A pointer to the first element of the array is not the same as a pointer
> to
> the array. The former has type pointer to T, that latter has type
> pointer
> to array of N T. If they were the same, given the declaration
A pointer to the first element of an array, is a pointer to the array.
>
> int *pi, (*pai)[1];
>
> the assignment
>
> pi = pai;
>
> would be allowed, but it is not allowed.
You obviously do not understand the difference in level sof indirection.
>
> The C++ standard allows the right operand of an assignment operator
> to be implicitly converted to the type of the left operand. However,
> converting from a pointer to an array of N T to a pointer to T is
> not a conversion allowed by section 4 of the C++ standard, where
> the implicit conversions are specified.
You obviously dont know anything about the C++ standard if you cant
understand the simple statement :
points to the first element of an array, means by definition it points to
the array.
>
>> If it points to the first element *OF THE ARRAY* then, by definition , it
>> points to the array.
>
> Such a definition ignores the fact that C++ pointers are typed. The
> "it" that points is a pointer with a type. A pointer to an element of
> an array and a pointer to an array are two different types of pointers.
No it ignores no facts, it acknowledges the relevant sections of the
standards that you think are irrelevant.
I fully understand the difference between the types:
int(*)[size] and int*.
I also understand that both can point to arrays, you cannot understand this
though . You think only one type can point to an array which is ofc against
the views of all the C++ experts.
A. Bolmarcich
In order for a part of the C++ standard that is about a dereference
of an array to be relevant to a C++ statement, the statement has to
contain a dereference of an array. The statement
int *p = new int[4]
does not dereference an array.
There are many other sections of the C++ standard that are not
relevant to that statement, such section 5.7 about Additive
Operators. There are some sections that are relevant, such as
section 5.3.4 about New.
The type int***** is not the same as type int. Values with different
levels of indirection to the same type have different types.
>>> So why do you not understand the parr points to the array?
>>
>> parr is a pointer to an int; it has type int*. A pointer to an array of
>> int has of the form int(*)[].
> No you are wrong , this is A pointer to an array , this is not THE ONLY type
> that points to an array.
>
>> parr does not point to the array because
>> its type is not that of a pointer to an array.
>
> They all point to the same array. How can you not understand that, do you
> have learning difficulties?
I don't have any learning difficulties. However, I do understand that
in C++ a pointer to an int points to an int; it does not point to an
array. A pointer to an int and an pointer to an array of int are
different types.
A pointer to an int may point to any int, including one that is an
element of an array of int. However, when pointing to an element of
an array of int it is pointing to an int, not an array. When you
dereference the pointer the result is an int, not an array.
[snip]
>>>> The ideas I have about pointers and arrays are from the standard. Here
>>>> is paragraph 1 of section 4.2 of the standard (you silently snipped
>>>> the copy that was in my previous post):
>>>>
>>>> An lvalue or rvalue of type "array of N T" or "array of unknown
>>>> bound of T" can be converted to an rvalue of type "pointer to T."
>>>> The result is a pointer to the first element of the array.
>>>>
>>>> A pointer to the first element of the array is not the same as a pointer
>>>> to
>>>> the array.
>>> WHere does the standard state this? Or it this your addition to the
>>> standard?
>>
>> I demonstrated why they are not the same in lines that you sliently
>> snipped at this point. Here are the snipped lines:
>>
> You have demonstrated nothing.
It appears that you think I have demonstrated nothing even before
reading the sliently snipped lines that were restored. That is
about as useful as write-only memory.
>> A pointer to the first element of the array is not the same as a pointer
>> to
>> the array. The former has type pointer to T, that latter has type
>> pointer
>> to array of N T. If they were the same, given the declaration
> A pointer to the first element of an array, is a pointer to the array.
>
>> int *pi, (*pai)[1];
>>
>> the assignment
>>
>> pi = pai;
>>
>> would be allowed, but it is not allowed.
> You obviously do not understand the difference in level sof indirection.
What C++ compiler have you used that does not give a diagnostic
message about the assignment statement?
>> The C++ standard allows the right operand of an assignment operator
>> to be implicitly converted to the type of the left operand. However,
>> converting from a pointer to an array of N T to a pointer to T is
>> not a conversion allowed by section 4 of the C++ standard, where
>> the implicit conversions are specified.
> You obviously dont know anything about the C++ standard if you cant
> understand the simple statement :
> points to the first element of an array, means by definition it points to
> the array.
I know enough about the C++ standard to have quoted or referred to
parts of it that are relevant to C++ statements discussed in this
thread of posts.
>>> If it points to the first element *OF THE ARRAY* then, by definition , it
>>> points to the array.
>>
>> Such a definition ignores the fact that C++ pointers are typed. The
>> "it" that points is a pointer with a type. A pointer to an element of
>> an array and a pointer to an array are two different types of pointers.
>
> No it ignores no facts, it acknowledges the relevant sections of the
> standards that you think are irrelevant.
The relevant sections of the standard for the statement
pi = pai;
where pi and pai are declared with
int *pi, (*pai)[1];
are the one about assignment operators (5.17) and the one about
implict conversions (4) that it refers to. According to those
sections, that assignment, which tries have a pointer to int point
to an array, is not allowed. If pi and pai had the same type, the
assignment would be allowed.
> I fully understand the difference between the types:
> int(*)[size] and int*.
> I also understand that both can point to arrays, you cannot understand this
> though . You think only one type can point to an array which is ofc against
> the views of all the C++ experts.
If you fully understood the difference between those types in C++,
you would understand that a pointer to int cannot point to an array
of int. A term, such as "point to", used in the context of a
a programming language does not necessarily have the same meaning
that it has in other contexts.
Exactly where in the C++ standard is a statement that a pointer of
another type can "point to an array", as opposed to a pointer whose
type is the same as an array element type being able to point to an
element of that array?
Paul
to an array is. Therefore the section of the C++ standards that defines
pointers to arrays is very releveant.
Why would anyone suggest it was the same type? This is only your ludicrous
suggestion. We are talking about arrays and different levels of indirection,
the typeof the array is int, not int*** or int(*)[x][y][z].
An array of int* is not the same as a 2d array of int.
>
>>>> So why do you not understand the parr points to the array?
>>>
>>> parr is a pointer to an int; it has type int*. A pointer to an array of
>>> int has of the form int(*)[].
>> No you are wrong , this is A pointer to an array , this is not THE ONLY
>> type
>> that points to an array.
>>
>>> parr does not point to the array because
>>> its type is not that of a pointer to an array.
>>
>> They all point to the same array. How can you not understand that, do you
>> have learning difficulties?
>
> I don't have any learning difficulties. However, I do understand that
> in C++ a pointer to an int points to an int; it does not point to an
> array. A pointer to an int and an pointer to an array of int are
> different types.
But you obviously don't understand that an int* can point to a single int,
or an array of int's. Thus it seems you have have some difficulties with
understanding common sense.
A pointer type does not define what is pointed to, what is pointed to is
defined by allocation.
>
> A pointer to an int may point to any int, including one that is an
> element of an array of int. However, when pointing to an element of
> an array of int it is pointing to an int, not an array. When you
> dereference the pointer the result is an int, not an array.
This is where you lose all sense of logic, a pointer to an entity points
exactly to that entity. The pointer type does not define the pointed to
entity.
>
> [snip]
>
>>>>> The ideas I have about pointers and arrays are from the standard.
>>>>> Here
>>>>> is paragraph 1 of section 4.2 of the standard (you silently snipped
>>>>> the copy that was in my previous post):
>>>>>
>>>>> An lvalue or rvalue of type "array of N T" or "array of unknown
>>>>> bound of T" can be converted to an rvalue of type "pointer to T."
>>>>> The result is a pointer to the first element of the array.
>>>>>
>>>>> A pointer to the first element of the array is not the same as a
>>>>> pointer
>>>>> to
>>>>> the array.
>>>> WHere does the standard state this? Or it this your addition to the
>>>> standard?
>>>
>>> I demonstrated why they are not the same in lines that you sliently
>>> snipped at this point. Here are the snipped lines:
>>>
>> You have demonstrated nothing.
>
> It appears that you think I have demonstrated nothing even before
> reading the sliently snipped lines that were restored. That is
> about as useful as write-only memory.
What exactly does SILENTLY snipped mean? Does snipping produce sound on your
PC?
>
>>> A pointer to the first element of the array is not the same as a
>>> pointer
>>> to
>>> the array. The former has type pointer to T, that latter has type
>>> pointer
>>> to array of N T. If they were the same, given the declaration
>> A pointer to the first element of an array, is a pointer to the array.
>>
>>> int *pi, (*pai)[1];
>>>
>>> the assignment
>>>
>>> pi = pai;
>>>
>>> would be allowed, but it is not allowed.
>> You obviously do not understand the difference in level sof indirection.
>
> What C++ compiler have you used that does not give a diagnostic
> message about the assignment statement?
Your code is just wrong. I don't know what its supposed to do.
>
>>> The C++ standard allows the right operand of an assignment operator
>>> to be implicitly converted to the type of the left operand. However,
>>> converting from a pointer to an array of N T to a pointer to T is
>>> not a conversion allowed by section 4 of the C++ standard, where
>>> the implicit conversions are specified.
>> You obviously dont know anything about the C++ standard if you cant
>> understand the simple statement :
>> points to the first element of an array, means by definition it points to
>> the array.
>
> I know enough about the C++ standard to have quoted or referred to
> parts of it that are relevant to C++ statements discussed in this
> thread of posts.
You don't accept what is relevant , the part of the C++ standards that
defines arrays are relevant but you seem to think not.
>
>>>> If it points to the first element *OF THE ARRAY* then, by definition ,
>>>> it
>>>> points to the array.
>>>
>>> Such a definition ignores the fact that C++ pointers are typed. The
>>> "it" that points is a pointer with a type. A pointer to an element of
>>> an array and a pointer to an array are two different types of pointers.
>>
>> No it ignores no facts, it acknowledges the relevant sections of the
>> standards that you think are irrelevant.
>
> The relevant sections of the standard for the statement
>
> pi = pai;
>
> where pi and pai are declared with
>
> int *pi, (*pai)[1];
>
> are the one about assignment operators (5.17) and the one about
> implict conversions (4) that it refers to. According to those
> sections, that assignment, which tries have a pointer to int point
> to an array, is not allowed. If pi and pai had the same type, the
> assignment would be allowed.
What is this nonsense about , your code is trash dude and you can't even
accept what is really the relevant sections of the standard, the sections
about arrays.
>
>> I fully understand the difference between the types:
>> int(*)[size] and int*.
>> I also understand that both can point to arrays, you cannot understand
>> this
>> though . You think only one type can point to an array which is ofc
>> against
>> the views of all the C++ experts.
>
> If you fully understood the difference between those types in C++,
> you would understand that a pointer to int cannot point to an array
> of int. A term, such as "point to", used in the context of a
> a programming language does not necessarily have the same meaning
> that it has in other contexts.
As you refuse to accept all reason and common sense I can only appeal to
authority. If people like Bjarne Stroustrup say that an int* can point to a
single int or an array of int, and you say otherwise, who are we to believe
is correct? You or Bjarne Stroustrup?
If the C++ standard states that , when dereferenced, an array(or pointer to
an array) returns the pointed to (n-1)dimension array. Then who are we to
believe, you or the C++ standard?
>
> Exactly where in the C++ standard is a statement that a pointer of
> another type can "point to an array", as opposed to a pointer whose
> type is the same as an array element type being able to point to an
> element of that array?
You refuse to accept what the C++ standard says about arrays, you said it
was irrelevant because the statement:
int* p = new int[7];
does not contain any dereference.
A. Bolmarcich
> news:slrnipc3gd....@earl-grey.cloud9.net...
>> On 2011-03-31, Paul <pchr...@yahoo.co.uk> wrote:
>>>> How is a part of the C++ standard that is about dereferencing an
>>>> array relevant to a C++ statement in which there is no dereferencing
>>>> of an array?
>>> Because it explains that when you derefernece an array it returns a
>>> pointed
>>> to (n-1) dimensional array.
>>
>> In order for a part of the C++ standard that is about a dereference
>> of an array to be relevant to a C++ statement, the statement has to
>> contain a dereference of an array. The statement
>>
>> int *p = new int[4]
>>
>> does not dereference an array.
>>
>> There are many other sections of the C++ standard that are not
>> relevant to that statement, such section 5.7 about Additive
>> Operators. There are some sections that are relevant, such as
>> section 5.3.4 about New.
> The argument is not simply about this statement, it is about what a pointer
> to an array is. Therefore the section of the C++ standards that defines
> pointers to arrays is very releveant.
My comment was simply about a C++ statement. I wrote that part of
the C++ standard about dereferencing an array is not relevant to the
statement
int *p = new int[4];
because that statement does not dereference an array.
In addition, the statement does not involve a pointer to an array.
The statement declares a pointer to an int. That pointer is
initialized with a C++ expression that according to the C++
standard returns a pointer to an int (see paragraph 5 of section
5.3.4 of the standard about New, which I quoted it in my first post
in this thread of posts).
You are the one who suggested that they were the same type by
writing: "They all are int types" and "It doesn't matter if the
TYPE is int*****."
[snip]
>>>> parr does not point to the array because
>>>> its type is not that of a pointer to an array.
>>>
>>> They all point to the same array. How can you not understand that, do you
>>> have learning difficulties?
>>
>> I don't have any learning difficulties. However, I do understand that
>> in C++ a pointer to an int points to an int; it does not point to an
>> array. A pointer to an int and an pointer to an array of int are
>> different types.
> But you obviously don't understand that an int* can point to a single int,
> or an array of int's. Thus it seems you have have some difficulties with
> understanding common sense.
> A pointer type does not define what is pointed to, what is pointed to is
> defined by allocation.
What I understand is that in C++ a pointer to an int points to an int
and not to an array of int. A pointer to an int and a pointer to an
array of int are different types. It is not a matter of common sense;
it is a matter of what the term "points to" means in C++. Here is
paragraph 1 of section 5.3.1 of the C++ standard:
The unary * operator performs indirection: the expression to which
it is applied shall be a pointer to an object type, or a pointer
to a function type and the result is an lvalue referring to the
object or function to which the expression points. If the type of
the expression is pointer to T, the type of the result is T.
[Note: a pointer to an incomplete type (other than cv void ) can
be dereferenced. The lvalue thus obtained can be used in limited
ways (to initialize a reference, for example); this lvalue must
not be converted to an rvalue, see 4.1.]
According to the C++ standard, the pointer type determines the
type of the result of dereferencing the pointer.
>> A pointer to an int may point to any int, including one that is an
>> element of an array of int. However, when pointing to an element of
>> an array of int it is pointing to an int, not an array. When you
>> dereference the pointer the result is an int, not an array.
> This is where you lose all sense of logic, a pointer to an entity points
> exactly to that entity. The pointer type does not define the pointed to
> entity.
According the the C++ standard, see the preceeding quote from the
standard, the type of the result of dereferencing a pointer depends
on the type of the pointer. The result type does not depend on the
type used when the object was allocated.
[snip]
>>>>>> The ideas I have about pointers and arrays are from the standard.
>>>>>> Here
>>>>>> is paragraph 1 of section 4.2 of the standard (you silently snipped
>>>>>> the copy that was in my previous post):
>>>>>>
>>>>>> An lvalue or rvalue of type "array of N T" or "array of unknown
>>>>>> bound of T" can be converted to an rvalue of type "pointer to T."
>>>>>> The result is a pointer to the first element of the array.
>>>>>>
>>>>>> A pointer to the first element of the array is not the same as a
>>>>>> pointer
>>>>>> to
>>>>>> the array.
>>>>> WHere does the standard state this? Or it this your addition to the
>>>>> standard?
>>>>
>>>> I demonstrated why they are not the same in lines that you sliently
>>>> snipped at this point. Here are the snipped lines:
>>>>
>>> You have demonstrated nothing.
>>
>> It appears that you think I have demonstrated nothing even before
>> reading the sliently snipped lines that were restored. That is
>> about as useful as write-only memory.
> What exactly does SILENTLY snipped mean? Does snipping produce sound on your
> PC?
Silently snipped means removing lines of the post being followed-up
to without indicating that the lines have been removed, such as by
including "[snip]" in the followup.
>>>> A pointer to the first element of the array is not the same as a
>>>> pointer
>>>> to
>>>> the array. The former has type pointer to T, that latter has type
>>>> pointer
>>>> to array of N T. If they were the same, given the declaration
>>> A pointer to the first element of an array, is a pointer to the array.
>>>
>>>> int *pi, (*pai)[1];
>>>>
>>>> the assignment
>>>>
>>>> pi = pai;
>>>>
>>>> would be allowed, but it is not allowed.
>>> You obviously do not understand the difference in level sof indirection.
>>
>> What C++ compiler have you used that does not give a diagnostic
>> message about the assignment statement?
> Your code is just wrong. I don't know what its supposed to do.
What it tries to do is assign a pointer to an array of int to a
pointer to an int. The fact that it is not allowed by the C++
standard demonstrates that a pointer to an int cannot not point
to an array of int. It can point to an element of an array of int.
The statement
pi = &((*pai)[0]);
is allowed. It assigns a pointer to an element of an array of int
to a pointer to an int.
[snip]
>>>>> If it points to the first element *OF THE ARRAY* then, by definition ,
>>>>> it
>>>>> points to the array.
>>>>
>>>> Such a definition ignores the fact that C++ pointers are typed. The
>>>> "it" that points is a pointer with a type. A pointer to an element of
>>>> an array and a pointer to an array are two different types of pointers.
>>>
>>> No it ignores no facts, it acknowledges the relevant sections of the
>>> standards that you think are irrelevant.
>>
>> The relevant sections of the standard for the statement
>>
>> pi = pai;
>>
>> where pi and pai are declared with
>>
>> int *pi, (*pai)[1];
>>
>> are the one about assignment operators (5.17) and the one about
>> implict conversions (4) that it refers to. According to those
>> sections, that assignment, which tries have a pointer to int point
>> to an array, is not allowed. If pi and pai had the same type, the
>> assignment would be allowed.
> What is this nonsense about , your code is trash dude and you can't even
> accept what is really the relevant sections of the standard, the sections
> about arrays.
The fact that C++ compilers reject the code demonstrates that a
pointer to an array of int cannot be assigned to a pointer to int.
In other words, a pointer to int cannot point to an array of int.
What paragraph of the C++ standard states otherwise?
>>> I fully understand the difference between the types:
>>> int(*)[size] and int*.
>>> I also understand that both can point to arrays, you cannot understand
>>> this
>>> though . You think only one type can point to an array which is ofc
>>> against
>>> the views of all the C++ experts.
>>
>> If you fully understood the difference between those types in C++,
>> you would understand that a pointer to int cannot point to an array
>> of int. A term, such as "point to", used in the context of a
>> a programming language does not necessarily have the same meaning
>> that it has in other contexts.
> As you refuse to accept all reason and common sense I can only appeal to
> authority. If people like Bjarne Stroustrup say that an int* can point to a
> single int or an array of int, and you say otherwise, who are we to believe
> is correct? You or Bjarne Stroustrup?
No one needs to believe anything that is not supported by what is
in the C++ standard or by compliers that comply to the standard.
Given the declaraion
int *pi, (*pai)[1];
the statement
pi = pai;
which attempts to have a pointer to an int point to the array of int
(pointed to by the variable pai) is not allowed. C++ compilers will
issue a diagnosic message for the assignment statement.
> If the C++ standard states that , when dereferenced, an array(or pointer to
> an array) returns the pointed to (n-1)dimension array. Then who are we to
> believe, you or the C++ standard?
Right, in the statement
int a2i[3][5], (*pa1i)[5] = a2i;
evaluating a2i in the initialization expression returns a pointer to
a 1-dimensional array. After the initialization pa1i points to that
1-dimensional array, not to a 2-dimensional array.
>> Exactly where in the C++ standard is a statement that a pointer of
>> another type can "point to an array", as opposed to a pointer whose
>> type is the same as an array element type being able to point to an
>> element of that array?
>
> You refuse to accept what the C++ standard says about arrays, you said it
> was irrelevant because the statement:
> int* p = new int[7];
> does not contain any dereference.
I accept what the C++ standard says about arrays. I said that parts
of the C++ standard about *dereferencing* are not relevant to a
statement that does not contain dereferencing (I have emphasized the
word *dereferencing* because you omitted it).
I have answered your questions and cited parts of the C++ standard
relevant to example C++ statements. I don't know why you don't
similarly answer my questions, including the one immediately before
the last lines of your post.
Paul
pointer to int, but this does not mean it cannot point to an array of int.
Since you have stated that a pointer of type int* cannot point to an array
the rellevant sections of the standards, that address dereferencing pointers
to arrays, are applicable.
I'm saying they are all arrays of the same type i.e:
int arr1[3][4]; /*Array of int type*/
int arr2[6]; /*Array of int*/
int* p1 = new int[5]; /*Array of int*/
int (*p2)[6] = new int[5][6]; /*Array of int*/
They are all int-type arrays and the identifier in each case, no matter what
type that is, points to an array of int.
> [snip]
>
>>>>> parr does not point to the array because
>>>>> its type is not that of a pointer to an array.
>>>>
>>>> They all point to the same array. How can you not understand that, do
>>>> you
>>>> have learning difficulties?
>>>
>>> I don't have any learning difficulties. However, I do understand that
>>> in C++ a pointer to an int points to an int; it does not point to an
>>> array. A pointer to an int and an pointer to an array of int are
>>> different types.
>> But you obviously don't understand that an int* can point to a single
>> int,
>> or an array of int's. Thus it seems you have have some difficulties with
>> understanding common sense.
>> A pointer type does not define what is pointed to, what is pointed to is
>> defined by allocation.
>
> What I understand is that in C++ a pointer to an int points to an int
> and not to an array of int.
This is wrong. An int* can point to an array of ints.
It can actually point to almost anything but within reason its either
uninitialised, null , points to int or points to array of int.
> A pointer to an int and a pointer to an
> array of int are different types.
No they're not. Your thinking about pointer types, not what is pointed to. I
have already said a pointer type doesn't define what is pointed to but I
will repeat it.
> It is not a matter of common sense;
> it is a matter of what the term "points to" means in C++. Here is
> paragraph 1 of section 5.3.1 of the C++ standard:
I know what points to means I dont need to reference the standard to find
out.
>
> The unary * operator performs indirection: the expression to which
> it is applied shall be a pointer to an object type, or a pointer
> to a function type and the result is an lvalue referring to the
> object or function to which the expression points. If the type of
> the expression is pointer to T, the type of the result is T.
> [Note: a pointer to an incomplete type (other than cv void ) can
> be dereferenced. The lvalue thus obtained can be used in limited
> ways (to initialize a reference, for example); this lvalue must
> not be converted to an rvalue, see 4.1.]
>
> According to the C++ standard, the pointer type determines the
> type of the result of dereferencing the pointer
>
So the C++ standards are relevant now when talking about dereferencing
pointers?
If you read the above in conjuction with the relevant section on arrays you
will understand.
>>> A pointer to an int may point to any int, including one that is an
>>> element of an array of int. However, when pointing to an element of
>>> an array of int it is pointing to an int, not an array. When you
>>> dereference the pointer the result is an int, not an array.
>> This is where you lose all sense of logic, a pointer to an entity points
>> exactly to that entity. The pointer type does not define the pointed to
>> entity.
>
> According the the C++ standard, see the preceeding quote from the
> standard, the type of the result of dereferencing a pointer depends
> on the type of the pointer. The result type does not depend on the
> type used when the object was allocated.
>
This does not mean the an int* cannot point to an array, If you read the
standards properly you will understand why a pointer to an array must point
to , the pointed to (n-1) diemnsional array.
And I though you said the standards were irellevant because we were not
talking aobut dereferencing a pointer.
Well thats just wrong because the pointer types are different levels if
indirection. You convert an array into a pointer like so :
int arr[5];
int* p = arr;
You don't take the address of an array , unless you want a different level
of indirection. Arrays are implicitly converted to pointers.
> The fact that it is not allowed by the C++
> standard demonstrates that a pointer to an int cannot not point
> to an array of int.
It is allowed but it needs a cast.
> It can point to an element of an array of int.
> The statement
>
> pi = &((*pai)[0]);
>
> is allowed. It assigns a pointer to an element of an array of int
> to a pointer to an int.
>
You are either deliberately or unknowingly writing bad code.
Its your code that is rejected by compilers so its your understanding that
must be wrong.
That piece of bad code you have produced somehow suggests that Bjarne
Stroustrup is wrong does it?
>
>
>> If the C++ standard states that , when dereferenced, an array(or pointer
>> to
>> an array) returns the pointed to (n-1)dimension array. Then who are we
>> to
>> believe, you or the C++ standard?
>
> Right, in the statement
>
> int a2i[3][5], (*pa1i)[5] = a2i;
>
> evaluating a2i in the initialization expression returns a pointer to
> a 1-dimensional array. After the initialization pa1i points to that
> 1-dimensional array, not to a 2-dimensional array.
a2i is implicitly converted to a pointer. The pointed to array is a 2d
array, not a 1dim array. Where the above standards quote applies is if you
derefernece either a2i or pa1i, eg:
*pa1i;
or
pa1i[0];
This is dereferencing the pointer to the array, and the results of this
dereference is an array of (n-1) dimensions , eg:
int[5];
As you can see the standard agrees perfectly with my interpretation.
If you take pa1i and consider it a pointer to a 1d array, this fails
because *pa1i does not produce the pointed to (n-1) dimensional array, which
would be a single int( a zero dim array).
You are creating another level of indirection, because arr already is(or
converts to) a pointer, under the hood. You compare this with a pointer to a
non array object, eg:
int arr[6];
int (*p)[6] = &arr; /*Taking address of a pointer.*/
int x =5;
int* p_x=&x; /*Creating a pointer */
You think the above is the same but its not, what you are doing is similar
to this:
int** pp = &p_x; /*Taking address of a pointer*/
>
>>> Exactly where in the C++ standard is a statement that a pointer of
>>> another type can "point to an array", as opposed to a pointer whose
>>> type is the same as an array element type being able to point to an
>>> element of that array?
>>
>> You refuse to accept what the C++ standard says about arrays, you said it
>> was irrelevant because the statement:
>> int* p = new int[7];
>> does not contain any dereference.
>
> I accept what the C++ standard says about arrays. I said that parts
> of the C++ standard about *dereferencing* are not relevant to a
> statement that does not contain dereferencing (I have emphasized the
> word *dereferencing* because you omitted it).
Well you have posted stuff from the standards about dereferencing pointers.
>
> I have answered your questions and cited parts of the C++ standard
> relevant to example C++ statements. I don't know why you don't
> similarly answer my questions, including the one immediately before
> the last lines of your post.
I have answered any questins you have asked.