Re: Problem with array objects

"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:472dnTX-tpH7JnvQnZ2dnUVZ8jWdnZ2d@giganews.com...
> On 01/06/2011 22:39, Paul wrote:
>>> [snip]
>>>
>>>>>> It is regarded as a pointer to the set of dominos, not a pointer to
>>>>>> one
>>>>>> single domino.
>>>>>
>>>>> Whether it is bananas, strawberries or dominoes it makes no difference
>>>>> to that fact that a pointer of type 'foo*' can only point to objects
>>>>> of type 'foo' (or objects of a type related to 'foo'); it cannot point
>>>>> to objects of type array of 'foo'.
>>>>>
>>>> But you contradict yourself because you say that a pointer of type foo*
>>>> can point to objectS(NOTE THE FUCKIN PLURAL) of the foo.
>>>> Yet you do not accept that a foo* can actually point to objects of type
>>>> foo and you'll say in another statement that it can only point to one
>>>> single foo
>>>
>>> Your comprehension of the English language when applied to technical
>>> discussions is very poor. What I said does not mean that a pointer of
>>> type 'foo*' can point to more than one object; what I said means that
>>> a pointer of type 'foo*' can point to objects of type 'foo' but not
>>> *more* than more than one object *at the same time*. Your thinking
>>> does not seem to be sufficiently sophisticated to make "leaps of logic":
>>>
>> This is ridiculous whether its English applied to a technical discussion
>> or any other kind of discussion. A plural implies more than one object.
>> A pointer to objectS(plural) , is distinctly different to a pointer to a
>> single object.
>
> I did not use the words "A pointer to objects" I used the words "point to
> objects"; it is not my fault that your lack of English comprehension
> skills is so poor. You are causing much wasting of time; you don't have a
> clue and you are extremely annoying.
>
If a pointer "points to" objectS, then it must be a "pointer to" objectS.

> You deliberately snipped/ignored my explanation so here it is again:
>
> int object1;
> int object2;
> int* rocketscience;
> rocketscience = &object1;
> rocketscience = &object2;
>
> 'rocketscience' is a pointer to an 'int' it being able to point to a
> single 'int' object or no object at all and 'rocketscience' pointed to two
> 'int' objects; this is NOT a contradiction; you need some degree of
> intelligence to understand it and I cannot help you increase your
> intelligence if you can't understand it.

rocketscience points to more than one object. If the code were put as
follows:
int arr[5];
int* rs = &arr[0];
rs = &arr[1];
rs = &arr[2];
rs = &arr[3];
rs = &arr[4];

Then rs points to all the integer objects of the array of integer objects.



>
>> Time is a completely differently variable to add on top of that. The
>> term you need is simultaneously, so what you seem to be saying now is
>> that a pointer of type int* CAN point to more than one int object but
>> just not all at the same time, Is this correct?
>
> What is correct is that a pointer of type 'int*' can only point to one
> 'int' object at a time (or no object at all); it cannot point to an array
> of 'int' objects.
>
As I showed above the pointer can point to the complete array, element by
element. What is your problem with this?

On Jun 1, 3:17*pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Joshua Maurice" <joshuamaur...@gmail.com> wrote in message
>
> news:bb11e43c-63a4-4830-a302-18b6d8091570@r35g2000prj.googlegroups.com...
> On Jun 1, 1:22 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> > There is a problem with inconsistency in the terminology used the C++
> > standards. For example the word "contains" .
> > (1) An object of array type, which nobody around can even acknowledge ,
>
> --You're still hung up on the whole "array objects are not modifiable
> --thing, but its contained sub-objects are". I'm sorry - the standard
> --does mean that expressions of array type, which refer to a region of
> --memory which contains the sub-objects, is not modifiable, but the
> --individual sub-objects are modifiable. It is making a statement about
> --how expressions of array type are not modifiable. It is not making a
> --statement about how the entire region of memory is not modifiable but
> --the sub-pieces, the array elements, are.
>
> So you are saying that the standard is worng to say the "object" is non
> modifiable?
> It should say the expression is non modifiable or something like that?

Pretty much, yeah. Let me reproduce my const example:
int x = 0;
int const& y = x;
x = 1;
I just modified the object referred to by "y", and it's not unusual to
say that "y" is unmodifiable.

> > is
> > described as some object that "contains" sub objects of element types.
> > I can understand this *concept* sure but there is no physical object in
> > memory that contains sub-objects.
>
> -- * *class Foo { int x; };
> -- * *Foo foo;
> --"foo" is a physical object in memory. "x" is a physical (sub-)object
> --in memory. Both take up a piece of memory. The region of memory of "x"
> --is a sub-region of the region of memory of "foo". That is, the region
> --of memory of "x" is contained within the region of memory of "foo".
> --Put another way, we are guaranteed that:
> -- * *assert( (char*)&foo <= (char*)&x );
> -- * *assert( (char*)&x + sizeof(x) <= (char*)&foo + sizeof(foo) );
> --(Optionally, that may require std::less. I don't care enough to look
> --up the arcane rules of if you can do pointer comparisons for pointers
> --obtained from the same complete object.)
>
> I dont see what you are trying to say here. x is a sub-object of Foo?

Yes.

> class Foo{}
> class Barublic Foo{}
>
> Bar b;
>
> Does b have a sub-object of type Foo?

Yes.

> Is this also a sub-object but in a different way?

This is a sub-object. It is a base class sub-object. There are base
class sub-objects, class member sub-objects, union member sub-objects,
and array element sub-objects. There may be more kinds; that's all I
remember off the top of my head.

