Problem with array objects

[Paul]

On 01/06/2011 19:44, 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.
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?

 

[Joshua Maurice]

Consider the following:

void* p1 = (void*)new int;
void* p2 = (void*)new int[55];

p1 points to a single integer.
p2 points to an array of integers.

This is what I mean when I say 'ip' is a pointer to an array. I don't
mean it's type, I am talking about what it points to.

Oh ...  uh...  I'm not sure how to discuss this.

When you say "I don't mean its type" - do you mean to imply that you are now
no longer talking about/referring to the C/C++ language definition, but
something else?

I'll repeat what I've said before. When you say "x is a pointer to
<Y>", this is a claim about the (static) type of x. When you say "x
points to <Y>", this is a claim about the value of x at runtime. At
least, that's how almost all reasonable people interpret it. Paul
conflates the two terminologies, and he uses either one depending "on
his mood". He claims that "x is a pointer to an array of int" is not a
claim about the type of x, but merely a claim about the runtime value
of x. He really ought to say "x points to" instead of "x is a pointer
to", but Paul ought to do a lot of things differently w.r.t. his
incorrect use of words.

 

[Paul]

On 01/06/2011 20:10, Paul wrote:
[snip]

I believe that would be the terminology that is most accepted and
most
closely
matches the language definition.

Well I draw your attention so a couple of quotes from highly regarded
experts who think in the same way as me:
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 [footnote]"

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. "

Appealing to authority is a logical fallacy; you have been told this
before; try paying attention.

I don't know what you mean by "appealing to authority" because I am not
appealing to anyone.

http://en.wikipedia.org/wiki/Appeal_to_authority

I was simply showing that the terminology I use is also used by
respected experts.

http://en.wikipedia.org/wiki/Appeal_to_authority


'char*' cannot point to an array of char; 'char*' can only ever point
to a single char object (or no object at all):

Perhaps you do know C++ better than Bjarne Stroustrup or Steve Summit,
perhaps you don't.

What has Bjarne Stroustrup knowing C++ better than me got to do with
anything? We all make mistakes; we all sometimes write something which
is less formal or less technically accurate than it should be; you
certainly are.

Who are you to say they are technically inaccurate?

Who are you to say they are not technically inaccurate on this particular
occasion?

I never said they were , I just suggested there was a high probability that
they were mor elikely to be more accurate than you.

The C faqs are easily ammended, if SS is technically inaccurate then he
would have corrected it by now.
BS's site was modified in 2007, I'm sure he has revised this site and
would have corrected any technically inaccurate information.

I'm sure both these sites have been scrutinised by many programmers and
any inaccuracies would be corrected. They don't just throw these pages
online without first checking them for technical accuracy.

What amazing Internet insights you have.

Whatever the case may be I prefer to think that a pointer that points
to
an array of chars is of type char*. Having said that I also fully
understand that there can be a pointer type char (*)[n], but I see that
as a pointer with a different level of indirection that is most
commonly
used as a pointer to a 2d array because it requires two dereferences to
access the array of chars that it points to.

'char(*)[n]' is a pointer to a 1D array not a pointer to a 2D array;
the first dereference evaluates to a reference to the array and the
second dereference evaluates to a reference to the array element.

The C++ standard states that a when a 2d array is converted to a
pointer....:
"If the * operator, either explicitly or implicitly as a result of
subscripting, is applied to this pointer, the result is the pointed-to
(n ? 1)-dimensional array, which itself is immediately converted into a
pointer."

The key phrase here is "the pointed-to (n ? 1)-dimensional array". This
means the pointed-to (n)-dimensional array is a 2d array because the
resulting (n-1)-dimensional array is a 1d array.

You have repeated this citation on multiple occasions to try and refute
the same *fact* on multiple occasions; each time the citation is unrelated
to the fact; each time you have been wrong.

'char(*)[N]' is a pointer to a 1D array not a pointer to a 2D array and
nothing in the Standard contradicts this *fact*.

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?

If you are comfortable with your state of wrongness then that is your
lookout.

I don't see what is wrong with it.

 

[Joshua Maurice]

An array of integer objects is a sequence of objects of int type. A
pointer that points to them is of type int*.
Where do you see the difference in type, other than one is a pointer
type and the other not?

