«

"James Kanze" <> wrote in message
news:8b4290e7-303b-4f68-a367-...
> On Mar 26, 3:51 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>> "James Kanze" <james.ka...@gmail.com> wrote in message
>
>> news:aec94ef4-297d-4739-913e-...>
>> On
>> Mar 22, 5:17 am, "Paul" <pchris...@yahoo.co.uk> wrote:
>> >> "James Kanze" <james.ka...@gmail.com> wrote in message
>
>> > [...]
>> >> > I'll repeat my suggestion. Read the C++ standard. And show me
>> >> > where it defines an operator[] on an array.
>
>> >> I'm not wasting my time arguing with you over something that
>> >> is utterly and ridiculously obvious.
>
>> >> An array can be indexed. Learn to live with it, its never
>> >> gonna change.
>
>> > Not in C++. (Well, std::array can be indexed.)
>
>> Yes in C++. AN array can be indexed by subscripting.
>> Please stop making ridiculous statements that are untrue.
>
> Read the standard. The standard explicitly says that the
> operands to an [] operator must be a pointer and an integral
> type. No array. This has been the case since K&R C, and none
> of your claims to the contrary are going to change it.
>
You read the standards , please pay particular attention to the part that
states:

"Except where it has been declared for a class (13.5.5), the subscript
operator [] is interpreted in such a way
that E1[E2] is identical to *((E1)+(E2)). Because of the conversion rules
that apply to +, if E1 is an
array and E2 an integer, then E1[E2] refers to the E2th
member of E1."

So please stop making ridiculous statements that are simply untrue.

>> > [...]
>> >> > [...]
>> >> >> >> int* arr1 = new int[12]; /*Create an array of 12 int*/
>> >> >> >> arr1[0] = 33;
>> >> >> >> int* arr2 = new(++arr1) int[11]; /*Create an sub-array within
>> >> >> >> original*/
>
>> >> >> > You see. You even say so: new int[11] creates a new array of 11
>> >> >> > ints, and returns a pointer to the first element of that array.
>> >> >> > Not a pointer to arr1.
>
>> >> >> No I said I created an array of 12 ints, then I create and
>> >> >> sub-array within it, which returns a pointer with a value
>> >> >> identical to that of arr1.
>
>> >> > You didn't create a subarray. You created a new array, using
>> >> > some of the memory of the old one. (C++ doesn't have
>> >> > "subarrays", although I guess you could call an array which is a
>> >> > subobject of some larger object a subarray. That's not the case
>> >> > here, however.)
>
>> >> So it's a sub array.
>
>> > No. A sub array would be part of another object. In this case,
>> > you've created a new top level object.
>
>> No I managed the memory in such a way that i created an array
>> within an existing array.
>
> Which formally at least causes the previously existing array to
> cease to exist. At least according to the standard.
>
[] == oldarray
{} == new array

[][][][][][]{}{}{}{}{}{}{}{}{}{}{}[][][][][][][][]

If I create an array within another array as above. Only the elements that
are overwritten cease to exist, the elements not overwritten still exist
because I did not free the memory.


> [...]
>> > But an object is more than just memory, and the standard says
>> > that the object's lifetime ends if the memory is used for
>> > something else.
>
>> But the whole object wasn't overwritten.
>
> So you have a (small) part of the previous array? An object
> either exists, or it doesn't.
>
An array is a contiguous sequence of objects, not one single object(unless
its size is 0 or 1).

"Paul" <> wrote:
> "James Kanze" <> wrote:
>> Read the standard. The standard explicitly says that the
>> operands to an [] operator must be a pointer and an integral
>> type. No array. This has been the case since K&R C, and none
>> of your claims to the contrary are going to change it.
>>
> You read the standards , please pay particular attention to the part that
> states:
>
> "Except where it has been declared for a class (13.5.5), the subscript
> operator [] is interpreted in such a way
> that E1[E2] is identical to *((E1)+(E2)). Because of the conversion rules
> that apply to +, if E1 is an
> array and E2 an integer, then E1[E2] refers to the E2th
> member of E1."

"Because of the conversion rules that apply to +," i.e., that the array
reference A is converted to the pointer &(A[0]), "if E1 is an array and
E2 an integer, then E1[E2] refers to the E2th member of E1" -- since

E1[E2] <=> *((E1)+(E2)) <=> *(&(E1[0]) + (E2))

In other words, array dereferencing doesn't exist except as a (deliberate)
side-effect of pointer arithmetic.

--Joel