> > (2) An object(of class type) does not contain member functions. LOL
> > This must be a joke because an array object can "contain" sub objects ,as
> > a
> > concept but an object(of class type) cannot "contain" memeber function,as
> > a
> > concept.
>
> --Yep. The C++ source code of the member functions neither appears
> --inside the declaration nor definition of the object.
> The member function is declared inside the the class definiton.

Yes. The class definition contains the member function. The object
definition does not contain the member function declaration nor
definition.
class Foo { public: void f(); }; //class definition
Foo foo; //object definition

> *--Also, on
> --basically every implementation ever, the compiled assembly of the
> --member function does not exist inside the region of memory of the
> --object. Finally, the object does not "own" the member function - you
> --can have member functions without an object. Thus, the word "contains"
> --does not apply to objects and their member functions.
>
> A member function is invoked on an object.
> What do you mean by a member function without an object. Please give an
> example.

We've done this already. Here it is again:
class Foo { public: void f(); };
typedef void (Foo::*mem_func_ptr_t)();
mem_func_ptr_t mem_func_tr = & Foo::f;
There is a pointer to a member function. I am able to point to it. It
exists without any objects of type "Foo".

"Joshua Maurice" <joshuamaurice@gmail.com> wrote in message
news:44877149-f3a7-404e-82e6-362c013d86d0@f31g2000pri.googlegroups.com...
On Jun 1, 3:17 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Joshua Maurice" <joshuamaur...@gmail.com> wrote in message
>
> news:bb11e43c-63a4-4830-a302-18b6d8091570@r35g2000prj.googlegroups.com...
> On Jun 1, 1:22 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> > There is a problem with inconsistency in the terminology used the C++
> > standards. For example the word "contains" .
> > (1) An object of array type, which nobody around can even acknowledge ,
>
> --You're still hung up on the whole "array objects are not modifiable
> --thing, but its contained sub-objects are". I'm sorry - the standard
> --does mean that expressions of array type, which refer to a region of
> --memory which contains the sub-objects, is not modifiable, but the
> --individual sub-objects are modifiable. It is making a statement about
> --how expressions of array type are not modifiable. It is not making a
> --statement about how the entire region of memory is not modifiable but
> --the sub-pieces, the array elements, are.
>
> So you are saying that the standard is worng to say the "object" is non
> modifiable?
> It should say the expression is non modifiable or something like that?

--Pretty much, yeah. Let me reproduce my const example:
-- int x = 0;
-- int const& y = x;
-- x = 1;
--I just modified the object referred to by "y", and it's not unusual to
--say that "y" is unmodifiable.

But when you say 'y' is non modifiable you usually mean it cannot be
assigned to refer to another object.

> > is
> > described as some object that "contains" sub objects of element types.
> > I can understand this *concept* sure but there is no physical object in
> > memory that contains sub-objects.
>
> -- class Foo { int x; };
> -- Foo foo;
> --"foo" is a physical object in memory. "x" is a physical (sub-)object
> --in memory. Both take up a piece of memory. The region of memory of "x"
> --is a sub-region of the region of memory of "foo". That is, the region
> --of memory of "x" is contained within the region of memory of "foo".
> --Put another way, we are guaranteed that:
> -- assert( (char*)&foo <= (char*)&x );
> -- assert( (char*)&x + sizeof(x) <= (char*)&foo + sizeof(foo) );
> --(Optionally, that may require std::less. I don't care enough to look
> --up the arcane rules of if you can do pointer comparisons for pointers
> --obtained from the same complete object.)
>
> I dont see what you are trying to say here. x is a sub-object of Foo?

--Yes.

> class Foo{}
> class Barublic Foo{}
>
> Bar b;
>
> Does b have a sub-object of type Foo?

--Yes.

> Is this also a sub-object but in a different way?

--This is a sub-object. It is a base class sub-object. There are base
--class sub-objects, class member sub-objects, union member sub-objects,
--and array element sub-objects. There may be more kinds; that's all I
--remember off the top of my head.

> > (2) An object(of class type) does not contain member functions. LOL
> > This must be a joke because an array object can "contain" sub objects ,
> > as
> > a
> > concept but an object(of class type) cannot "contain" memeber function,
> > as
> > a
> > concept.
>
> --Yep. The C++ source code of the member functions neither appears
> --inside the declaration nor definition of the object.
> The member function is declared inside the the class definiton.

--Yes. The class definition contains the member function. The object
--definition does not contain the member function declaration nor
--definition.
-- class Foo { public: void f(); }; //class definition
-- Foo foo; //object definition

The class defines the object type. Above you have declared an object of type
Foo, objects of type Foo are defined by the class Foo.

> --Also, on
> --basically every implementation ever, the compiled assembly of the
> --member function does not exist inside the region of memory of the
> --object. Finally, the object does not "own" the member function - you
> --can have member functions without an object. Thus, the word "contains"
> --does not apply to objects and their member functions.
>
> A member function is invoked on an object.
> What do you mean by a member function without an object. Please give an
> example.

--We've done this already. Here it is again:
-- class Foo { public: void f(); };
-- typedef void (Foo::*mem_func_ptr_t)();
-- mem_func_ptr_t mem_func_tr = & Foo::f;
--There is a pointer to a member function. I am able to point to it. It
--exists without any objects of type "Foo".

Yes fair enough but it's UB to invoke a member function without an object. I
agree that it is possible but IMO it's a bit of a hack to use the member
function as a standalone function.