int *ip;        // pointer to int
int arr[10];    // array of int

These are not the same type. Look it up.

For example:
int* p = new int[100];

Creates an object of type array of 100 int, converts it to type  int*,
and stores the result in p.

int i = 3.1;

Creates an object of type double, converts it to type int, and stores
the result in i.

Being able to convert one type into another does not make the types the same.

Technically, the "type conversion", if there is one, happens inside
new int[100]. The type of the expression "new int[100]" is "int*". It
is not "int[100]". Thus there is no conversion in "int* p = new
int[100]".

Still, I appreciate your intent.

 

[Ian Collins]

I don't see what is wrong with it.

There lies the root of the problem.

 

[Paul]

There is no need for this sarcasm, I fully appreciate the mammoth task of
creating the C++ standard.

But you cannot have it both ways, you want an array to be a non
modifiable object of array type when we discuss pointers to arrays, but
in other situations you want an array to be a sequence of objects.

The two are not inherently inconsistent. And when you see potential
conflicts in the way things are described you can either proclaim that
they are irreconcilable and anyone trying to reconcile them is an idiot,
or you can look for a way to read them that makes them consistent; the
latter may require accepting an interpretation that's different from your
preconceived notions.

Also this object of array type is not clearly defined in the C++
standards.
What exactly is this non modifiable object of array type, is it an object
or is it a type?

You're kidding, right? A *non modifiable object* is an object.

If its an object then , as defined in the standards, an object is a
region of storage, so where is this object stored?

Wherever the compiler puts it.

It cannot be stored int he same region as its elements because that
region of storage is modifiable.

int arr[5];
int arr0[5];
arr = arr0; // error: arr is not a modifiable object
arr[0] = 3; // Ok: array element is modifiable

--

So 'arr' is an object in its own right?
I can understand this as array has a value of an address to the first
element.

So is it correct that 'arr' is a non modifiable object of array type that is
not the same object as the modifiable integer objects it represents?

 

[Joshua Maurice]

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.

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.)