"Joel C. Salomon" <> wrote in message
news:imt3mc$bpn$...
> "Paul" <> wrote:
>> "James Kanze" <> wrote:
>>> Read the standard. The standard explicitly says that the
>>> operands to an [] operator must be a pointer and an integral
>>> type. No array. This has been the case since K&R C, and none
>>> of your claims to the contrary are going to change it.
>>>
>> You read the standards , please pay particular attention to the part that
>> states:
>>
>> "Except where it has been declared for a class (13.5.5), the subscript
>> operator [] is interpreted in such a way
>> that E1[E2] is identical to *((E1)+(E2)). Because of the conversion rules
>> that apply to +, if E1 is an
>> array and E2 an integer, then E1[E2] refers to the E2th
>> member of E1."
>
> "Because of the conversion rules that apply to +," i.e., that the array
> reference A is converted to the pointer &(A[0]), "if E1 is an array and
> E2 an integer, then E1[E2] refers to the E2th member of E1" -- since
>
> E1[E2] <=> *((E1)+(E2)) <=> *(&(E1[0]) + (E2))
> In other words, array dereferencing doesn't exist except as a (deliberate)
> side-effect of pointer arithmetic.
>

What are you trying to say?!
Are you, like James, trying to make this ludicrous claim that arrays cannot
be indexed ?
Or do you agree with the more sensible fact that they can be indexed?

On Mar 23, 3:45*pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "hanukas" <ju...@liimatta.org> wrote in message
>
> news:36f2fd28-d7af-4f95-a424-...
> On Mar 22, 5:00 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
>
>
>
>
>
>
>
>
> > "hanukas" <ju...@liimatta.org> wrote in message
>
> > > "Leigh Johnston" <le...@i42.co.uk> wrote in message
>
> > > >>> "x points to an array" is different to "x is a pointer to an array";
> > > >>> the first form is ambiguous but probably OK in informal settings;
> > > >>> the
> > > >>> second form is an incorrect description of what "x" is.
>
> > > >> Nonsense if x is a pointerto an array then , by defintion, x points
> > > >> to
> > > >> an array.
> > > >> *shrug*
>
> > > > Correct but that is not what I said. Your comprehension of the English
> > > > language and logic is very poor.
>
> > > Nothing wrong with my English.
> > > You were trying to say : "x points to an array" is OK but "x is a
> > > pointer
> > > to the array" is completely wrong. You are speaking complete nonsense
> > > because if one is true the other, by definition, is also true.
>
> > --You're confusing value and type. The type of x is "pointer to int",
> > --the value of the pointer to int is address of array element.
>
> > The value of a pointer-to an array, is not necessarrilly the address of
> > one
> > of the pointed-to arrays elements.
> > Who is confused?
>
> > <snip>
>
> --You aren't making much sense there, son. You should change your hobby
> --to something more suited to your unique set of skills.
>
> Oviously it's not going to make sense to you, if you don't understand it ..

There is nothing to be gained from understanding nonsense.

"Paul" <> wrote:
> "Joel C. Salomon" <> wrote:
>> "Because of the conversion rules that apply to +," i.e., that the array
>> reference A is converted to the pointer &(A[0]), "if E1 is an array and
>> E2 an integer, then E1[E2] refers to the E2th member of E1" -- since
>>
>> E1[E2] <=> *((E1)+(E2)) <=> *(&(E1[0]) + (E2))
>>
>> In other words, array dereferencing doesn't exist except as a (deliberate)
>> side-effect of pointer arithmetic.
>
> What are you trying to say?!
> Are you, like James, trying to make this ludicrous claim that arrays cannot
> be indexed ?
> Or do you agree with the more sensible fact that they can be indexed?

Yes.

--Joel

Le 25/03/2011 16:55, cg_chas a écrit :
> On Fri, 25 Mar 2011 12:18:33 +0100, ptyxs<> wrote:
>> Consider :
>> char ch[100];
>> The size of ch.sizeof(ch), is 100. However, the name of an array turns
>> into ("decays to") a pointer with the slightest excuse. For example:
>> char* p = ch;
>> Here p is initialized to&ch[10] and sizeof(p) is something like 4 (not
>> 100).
Of course, it was a typo. Mine, not Stroustrup's. The last sentence
starts thus :
"Here p is initialized to &ch[0]"

"Joel C. Salomon" <> wrote in message
news:imvffh$p3q$...
> "Paul" <> wrote:
>> "Joel C. Salomon" <> wrote:
>>> "Because of the conversion rules that apply to +," i.e., that the array
>>> reference A is converted to the pointer &(A[0]), "if E1 is an array and
>>> E2 an integer, then E1[E2] refers to the E2th member of E1" -- since
>>>
>>> E1[E2] <=> *((E1)+(E2)) <=> *(&(E1[0]) + (E2))
>>>
>>> In other words, array dereferencing doesn't exist except as a
>>> (deliberate)
>>> side-effect of pointer arithmetic.
>>
>> What are you trying to say?!
>> Are you, like James, trying to make this ludicrous claim that arrays
>> cannot be indexed ?
>> Or do you agree with the more sensible fact that they can be indexed?
>
> Yes.
>
^_^