"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:j6adnQ8edrlLIXvQnZ2dnUVZ8n2dnZ2d@giganews.com ...
> On 01/06/2011 22:43, Paul wrote:
>
> [snip]
>
>> So if char(*)[n] is, in your mind, a pointer to a 1d array what is a
>> pointer to a 2d array?
>> It surely cannot be the same type of pointer but I dunno. I presume it
>> must be a pointer of type int(*)[n][n]. Is this correct?
>
> 'int(*)[n][n]' is a pointer to a 2D array yes; if it where not the
> following would not compile:
>
> int array[7][42]; // this is a 2D array
> int (*pointer_to_array)[7][42] = &array;
>
So does this point to an array of objects or a single object of array type?

On Jun 1, 3:58*pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Joshua Maurice" <joshuamaur...@gmail.com> wrote in message
>
> -- Let me reproduce my const example:
> -- * *int x = 0;
> *-- * int const& y = x;
> *-- * x = 1;
> --I just modified the object referred to by "y", and it's not unusual to
> --say that "y" is unmodifiable.
>
> But when you say 'y' is non modifiable you usually mean it cannot be
> assigned to refer to another object.

Minor semantic quibble: In the above example, y refers to the same
object. The value of the object has changed. Ex:
int x[3] = {};
x[0] = 1; //line A
Line A doesn't create nor destroy any objects. It doesn't make
something refer to a new object. Line A merely changes the value of an
already existing object.

> > > (2) An object(of class type) does not contain member functions. LOL
> > > This must be a joke because an array object can "contain" sub objects,
> > > as
> > > a
> > > concept but an object(of class type) cannot "contain" memeber function,
> > > as
> > > a
> > > concept.
>
> > --Yep. The C++ source code of the member functions neither appears
> > --inside the declaration nor definition of the object.
> > The member function is declared inside the the class definiton.
>
> --Yes. The class definition contains the member function. The object
> --definition does not contain the member function declaration nor
> --definition.
> *-- * class Foo { public: void f(); }; //class definition
> -- * *Foo foo; //object definition
>
> The class defines the object type. Above you have declared an object of type
> Foo, objects of type Foo are defined by the class Foo.

No. Please go reread the ODR and the other parts of the standards
which describe "definitions" and "declarations". The terminology is
quite clear.

class Foo {};
That is a declaration. It brings into scope the name "Foo". It is a
declaration of the name "Foo". It is also a definition; it is a
definition of a class - it satisfies one of the bullets of the
standard, in this case it is a declaration of a class name which has
the class body.

Foo x;
This is a declaration. It brings into scope the name "x". It is also a
definition; it is a definition of an object - it satisfies one of the
bullets of the standard, in this case it is a declaration of an object
name without anything else that would make it not a definition (such
as "extern").

An object is /not/ defined by the class definition. That is simply
confusing and incorrect terminology. The definition of the object, or
more specifically the name of the object, is the declaration which
brings the name into scope, and which satisfies the requirements of
being a definition (one requirement is no "extern").

On 02/06/2011 00:26, Paul wrote:
>
> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
> news:j6adnQ8edrlLIXvQnZ2dnUVZ8n2dnZ2d@giganews.com ...
>> On 01/06/2011 22:43, Paul wrote:
>>
>> [snip]
>>
>>> So if char(*)[n] is, in your mind, a pointer to a 1d array what is a
>>> pointer to a 2d array?
>>> It surely cannot be the same type of pointer but I dunno. I presume it
>>> must be a pointer of type int(*)[n][n]. Is this correct?
>>
>> 'int(*)[n][n]' is a pointer to a 2D array yes; if it where not the
>> following would not compile:
>>
>> int array[7][42]; // this is a 2D array
>> int (*pointer_to_array)[7][42] = &array;
>>
> So does this point to an array of objects or a single object of array type?

The question makes no sense as "an array of objects" is "a single object
of array type" (a "sub-object" is also an "object").

/Leigh

"Joshua Maurice" <joshuamaurice@gmail.com> wrote in message
news:9ed74694-0012-47aa-ab1f-93f326b19d46@f31g2000pri.googlegroups.com...
On Jun 1, 3:58 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Joshua Maurice" <joshuamaur...@gmail.com> wrote in message
>
> -- Let me reproduce my const example:
> -- int x = 0;
> -- int const& y = x;
> -- x = 1;
> --I just modified the object referred to by "y", and it's not unusual to
> --say that "y" is unmodifiable.
>
> But when you say 'y' is non modifiable you usually mean it cannot be
> assigned to refer to another object.

--Minor semantic quibble: In the above example, y refers to the same
--object. The value of the object has changed. Ex:
-- int x[3] = {};
-- x[0] = 1; //line A
--Line A doesn't create nor destroy any objects. It doesn't make
--something refer to a new object. Line A merely changes the value of an
--already existing object.


No, Major error.

The reference is not changed unless is it made to alias another object.


> > > (2) An object(of class type) does not contain member functions. LOL
> > > This must be a joke because an array object can "contain" sub objects
> > > ,
> > > as
> > > a
> > > concept but an object(of class type) cannot "contain" memeber
> > > function,
> > > as
> > > a
> > > concept.
>
> > --Yep. The C++ source code of the member functions neither appears
> > --inside the declaration nor definition of the object.
> > The member function is declared inside the the class definiton.
>
> --Yes. The class definition contains the member function. The object
> --definition does not contain the member function declaration nor
> --definition.
> -- class Foo { public: void f(); }; //class definition
> -- Foo foo; //object definition
>
> The class defines the object type. Above you have declared an object of
> type
> Foo, objects of type Foo are defined by the class Foo.

--No. Please go reread the ODR and the other parts of the standards
--which describe "definitions" and "declarations". The terminology is
--quite clear.