(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. 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.

The problem is that people can interpret the standards in different ways,
and when the majority of people in a given group come to a consensus about
the interpreted meaning, that is the defined meaning.
But a technical standard should define what it is written to define , nota
clique of people who have a common concencus of its interpretation.

Well, we're in agreement on that point. All of us just think that you
are wrong in your readings and interpretations.

 

[Paul]

Consider:

struct X { mutable int n; };

int main()
{
const X x1 = {0};
X x2 = {1};

x1 = x2; // Error, x1 isn't modifiable.
x1.n = x2.n; // OK, x1.n is.
}

Are there two instances of x1?

When you modify x1.n you also modify x1.
x1 has ben modified so how can you say its a non modifable object.

 

[Joshua Maurice]

When you modify  x1.n you also modify x1.
x1 has ben modified so how can you say its a non modifable object.

It's easy. Consider:
int x = 0;
int const& y = x;
We say that "y" is non-modifiable. That is, you cannot modify the
object referred to by "y" through the expression "y". However, you can
modify the object referred to by "y" through other expressions, such
as "x". Ex:
x = 1;
There. I just modified "y" when "y" is non-modifiable.

 

[Paul]

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?

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?

class Foo{}
class Barublic Foo{}

Bar b;

Does b have a sub-object of type Foo?
Is this also a sub-object but in a different way?

(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.

--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.

The problem is that people can interpret the standards in different ways,
and when the majority of people in a given group come to a consensus about
the interpreted meaning, that is the defined meaning.
But a technical standard should define what it is written to define , not
a
clique of people who have a common concencus of its interpretation.

--Well, we're in agreement on that point. All of us just think that you
--are wrong in your readings and interpretations.

Glad your in the majority, bet it makes you feel good

 

[Paul]

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?

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?

class Foo{}
class Barublic Foo{}

Bar b;

Does b have a sub-object of type Foo?
Is this also a sub-object but in a different way?

(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.

--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.

The problem is that people can interpret the standards in different ways,
and when the majority of people in a given group come to a consensus about
the interpreted meaning, that is the defined meaning.
But a technical standard should define what it is written to define , not
a
clique of people who have a common concencus of its interpretation.

--Well, we're in agreement on that point. All of us just think that you
--are wrong in your readings and interpretations.

Glad your in the majority, bet it makes you feel good

 

[Paul]

For example:
int* p = new int[100];

Creates an object of type array of 100 int, converts it to type int*,
and stores the result in p.

Ok this is interesting, so an object of array type is created but its
must be a temporary.

No, it's not a temporary. It's an object with dynamic storage duration.

Can you please give an example of how to access this object, I don't see
what this object is.

 

[Paul]

For example:
int* p = new int[100];

Creates an object of type array of 100 int, converts it to type int*,
and stores the result in p.

Ok this is interesting, so an object of array type is created but its
must be a temporary.

No, it's not a temporary. It's an object with dynamic storage duration.

Can you please give an example of how to access this object, I don't see
what this object is.

 

[Paul]

[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.

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?

 

[Joshua Maurice]

--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.

--    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.

--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".

 

[Paul]

When you modify x1.n you also modify x1.
x1 has ben modified so how can you say its a non modifable object.

--It's easy. Consider:
-- int x = 0;
-- int const& y = x;
--We say that "y" is non-modifiable. That is, you cannot modify the
--object referred to by "y" through the expression "y". However, you can
--modify the object referred to by "y" through other expressions, such
--as "x". Ex:
-- x = 1;
--There. I just modified "y" when "y" is non-modifiable.

'y' is a reference , you did not modify 'y'. To modify 'y' you would need to
make it reference another object.

 

[Paul]

The problem is that people can interpret the standards in different
ways, and when the majority of people in a given group come to a
consensus about the interpreted meaning, that is the defined meaning.
But a technical standard should define what it is written to define ,
not a clique of people who have a common concencus of its
interpretation.

I look forward to seeing your rewrite of the C++ standard with all the
problems you perceive fixed so that no reader could possibly interpret
it differently from what you intended. When will it be available?

There is no need for this sarcasm, I fully appreciate the mammoth task
of creating the C++ standard.

But you cannot have it both ways, you want an array to be a non
modifiable object of array type when we discuss pointers to arrays, but
in other situations you want an array to be a sequence of objects.

The two are not inherently inconsistent. And when you see potential
conflicts in the way things are described you can either proclaim that
they are irreconcilable and anyone trying to reconcile them is an idiot,
or you can look for a way to read them that makes them consistent; the
latter may require accepting an interpretation that's different from
your preconceived notions.

Also this object of array type is not clearly defined in the C++
standards.
What exactly is this non modifiable object of array type, is it an
object or is it a type?

You're kidding, right? A *non modifiable object* is an object.


If its an object then , as defined in the standards, an object is a
region of storage, so where is this object stored?

Wherever the compiler puts it.

It cannot be stored int he same region as its elements because that
region of storage is modifiable.

int arr[5];
int arr0[5];
arr = arr0; // error: arr is not a modifiable object
arr[0] = 3; // Ok: array element is modifiable

--

So 'arr' is an object in its own right?
I can understand this as array has a value of an address to the first
element.

That's not what the standard says. It says that the name of an array
*decays* into a pointer to the first element in most contexts.

So is it correct that 'arr' is a non modifiable object of array type that
is not the same object as the modifiable integer objects it represents?

That's far too metaphysical for me.

What is this non modifiable object of array type?
Can you define exactly what this object is, or is it beyond you in some
metaphysical way?

 

[Ian Collins]

When you modify x1.n you also modify x1.
x1 has ben modified so how can you say its a non modifable object.

Is this clearer?

class X
{
X& operator=(const X&);

public:

int n;
};

int main()
{
X x1 = {0};
X x2 = {1};

x1 = x2;
x1.n = x2.n;
}

 

[Paul]

--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.

-- 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.

--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.

 

[crisgoogle]

On 2011-06-01 11:31:35 -1000, Paul said:

For example:
int* p = new int[100];
Creates an object of type array of 100 int, converts it to type  int*,
and stores the result in p.
Ok this is interesting, so an object of array type is created but its
must be a temporary.

No, it's not a temporary. It's an object with dynamic storage duration.

Can you please give an example of how to access this object, I don't see
what this object is.

You access it via the pointer to its first element, which was just
handed to you:

p[0] accesses the first element of the array object, etc.