-- class Foo {};
--That is a declaration. It brings into scope the name "Foo". It is a
--declaration of the name "Foo". It is also a definition; it is a
--definition of a class - it satisfies one of the bullets of the
--standard, in this case it is a declaration of a class name which has
--the class body.

-- Foo x;
--This is a declaration. It brings into scope the name "x". It is also a
--definition; it is a definition of an object - it satisfies one of the
--bullets of the standard, in this case it is a declaration of an object
--name without anything else that would make it not a definition (such
--as "extern").

--An object is /not/ defined by the class definition. That is simply
--confusing and incorrect terminology. The definition of the object, or
--more specifically the name of the object, is the declaration which
--brings the name into scope, and which satisfies the requirements of
--being a definition (one requirement is no "extern").

There is no definition for each object created. An object instance is not
defined it's type is defined, and that defintion stands for all objects of
the given type..
An object type is defined by a class.

"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:542dnY7aNpTEUXvQnZ2dnUVZ8nqdnZ2d@giganews.com ...
> On 02/06/2011 00:26, Paul wrote:
>>
>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
>> news:j6adnQ8edrlLIXvQnZ2dnUVZ8n2dnZ2d@giganews.com ...
>>> On 01/06/2011 22:43, Paul wrote:
>>>
>>> [snip]
>>>
>>>> So if char(*)[n] is, in your mind, a pointer to a 1d array what is a
>>>> pointer to a 2d array?
>>>> It surely cannot be the same type of pointer but I dunno. I presume it
>>>> must be a pointer of type int(*)[n][n]. Is this correct?
>>>
>>> 'int(*)[n][n]' is a pointer to a 2D array yes; if it where not the
>>> following would not compile:
>>>
>>> int array[7][42]; // this is a 2D array
>>> int (*pointer_to_array)[7][42] = &array;
>>>
>> So does this point to an array of objects or a single object of array
>> type?
>
> The question makes no sense as "an array of objects" is "a single object
> of array type" (a "sub-object" is also an "object").
>
An array of objects is not the same thing as a single object. It's you who
does not make sense.

On 2011-06-01, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrniucund.1rf2.aggedor@earl-grey.cloud9.net...
>> On 2011-05-31, Paul <pchristor@yahoo.co.uk> wrote:
>>>
>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>>> news:slrniua96r.jkt.aggedor@earl-grey.cloud9.net...
>>>> On 2011-05-28, Paul <pchristor@yahoo.co.uk> wrote:
>>
>> [snip]
>>
>>>>> Section 8.3.4 Arrays
>>>>>
>>>>> 5 [ Note: conversions affecting expressions of array type are described
>>>>> in
>>>>> 4.2. Objects of array types cannot be modified, see 3.10. -end note ]
>>>>> §
>>
>> [snip]
>>
>>>> The sections of the C++ standard cited in the above note give the
>>>> details of why assigning to an array type is not allowed. Paragraph
>>>> 1 of section 4.2 (Array-to-pointer conversion) is:
>>>>
>>>> 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.
>>>>
>>>> Note that the result of an array-to-pointer conversion is an rvalue
>>>> of type pointer.
>>>>
>>>> The first two paragraphs of 3.10 (Lvalues and rvalues) are
>>>>
>>>> Every expression is either an lvalue or an rvalue.
>>>>
>>>> An lvalue refers to an object or function. Some rvalue expressions
>>>> --- those of class or cv-qualified class type --- also refer to
>>>> objects.
>>>>
>>>> Given the declaration
>>>>
>>>> int z;
>>>>
>>>> the result of the expression z is an lvalue that refers to the object
>>>> where the value of the variable z is stored.
>>>>
>>>> Because a pointer is not of a class or cv-qualified class type, the
>>>> rvalue result of array-to-pointer conversion does not refer to an
>>>> object. In a assignment the left operand needs to refer to an object,
>>>> the one whose value is replaced with that of the right operand of the
>>>> assignment.
>>>>
>>> What did you have for breakfast?
>>
>> What I had for breakfast is irrelevant.
>>
>>> A pointer is not a class , period.
>>
>> I never stated it was. I wrote: "Because a pointer is not of a
>> class or cv-qualified class type, the rvalue result of
>> array-to-pointer conversion does not refer to an object." The "of
>> class or cv-qualified class type" part is from the C++ standard about
>> rvalues that refer to objects. I simply reasoned from statements in
>> the C++ standard to reach a conclusion about details behind why
>> assigning to an array type is not allowed.
>>
>
> So the rvalue result of an array to pointer conversion does not refer to an
> object?
> Well what does it refer to? And what does it mean by "refer to", does this
> mean the same as what it "points to"?

Yes, the result of an array-to-pointer conversion does not refer to
an object. The result is a value that is not in a C++ object.

The C++ standard does not define the term "refer to", although the
term occurs a number of times. It is used in the above quote from
3.10 (Lvalues and rvalues) of the standard, the first sentence of
the second paragraph is:

An lvalue refers to an object or function.

Another place it is used is in paragraph 8 of section 3 (Basic
concepts):

An identifier used in more than one translation unit can
potentially refer to the same entity in these translation units
depending on the linkage (3.5) of the identifier specified in each
translation unit.

"Refers to" is not the same as "points to". Points to is what a
pointer does. An lvalue of a pointer type refers to the object that
contains the pointer value. Given the declaration

int x, *px = &x;

x refers to the object that contains the value of x. px refers to
the object that contains the value of px. px points to the object
that contains the value of x.

> I think you are getting to tied up with language lawyeresque. You cannot see
> the the wood for the trees.

I am not getting tied up with language lawyeresque. When there are
questions about details of C++, the C++ standard is the definitive
source of information about those details.

"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrniufig2.2od7.aggedor@earl-grey.cloud9.net...
> On 2011-06-01, Paul <pchristor@yahoo.co.uk> wrote:
>>> [snip]
>>>
>>>>>> Section 8.3.4 Arrays
>>>>>>
>>>>>> 5 [ Note: conversions affecting expressions of array type are
>>>>>> described
>>>>>> in
>>>>>> 4.2. Objects of array types cannot be modified, see 3.10. -end note ]
>>>>>> §
>>>
>>> [snip]
>>>
>>>>> The sections of the C++ standard cited in the above note give the
>>>>> details of why assigning to an array type is not allowed. Paragraph
>>>>> 1 of section 4.2 (Array-to-pointer conversion) is:
>>>>>
>>>>> 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.
>>>>>
>>>>> Note that the result of an array-to-pointer conversion is an rvalue
>>>>> of type pointer.
>>>>>
>>>>> The first two paragraphs of 3.10 (Lvalues and rvalues) are
>>>>>
>>>>> Every expression is either an lvalue or an rvalue.
>>>>>
>>>>> An lvalue refers to an object or function. Some rvalue expressions
>>>>> --- those of class or cv-qualified class type --- also refer to
>>>>> objects.
>>>>>
>>>>> Given the declaration
>>>>>
>>>>> int z;
>>>>>
>>>>> the result of the expression z is an lvalue that refers to the object
>>>>> where the value of the variable z is stored.
>>>>>
>>>>> Because a pointer is not of a class or cv-qualified class type, the
>>>>> rvalue result of array-to-pointer conversion does not refer to an
>>>>> object. In a assignment the left operand needs to refer to an object,
>>>>> the one whose value is replaced with that of the right operand of the
>>>>> assignment.
>>>>>
>>>> What did you have for breakfast?
>>>
>>> What I had for breakfast is irrelevant.
>>>
>>>> A pointer is not a class , period.
>>>
>>> I never stated it was. I wrote: "Because a pointer is not of a
>>> class or cv-qualified class type, the rvalue result of
>>> array-to-pointer conversion does not refer to an object." The "of
>>> class or cv-qualified class type" part is from the C++ standard about
>>> rvalues that refer to objects. I simply reasoned from statements in
>>> the C++ standard to reach a conclusion about details behind why
>>> assigning to an array type is not allowed.
>>>
>>
>> So the rvalue result of an array to pointer conversion does not refer to
>> an
>> object?
>> Well what does it refer to? And what does it mean by "refer to", does
>> this
>> mean the same as what it "points to"?
>
> Yes, the result of an array-to-pointer conversion does not refer to
> an object. The result is a value that is not in a C++ object.
>
> The C++ standard does not define the term "refer to", although the
> term occurs a number of times. It is used in the above quote from
> 3.10 (Lvalues and rvalues) of the standard, the first sentence of
> the second paragraph is:
>
> An lvalue refers to an object or function.
>
> Another place it is used is in paragraph 8 of section 3 (Basic
> concepts):
>
> An identifier used in more than one translation unit can
> potentially refer to the same entity in these translation units
> depending on the linkage (3.5) of the identifier specified in each
> translation unit.
>
> "Refers to" is not the same as "points to". Points to is what a
> pointer does. An lvalue of a pointer type refers to the object that
> contains the pointer value. Given the declaration
>
> int x, *px = &x;
>
> x refers to the object that contains the value of x. px refers to
> the object that contains the value of px. px points to the object
> that contains the value of x.
>
>> I think you are getting to tied up with language lawyeresque. You cannot
>> see
>> the the wood for the trees.
>
> I am not getting tied up with language lawyeresque. When there are
> questions about details of C++, the C++ standard is the definitive
> source of information about those details.

Well it's you that is introducing all this language lawyeresque stuff.

I am simply trying to get to the bottom of why you think a pointer of type
int* cannot point to an array of integer objects.

On 2011-06-02, Paul <pchristor@yahoo.co.uk> wrote:

[snip]

> I am simply trying to get to the bottom of why you think a pointer of type
> int* cannot point to an array of integer objects.

A pointer of type int* cannot point to an array of int because
converting a pointer to array of T to a pointer to T is not one of
the standard conversions enumerated in section 4 (Standard
conversions) of the C++ standard.

A pointer of type int* can point to an element in an array of int.
Pointing to an array is not the same as pointing to an element in
the array; an array and an element in it do not have the same type.

On 2011-06-03, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrniui6tu.k80.aggedor@earl-grey.cloud9.net...
>> On 2011-06-02, Paul <pchristor@yahoo.co.uk> wrote:
>>
>> [snip]
>>
>>> I am simply trying to get to the bottom of why you think a pointer of
>>> type
>>> int* cannot point to an array of integer objects.
>>
>> A pointer of type int* cannot point to an array of int because
>> converting a pointer to array of T to a pointer to T is not one of
>> the standard conversions enumerated in section 4 (Standard
>> conversions) of the C++ standard.
>>
>> A pointer of type int* can point to an element in an array of int.
>> Pointing to an array is not the same as pointing to an element in
>> the array; an array and an element in it do not have the same type.
>>
>
> Yes pointing to an object of array type , is not the same as pointing to an
> array of objects of integer type.

No, pointing to an array of objects of integer type, that is,
pointing to a C++ array of int, is pointing to an object of array
type. An array of int is an array. An object of type array of int
is an object of array type.

Pointing to an array type is not the same as pointing to an element
type of the array.

> You are defining the term "pointing to an array" to mean poiting to an
> object of array type only. It is quite acceptable to conceive an array as a
> sequence of integer objects rather than one single array type object.
> This is why the types are different.
> It's simply terminology, you see at as one single object, whereas I can see
> it as a single object but also as a sequence of objects.

The C++ sees it as: "An object of array type contains a
contiguously allocated nonempty set of N sub-objects of type T."
Pointing to an array is pointing to an object of array type.
Pointing to a sub-object in an array is pointing to something other
than an object of the array type of the array that the sub-object is
in.

> With the following code..
> int arr[7];
> int* p1 = arr;
> int (*p2)[7] = &arr;
>
> Both the pointers point-to the first element in the array, and both pointers
> also point-to the array of integer objects. They are just different types of
> pointers.
> They both point to exactly the same location.

Both pointers do not point to the first element of the array. p1
points to the first element of the array; p2 points to the array.
An array is not the same as its first element.

> A example of both pointers accessing...;
> a) A single object:
> *p1;
> **p2;
> b) An array of obects:
> *p2;
> for(int i=0; i<7 ; ++i){ p1[i];}
>
> Note that in (b) p1 does not access the integer objects it just accesses the
> array type object. p2 does access the array of integer objects but it does
> not access the array type object.
> They only differ, because of their pointer types, in the way they access the
> array. They both point to exactly the same array but in this different way.

p1 in (b) does not access an array type object. p1 is a pointer to
int. The expression p1[i] is equivalent to *(p1+i). According to
the C++ standard (start of paragraph 5 of 5.7 (Additive operators)):

When an expression that has integral type is added to or subtracted
from a pointer, the result has the type of the pointer operand. If
the pointer operand points to an element of an array object, and
the array is large enough, the result points to an element offset
from the original element such that the difference of the
subscripts of the resulting and original array elements equals the
integral expression.

The result of (p1+i) is a pointer to int that points to the i-th
element from the array element that p1 points to. p1 points to an
array element; it does not point to the array that the element is in.

Unlike p1, p2 is a pointer to an array type object. p2 points to an
array. p1 does not point to an array; it points to the first
element of the array that p2 points to.

> Consider a stack frame pointer, pointing to the stack. It doesn't actually
> point the whole stack at the same time but nonetheless its still considered
> to be pointing to the stack.

There is a significant difference between a stack frame pointer and a
C++ pointer: a C++ pointer is typed. In C++, the result of
dereferencing a pointer to T, where T is a type, is a T.

The result of using a stack frame pointer as an address operand
depends on what the operator does. Different operators move 1, 2, 4,
8, or some other number of bytes to or from storage starting at the
address given by the address operand.

"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrniukoa8.1fj5.aggedor@earl-grey.cloud9.net...
> On 2011-06-03, Paul <pchristor@yahoo.co.uk> wrote:
>>
>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>> news:slrniui6tu.k80.aggedor@earl-grey.cloud9.net...
>>> On 2011-06-02, Paul <pchristor@yahoo.co.uk> wrote:
>>>
>>> [snip]
>>>
>>>> I am simply trying to get to the bottom of why you think a pointer of
>>>> type
>>>> int* cannot point to an array of integer objects.
>>>
>>> A pointer of type int* cannot point to an array of int because
>>> converting a pointer to array of T to a pointer to T is not one of
>>> the standard conversions enumerated in section 4 (Standard
>>> conversions) of the C++ standard.
>>>
>>> A pointer of type int* can point to an element in an array of int.
>>> Pointing to an array is not the same as pointing to an element in
>>> the array; an array and an element in it do not have the same type.
>>>
>>
>> Yes pointing to an object of array type , is not the same as pointing to
>> an
>> array of objects of integer type.
>
> No, pointing to an array of objects of integer type, that is,
> pointing to a C++ array of int, is pointing to an object of array
> type. An array of int is an array. An object of type array of int
> is an object of array type.
>
> Pointing to an array type is not the same as pointing to an element
> type of the array.
>
>> You are defining the term "pointing to an array" to mean poiting to an
>> object of array type only. It is quite acceptable to conceive an array as
>> a
>> sequence of integer objects rather than one single array type object.
>> This is why the types are different.
>> It's simply terminology, you see at as one single object, whereas I can
>> see
>> it as a single object but also as a sequence of objects.
>
> The C++ sees it as: "An object of array type contains a
> contiguously allocated nonempty set of N sub-objects of type T."
> Pointing to an array is pointing to an object of array type.
> Pointing to a sub-object in an array is pointing to something other
> than an object of the array type of the array that the sub-object is
> in.
>
You have quoted some text from that seems to describe an object of array
type.
As I said , and you have proved me correct, you can only see an array as "a
single array type object". You cannot see it at as array of integer
objects( or whatever type it is).



>> With the following code..
>> int arr[7];
>> int* p1 = arr;
>> int (*p2)[7] = &arr;
>>
>> Both the pointers point-to the first element in the array, and both
>> pointers
>> also point-to the array of integer objects. They are just different types
>> of
>> pointers.
>> They both point to exactly the same location.
>
> Both pointers do not point to the first element of the array. p1
> points to the first element of the array; p2 points to the array.
> An array is not the same as its first element.
The address of an array is the same as the address of the first element, and
a pointer is this address.

They both point to exactly the same place and they both point to exactly the
same array. Whether you view it as pointing to an array of pointing to the
first element is just a POV.

>
>> A example of both pointers accessing...;
>> a) A single object:
>> *p1;
>> **p2;
>> b) An array of obects:
>> *p2;
>> for(int i=0; i<7 ; ++i){ p1[i];}
>>
>> Note that in (b) p1 does not access the integer objects it just accesses
>> the
>> array type object. p2 does access the array of integer objects but it
>> does
>> not access the array type object.
>> They only differ, because of their pointer types, in the way they access
>> the
>> array. They both point to exactly the same array but in this different
>> way.
>
> p1 in (b) does not access an array type object. p1 is a pointer to
> int. The expression p1[i] is equivalent to *(p1+i). According to
> the C++ standard (start of paragraph 5 of 5.7 (Additive operators)):

No p1 is not a pointer to integer(singular) , it is a pointer to
integers(plural).
Correct p1 doesn't access the array-type object , but it accesses the array
of integer objects.


>
> When an expression that has integral type is added to or subtracted
> from a pointer, the result has the type of the pointer operand. If
> the pointer operand points to an element of an array object, and
> the array is large enough, the result points to an element offset
> from the original element such that the difference of the
> subscripts of the resulting and original array elements equals the
> integral expression.
>
> The result of (p1+i) is a pointer to int that points to the i-th
> element from the array element that p1 points to. p1 points to an
> array element; it does not point to the array that the element is in.

Look at the expression :
p1 + i;

It's a pointer plus offset(or index).
p1 is pointer to the beginning of the array
i is an offest that indexes the array.

It cannot be any clearer that p1 points to the array.


>
> Unlike p1, p2 is a pointer to an array type object. p2 points to an
> array. p1 does not point to an array; it points to the first
> element of the array that p2 points to.

p1 and p2 point to exactly the same place, and the same array.

>
>> Consider a stack frame pointer, pointing to the stack. It doesn't
>> actually
>> point the whole stack at the same time but nonetheless its still
>> considered
>> to be pointing to the stack.
>
> There is a significant difference between a stack frame pointer and a
> C++ pointer: a C++ pointer is typed. In C++, the result of
> dereferencing a pointer to T, where T is a type, is a T.

No, dereferencing a pointer of type pointer-to-T, will result in a T if it
points to a valid T object.
The pointer type declares a pointer object that can address an object of the
decalred type , for example:
int *p = 0;
p = &ix; /*assume x is valid int*/
p = new int[64];

Here the pointer p is declared to be a pointer of type ptr-to-int, it means
this pointer must be capable of pointing to a valid int object., It has
nothing to do with what it points to.
The above the pointer is shown pointing to nothing, an integer and an array
of integers.

Now consider the following code:
int *p;
What does this point to? Uninitialised memory that could contain anything.
The pointer type only tells us that the declared pointer object is capable
of pointing to an integer, it does not define what is pointed to, as you
have tried to imply.

>
> The result of using a stack frame pointer as an address operand
> depends on what the operator does. Different operators move 1, 2, 4,
> 8, or some other number of bytes to or from storage starting at the
> address given by the address operand.

What you seem to be talking about here is what I know as the PTR keyword in
assembly, it may change in different assemblers.
I don't really see what this has to do with the fundamental concept that a
SFP "points to" a stack frame.

On 2011-06-04, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrniukoa8.1fj5.aggedor@earl-grey.cloud9.net...
>> On 2011-06-03, Paul <pchristor@yahoo.co.uk> wrote:

[snip]

>> The C++ sees it as: "An object of array type contains a
>> contiguously allocated nonempty set of N sub-objects of type T."
>> Pointing to an array is pointing to an object of array type.
>> Pointing to a sub-object in an array is pointing to something other
>> than an object of the array type of the array that the sub-object is
>> in.
>>
> You have quoted some text from that seems to describe an object of array
> type.
> As I said , and you have proved me correct, you can only see an array as "a
> single array type object". You cannot see it at as array of integer
> objects( or whatever type it is).

I have quoted the C++ standard. Seeing it as the C++ standard does
is the proper way to see it when discussing C++, such as in the
comp.lang.c++ newsgroup. Seeing it another way is seeing it in a
way different from the C++ standard.

>>> With the following code..
>>> int arr[7];
>>> int* p1 = arr;
>>> int (*p2)[7] = &arr;
>>>
>>> Both the pointers point-to the first element in the array, and both
>>> pointers
>>> also point-to the array of integer objects. They are just different types
>>> of
>>> pointers.
>>> They both point to exactly the same location.
>>
>> Both pointers do not point to the first element of the array. p1
>> points to the first element of the array; p2 points to the array.
>> An array is not the same as its first element.
> The address of an array is the same as the address of the first element, and
> a pointer is this address.

The first element of an array is at the same memory location as the
array. The value of a C++ pointer is not only a memory location; it
is a typed memory location. Ignoring their types, the p1 and p2 have
the same value; however because p1 and p2 have different types, they
do not point to the same entity. p1 points to the first element of
the array, not to the array; p2 points to the array.

> They both point to exactly the same place and they both point to exactly the
> same array. Whether you view it as pointing to an array of pointing to the
> first element is just a POV.

They do not both point to exactly the same array. One points to an
array; the other may point to an element of that array. The point of
view of the C++ standard is that a

int (*)[]

points to an array of int while a

int *

points to an int, the int it points to may be an element in an array
of int.

>>> A example of both pointers accessing...;
>>> a) A single object:
>>> *p1;
>>> **p2;
>>> b) An array of obects:
>>> *p2;
>>> for(int i=0; i<7 ; ++i){ p1[i];}
>>>
>>> Note that in (b) p1 does not access the integer objects it just accesses
>>> the
>>> array type object. p2 does access the array of integer objects but it
>>> does
>>> not access the array type object.
>>> They only differ, because of their pointer types, in the way they access
>>> the
>>> array. They both point to exactly the same array but in this different
>>> way.
>>
>> p1 in (b) does not access an array type object. p1 is a pointer to
>> int. The expression p1[i] is equivalent to *(p1+i). According to
>> the C++ standard (start of paragraph 5 of 5.7 (Additive operators)):
>
> No p1 is not a pointer to integer(singular) , it is a pointer to
> integers(plural).
> Correct p1 doesn't access the array-type object , but it accesses the array
> of integer objects.

The declarations were

int arr[7];
int* p1 = arr;
int (*p2)[7] = &arr;

p1 is a pointer to an integer. What C++ has available as a pointer to
multiple integers is a pointer to an array of integers, such as p2.
p1 is a pointer to an integer, accessing what p1 points to access
that integer.

>> When an expression that has integral type is added to or subtracted
>> from a pointer, the result has the type of the pointer operand. If
>> the pointer operand points to an element of an array object, and
>> the array is large enough, the result points to an element offset
>> from the original element such that the difference of the
>> subscripts of the resulting and original array elements equals the
>> integral expression.
>>
>> The result of (p1+i) is a pointer to int that points to the i-th
>> element from the array element that p1 points to. p1 points to an
>> array element; it does not point to the array that the element is in.
>
> Look at the expression :
> p1 + i;
>
> It's a pointer plus offset(or index).
> p1 is pointer to the beginning of the array
> i is an offest that indexes the array.
>
> It cannot be any clearer that p1 points to the array.

An element in an array has a different type than the array the
element is in. The type of p1 is int*. When p1 points to an element
of an array of int, it is pointing to an an int, not to an array.
The type of a pointer to an array of int is of the form int(*)[].
The C++ standard is clear about this in the following example from
8.1 (Types).

int // int i
int * // int *pi
int *[3] // int *p[3]
int (*)[3] // int (*p3i)[3]
int *() // int *f()
int (*)(double) // int (*pf)(double)

name respectively the types "int," "pointer to int," "array of 3
pointers to int," "pointer to array of 3 int," "function of (no
parameters) returning pointer to int," and "pointer to a function
of (double) returning int.

The distinction between a pointer to an array and a pointer to an
element of that array is important for multidimensional arrays as
arrays of arrays in C++. The declaration

int x[3][5];

declares an array of 3 array of 5 int. The expression x[i][j] is
equivalent to *(*(x+i)+j). When that expression is evaluated

- x is an array of 3 array of 5 int
- array-to-pointer conversion results in a pointer to the first array
of 5 int in x
- adding i results in a pointer to the i-th array of 5 int in x
- dereferencing that results in the i-th array of 5 int in x
- array-to-pointer conversion results in a pointer to the first int in
the i-th array of 5 int in x
- adding j results in a pointer to the j-th int in the i-th array of
5 int in x
- dereferencing that result in the j-th int in the i-th array of 5 int
in x

Multidimensional arrays in C++ depend on the distinction between a
pointer to an array and a pointer to an element of that array. Not
understanding this distinction may lead to confusion.

>> Unlike p1, p2 is a pointer to an array type object. p2 points to an
>> array. p1 does not point to an array; it points to the first
>> element of the array that p2 points to.
>
> p1 and p2 point to exactly the same place, and the same array.

p1 and p2 have different types. p1 points to an int, not to an
array. p2 points to an array of 7 int.

>>> Consider a stack frame pointer, pointing to the stack. It doesn't
>>> actually
>>> point the whole stack at the same time but nonetheless its still
>>> considered
>>> to be pointing to the stack.
>>
>> There is a significant difference between a stack frame pointer and a
>> C++ pointer: a C++ pointer is typed. In C++, the result of
>> dereferencing a pointer to T, where T is a type, is a T.
>
> No, dereferencing a pointer of type pointer-to-T, will result in a T if it
> points to a valid T object.
> The pointer type declares a pointer object that can address an object of the
> decalred type , for example:
> int *p = 0;
> p = &ix; /*assume x is valid int*/
> p = new int[64];

What I have written is about what a C++ compiler does, along the
lines of what the C++ standard does in the folliwng sentence about
the unary * operator: "If the type of the expression is pointer to T,
the type of the result is T." These post are long enough without
adding possible undefined behaviors when the program runs due to the
value of a pointer to a non-polymorphic type.

> Here the pointer p is declared to be a pointer of type ptr-to-int, it means
> this pointer must be capable of pointing to a valid int object., It has
> nothing to do with what it points to.
> The above the pointer is shown pointing to nothing, an integer and an array
> of integers.

What is shown is p having the null pointer value, pointing to an
integer, and pointing to the first integer in an array of integers
(the result of the expression (new int[64]) is a pointer to int,
not a pointer to array of int).

> Now consider the following code:
> int *p;
> What does this point to? Uninitialised memory that could contain anything.
> The pointer type only tells us that the declared pointer object is capable
> of pointing to an integer, it does not define what is pointed to, as you
> have tried to imply.

It is undefined what p points to. I have used shorter phrases, such
as "is a T", rather than a longer ones, such as "is of type T". You
are misreading "is a T" as "is an object of type T that exists when
the program runs".

>> The result of using a stack frame pointer as an address operand
>> depends on what the operator does. Different operators move 1, 2, 4,
>> 8, or some other number of bytes to or from storage starting at the
>> address given by the address operand.
>
> What you seem to be talking about here is what I know as the PTR keyword in
> assembly, it may change in different assemblers.
> I don't really see what this has to do with the fundamental concept that a
> SFP "points to" a stack frame.

In that case, you don't really see the difference between a value
with the correct number of bits to be used as an address in assembler
and a C++ pointer. C++ pointers are typed.

On Jun 6, 2:04*pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> He's a troll. Don't feet the troll.

Don't feed* the troll.