«

Paul wrote:

>>> The difference is the possible sequences of execution given the
>>> following scenario of recursion.
>>>
>>> sort(){
>>> this = new anObjType; /*replace the object the function belongs to*/
>>
>> You can't change the this pointer. It is constant, so the compiler will
>> bail
>> out with an error at this point.
>
> This is psuedo code, you can change the object 'this' points to using any
> code you like, obviously that's assuming the object is not stored in
> read-only memoery.

The above code doesn't change the object, it changes the this-pointer.

> Sorry I should've made a specific note about psuedo code. I presumed it
> was obvious following from the context of my previous example.

Actually, I don't know what that code is supposed to tell me.

>>> (*this).sort(); /*re-invoke this function is not possible, what
>>> does
>>> 'this' point to?*/
>>> }
>>>
>>> sort(anObj){
>>> anObj = new anObjTye; /*replacing the object( heap or stack
>>> whatever,
>>> the code is psuedo)*/
>>> pointertothisfunction(anObj) /*Ok to call this function, recursion
>>> is ok
>>> with a new object.*/
>>> }
>>>
>>>
>>> The member function version does not have the same possible sequences of
>>> execution as the normal version.
>>> The member function version has an object identity, it belongs to the
>>> object on which it is called.
>>
>> Within the member function, the this-pointer is const, and so you can't
>> assign to it. If you declare your non-member function as:
>>
>> sort(sometype* const anObj)
>>
>> you'll have the same problem as with the member function.
>>
> The constantness is not rellevant to understand the point as code can be
> written to overcome that.

Not in a standard compliant way.

> Neither the stack nor the heap is read only. The object 'this' points to
> is likely to be in one of these areas, therefore overwriteable.

You should decide whether you want to look at it from the C++ standard point
of view or from "behind the scenes". The heap, the stack and the concept of
read only memory are not defined in C++. They are rather an implementation
detail. On that level, non-static member functions are implemented the same
as non-member functions, but with the address of the object as a hidden
parameter.
On the C++ level on the other hand, you have a pointer that is initially
declared const, and the C++ standard says that casting away constness of
such an object results in undefined behavior. So you cannot modify the this-
pointer in a member function, and neither can you modify anObj in:

>> sort(sometype* const anObj)

On Feb 22, 6:58 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "James Kanze" <james.ka...@gmail.com> wrote in message

> news:6a6f42d5-65ef-4431-a62f-...
> On Feb 22, 11:41 am, "Paul" <pchris...@yahoo.co.uk> wrote:

> > Is an nonstatic member function call the same as an ordinary function call
> > (with a hidden parameter)?
> > Two people , namely James Kanze and Itaj Sherman have been trying to
> > persuade me that a call to a nonstatic member function is exactly the same
> > as an ordinary function call.

> --Not exactly the same, but fundamentally the same.

> Ah ok sorry misunderstanding.

> > I disagree with them because I think the C++ standard disagrees with them.

> --The C++ standard does specify significant differences in the
> --calling syntax (e.g. in 5.2.2).
> Ok so this is the syntaxical rules we must obey, is it not?

It's just syntax. It's arbitrary. And superficial. (Other
languages use different syntax to achieve largely the same
thing. And there have been proposals---which I would
support---to unify the C++ syntax, so that for a member
function, obj.func() and func(obj) have exactly the same
meaning.)

> -- Beyond that, however, it
> --requires the this pointer to be initialized exactly as if it
> --were a reference to an object (except that it is initialized
> --with pointer type, and not with reference type). And it
> --certainly treats them the same in overload resolution. There's
> --no fundamental difference between them.

> Now I find what you say here slightly confusing.
> You say "beyond that" which I take to mean ..Beyond the definition of the
> standard, in your previous sentence.

Beyond simple syntax.

> Then you go on about what the standard requires for
> initialisation of the this pointer. Surely we must either
> speak in terms of the standard or not, you seem to jump in and
> out of standards context when it suits you.

I'm speaking purely within the context of the standard here.
The standard describes member functions as behaving
fundamentally like free functions with an additional implicite
argument. And for cause---it very definitely intends that an
implementation which does this be legal.

> But ignoring that, what you actually speak about is initialisation of the
> this pointer, which I presume is a pointer, yes?

Yes and no. It's certainly not a variable with pointer type,
since it's not an lvalue.

> You seem to intepret the this pointer a reference, surely the this pointer
> is not required to be converted to a refernece, this seems like an
> unneccessarry converion forced upon a compiler i.e :
> pointer -> reference -> pointer. (why?)

The semantics of the implicit argument used to initialize the
this pointer are the semantics of a reference, and the this
pointer behaves semantically like a reference: it cannot be
null, and it cannot be reseated. When asked why "this" is not
a reference, Stroustrup says "because references didn't exist
when it was introduced." In other words, if they had, this
would probably be a reference.

> Don't get me wrong I understand what you are saying about the
> underlying mechanics of a nonvirtual function call, but the
> issue here is: Are we allowed to do this as per the C++ std,
> which is the general concensus of this group to determine
> proper C++ code.

Allowed to do what? The standard is carefully crafted so that
existing implementation techniques would be legal. The most
widespread (the only, as far as I know) technique for
implementing member functions is as a normal function with
an additional implicit argument. The standard is carefully
worded so that this implementation is legal. The result is that
member functions and non member functions are pretty much the
same thing, when viewed from a standards point of view.

> --There are other subtle differences: a non-const member function
> --can be called on a temporary, where as a non-const reference
> --cannot be initialized with a temporary, for example.
> I see again you introduce references , this obviously has seem to be a
> requirement for you argument.

> I don't see the need to have any references when calling a member function,
> therefore this continued use of referneces in your demonstrations leads me
> to believe there is something wrong.

I introduce references because the implicit argument used to
initialize the this pointer behaves like a reference.

> Can you not give an example using simple pointers ?

No, because a simple pointer can be null, and it can be
reseated. This is a pointer for historical reasons, but except
for syntax, it behaves like a reference.

> -- But in the
> --other thread, you were looking for things that would make
> --member functions fundamentally different from non-members.

> I'm not looking for something to make them different , I know they are
> different. I'm trying to understand why you think it's beneficial to think
> of them as the the same.

Because they are fundamentally the same.

> One word proves they're different ...virtual.

That's a different issue. Although the standard also describes
virtual functions as being fundamentally the same as any other
function. The only thing that differs is which function is
actually choosen. A sort of overloading, deferred to runtime.

Note that although C++ chooses to limit virtual functions to
members, there's no fundamental reason why this should be the
case.

> As below we must respectively assume you are obviously not talking about
> virtual functions

> --Where as I fail to see anything but syntax differences between
> --titi and tata in the following:
> -- struct Toto
> -- {
> -- void titi() const;
> -- friend void tata(Toto const&);
> -- };
> --This is, of course, an extreme case of similarity. But my point
> --is that except for syntax, member functions have a series of
> --characteristics that can, in specific cases, apply to non member
> --functions as well.

> Yes I agree.

> But that syntax difference means we are not allowed to do the following, or
> does it:

> struct ObjT{
> void mthd(){};
> };

> ObjT o;
> mthd(o); /*I do not understand this is uncharted waters to me*/

That has been proposed. It was too late for C++98, and for some
reason, the proposal has not be followed up for C++0x. The
basic proposal was that o.mthd() and mthd(o) mean exactly the
same thing. (The proposal was never really studied, so there
could be significant problems with it.)

> mthd(&o) /*or is this what you propose?its not a reference I know*/
> o.mthd() /*my normal calling syntax*/

> I don't know if any of the above is proper code I didn't try to compile
> anything, please can you explain what is valid as per the standard.

The only point is that whether you write o.mthd() or mthd(o) is
purely syntax. (IIRC, Ada 95 chose the second form.) It has
nothing to do with what a function fundamentally is or is not.

--
James Kanze

"Rolf Magnus" <> wrote in message
news:ik2sjn$dhn$01$...
> Paul wrote:
>
>>>> The difference is the possible sequences of execution given the
>>>> following scenario of recursion.
>>>>
>>>> sort(){
>>>> this = new anObjType; /*replace the object the function belongs
>>>> to*/
>>>
>>> You can't change the this pointer. It is constant, so the compiler will
>>> bail
>>> out with an error at this point.
>>
>> This is psuedo code, you can change the object 'this' points to using any
>> code you like, obviously that's assuming the object is not stored in
>> read-only memoery.
>
> The above code doesn't change the object, it changes the this-pointer.
>
The above code doesnt do anything its psuedo code, it explains what real
code would do.

>> Sorry I should've made a specific note about psuedo code. I presumed it
>> was obvious following from the context of my previous example.
>
> Actually, I don't know what that code is supposed to tell me.

If you are unable to understand then so be it I cannot it explain it any
simpler .

<snip>

"James Kanze" <> wrote in message
news:bfb026f9-f16f-410f-87b5-...
> On Feb 22, 6:58 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>> "James Kanze" <james.ka...@gmail.com> wrote in message
>
>> news:6a6f42d5-65ef-4431-a62f-...
>> On Feb 22, 11:41 am, "Paul" <pchris...@yahoo.co.uk> wrote:
>
>> > Is an nonstatic member function call the same as an ordinary function
>> > call
>> > (with a hidden parameter)?
>> > Two people , namely James Kanze and Itaj Sherman have been trying to
>> > persuade me that a call to a nonstatic member function is exactly the
>> > same
>> > as an ordinary function call.
>
>> --Not exactly the same, but fundamentally the same.
>
>> Ah ok sorry misunderstanding.
>
>> > I disagree with them because I think the C++ standard disagrees with
>> > them.
>
>> --The C++ standard does specify significant differences in the
>> --calling syntax (e.g. in 5.2.2).
>> Ok so this is the syntaxical rules we must obey, is it not?
>
> It's just syntax. It's arbitrary. And superficial. (Other
> languages use different syntax to achieve largely the same
> thing. And there have been proposals---which I would
> support---to unify the C++ syntax, so that for a member
> function, obj.func() and func(obj) have exactly the same
> meaning.)
>
What an idiotic statement to make.
The syntax *is* the language.

>> -- Beyond that, however, it
>> --requires the this pointer to be initialized exactly as if it
>> --were a reference to an object (except that it is initialized
>> --with pointer type, and not with reference type). And it
>> --certainly treats them the same in overload resolution. There's
>> --no fundamental difference between them.
>
>> Now I find what you say here slightly confusing.
>> You say "beyond that" which I take to mean ..Beyond the definition of the
>> standard, in your previous sentence.
>
> Beyond simple syntax.
What simple syntax? Not that language we call C++ you talking about . BTW
why does it have a differnet name from other programming languages? they're
all the same except for syntax..duh .

So I was correct you do jump in and out of the standards when you choose?
>
>> Then you go on about what the standard requires for
>> initialisation of the this pointer. Surely we must either
>> speak in terms of the standard or not, you seem to jump in and
>> out of standards context when it suits you.
>
> I'm speaking purely within the context of the standard here.
> The standard describes member functions as behaving
> fundamentally like free functions with an additional implicite
> argument. And for cause---it very definitely intends that an
> implementation which does this be legal.

You are not speaking in the context of the , show us where the standard
states what you claim.

I have provided a quote from the stantard that says a member function call
is different from a normal function.


I am really getrtting sick the brainless idiots in this newsgroup speaking
****,
I'm on the verge of telling you to just go and **** off , your argument is
so idioticly unreasonable.


>> But ignoring that, what you actually speak about is initialisation of the
>> this pointer, which I presume is a pointer, yes?
>
> Yes and no. It's certainly not a variable with pointer type,
> since it's not an lvalue.

Yes and no... I chose what I want when I want it to mean wahtever I want it
to mean

>
>> You seem to intepret the this pointer a reference, surely the this
>> pointer
>> is not required to be converted to a refernece, this seems like an
>> unneccessarry converion forced upon a compiler i.e :
>> pointer -> reference -> pointer. (why?)
>
> The semantics of the implicit argument used to initialize the
> this pointer are the semantics of a reference, and the this
> pointer behaves semantically like a reference: it cannot be
> null, and it cannot be reseated. When asked why "this" is not
> a reference, Stroustrup says "because references didn't exist
> when it was introduced." In other words, if they had, this
> would probably be a reference.
>
>> Don't get me wrong I understand what you are saying about the
>> underlying mechanics of a nonvirtual function call, but the
>> issue here is: Are we allowed to do this as per the C++ std,
>> which is the general concensus of this group to determine
>> proper C++ code.
>
> Allowed to do what? The standard is carefully crafted

Is it hell carefully crafted and neither are your invaLID ARGUMENTS.
GO **** yoursefl and your stupid arguments along with the rest of your
homosexual friends in the newsgroup.

Had enough of your unreasonable arguments , go just a ****ing idiot after
all.

YOUR ****ING WRONG1 why? BEcause I ****in siad SO you IDIOT.

On Feb 23, 11:41*am, "Paul" <pchris...@yahoo.co.uk> wrote:
> > The member function version has an object identity,?
> >>What does this mean?
>
> It means each *function invokation is attached to a unique object

What does this mean?

"gwowen" <> wrote in message
news:d1ccbe74-2f8e-428b-9a2d-...
On Feb 23, 11:41 am, "Paul" <pchris...@yahoo.co.uk> wrote:
> > The member function version has an object identity,?
> >>What does this mean?
>
> It means each function invokation is attached to a unique object

--What does this mean?

It means you are probably a bit stupid
bye I got more important things to do.

James Kanze wrote:

>> You seem to intepret the this pointer a reference, surely the this
>> pointer is not required to be converted to a refernece, this seems like
>> an unneccessarry converion forced upon a compiler i.e :
>> pointer -> reference -> pointer. (why?)
>
> The semantics of the implicit argument used to initialize the
> this pointer are the semantics of a reference, and the this
> pointer behaves semantically like a reference: it cannot be
> null, and it cannot be reseated.

Syntactically and semantically, it behaves like a pointer that is constant.
And it cannot be null, because it's constant and always initialized with the
object's address.

> The only point is that whether you write o.mthd() or mthd(o) is
> purely syntax. (IIRC, Ada 95 chose the second form.) It has
> nothing to do with what a function fundamentally is or is not.

In Python, you can use both, and the "this" pointer (or rather "self"
reference) is an explicit parameter usually called "self", but since it's
just a parameter, you can basically name it whatever you want. A static
member function is simly one that does not have the self parameter.

On Feb 23, 5:34 pm, Rolf Magnus <ramag...@t-online.de> wrote:
> James Kanze wrote:
> >> You seem to intepret the this pointer a reference, surely the this
> >> pointer is not required to be converted to a refernece, this seems like
> >> an unneccessarry converion forced upon a compiler i.e :
> >> pointer -> reference -> pointer. (why?)

> > The semantics of the implicit argument used to initialize the
> > this pointer are the semantics of a reference, and the this
> > pointer behaves semantically like a reference: it cannot be
> > null, and it cannot be reseated.

> Syntactically and semantically, it behaves like a pointer that is constant.

No. It's not an lvalue. (You can't take its address, for
example.) It's a keyword, with a special meaning. Syntacticly,
a pointer (it has pointer type); semantically, more like
a reference; in reality, neither, but something special.

--
James Kanze

"Rolf Magnus" <> wrote in message
news:ik2sjn$dhn$01$...
> Paul wrote:
>
>>>> The difference is the possible sequences of execution given the
>>>> following scenario of recursion.
>>>>
>>>> sort(){
>>>> this = new anObjType; /*replace the object the function belongs
>>>> to*/
>>>
>>> You can't change the this pointer. It is constant, so the compiler will
>>> bail
>>> out with an error at this point.
>>
>> This is psuedo code, you can change the object 'this' points to using any
>> code you like, obviously that's assuming the object is not stored in
>> read-only memoery.
>
> The above code doesn't change the object, it changes the this-pointer.
>
>> Sorry I should've made a specific note about psuedo code. I presumed it
>> was obvious following from the context of my previous example.
>
> Actually, I don't know what that code is supposed to tell me.
>
>>>> (*this).sort(); /*re-invoke this function is not possible, what
>>>> does
>>>> 'this' point to?*/
>>>> }
>>>>
>>>> sort(anObj){
>>>> anObj = new anObjTye; /*replacing the object( heap or stack
>>>> whatever,
>>>> the code is psuedo)*/
>>>> pointertothisfunction(anObj) /*Ok to call this function, recursion
>>>> is ok
>>>> with a new object.*/
>>>> }
>>>>
>>>>
>>>> The member function version does not have the same possible sequences
>>>> of
>>>> execution as the normal version.
>>>> The member function version has an object identity, it belongs to the
>>>> object on which it is called.
>>>
>>> Within the member function, the this-pointer is const, and so you can't
>>> assign to it. If you declare your non-member function as:
>>>
>>> sort(sometype* const anObj)
>>>
>>> you'll have the same problem as with the member function.
>>>
>> The constantness is not rellevant to understand the point as code can be
>> written to overcome that.
>
> Not in a standard compliant way.
>
>> Neither the stack nor the heap is read only. The object 'this' points to
>> is likely to be in one of these areas, therefore overwriteable.
>
> You should decide whether you want to look at it from the C++ standard
> point
> of view or from "behind the scenes". The heap, the stack and the concept
> of
> read only memory are not defined in C++. They are rather an implementation
> detail. On that level, non-static member functions are implemented the
> same
> as non-member functions, but with the address of the object as a hidden
> parameter.

Their whole argument is non standard, the basis of thier argument is that we
ignored the whole C++ syntax altogether and assume there is some other
syntax.

> On the C++ level on the other hand, you have a pointer that is initially
> declared const, and the C++ standard says that casting away constness of
> such an object results in undefined behavior. So you cannot modify the
> this-
> pointer in a member function, and neither can you modify anObj in:
>
The fact that this is const actually supports the point I was making.


However I can't be arsed arguing with people who believe it is reasonable to
be non standard when it suits them yet any arguments against them must
always be in the context of the standards.

On Feb 23, 10:52*am, "Paul" <pchris...@yahoo.co.uk> wrote:
> " Tiib" <oot...@hot.ee> wrote in message
>
> news:feef80b6-5cfe-47d0-a6d4-...
> <snip headers>
>
>
>
>
>
> > >> -- But in the
> > >> --other thread, you were looking for things that would make
> > >> --member functions fundamentally different from non-members.
>
> > >> I'm not looking for something to make them different , I know they are
> > >> different. I'm trying to understand why you think it's beneficial to
> > >> think
> > >> of them as the the same.
>
> > > --But they are logically same. For example when i see two lines of code:
>
> > > -- bag1.sort();
> > > -- sort( bag2 );
>
> > > --Should i think that different things happened to bag1 and bag2? Nope.
> > > --I only think that both objects got sorted, only that sorting
> > > --functionality was delivered syntactically differently by interface of
> > > --their classes. Also i see nothing why to call one of them OOP and
> > > --other non-OOP.
>
> > > The obvious difference in the above is:
> > > bag1.sort() /*sort is a member function of bag 1*/
> > > sort(bag2) /*sort is not a memeber function*/
>
> > > Inside the member function we have access to the this pointer. The term
> > > "this" suggests an object identity. The following does not work:
> > > void sort(){
> > > overwrite the object 'this' points to; (with _thiscall: mov ecx, 0 would
> > > do it)
> > > call thisfunction; /*'this' == ?? */
> > > }
>
> > > Normal sort() does not have a this pointer , there is no similar object
> > > identity. Within normal sort() the object passed as a parameter has no
> > > control over the lifetime of the function.
> > > The following applies for the normal sort() function:
> > > void sort(anObject){
> > > overwrite anObject ;
> > > call thisfunction(anObject) ; /* anObject is OK, it contains what we
> > > overwrit it with*/
> > > }
>
> > You did not comment on this, do you understand what I am explaining?
>
> --Yes, i understand. For me both the functions are part of A's
> --interface:
> --void A:neOperation() {/* code operating on this */}
> --void otherOperation( A& that ) {/* code operating on that */}
>
> --What is the big matter if there is pointer "this" or reference "that"?
> --The otherOperation() is even more OOP for me since it accesses only
> --public interface of class A and does not mess with dirty inner
> --details. So i know that if i for some performance reasons have to
> --refactor implementation details of A leaving its public interface same
> --then i don't need to modify otherOperation (or tests written for it).
>
> Forgetting about operator oveloading , I am talking about what sort()
> initially seemed to be proposed as, specifically:
> anObj.sort(); /*A member function of anObject*/
> sort(anObj) /*A normal function with 'this' passed explicitly as a
> parameter*/
>
> The difference is the possible sequences of execution given the following
> scenario of recursion.
>
> sort(){
> * * this = new anObjType; /*replace the object the function belongsto*/
> * * (*this).sort(); */*re-invoke this function is not possible, what does
> 'this' point to?*/
> }

Does not compile. What compiles is:

void T::sort()
{
*this = T();
sort();
}

Why you brought it up? It is endless recursion that crashes when stack
is full.

> sort(anObj){
> * * anObj = new anObjTye; /*replacing the object( heap or stack whatever,
> the code is psuedo)*/
> * * pointertothisfunction(anObj) /*Ok to call this function, recursion is ok
> with a new object.*/
>
> }

Again does not compile. Compiles something like:

void sort( T& anObj )
{
anobj = T();
sort( anObj );
}

Still endless recursion.

> The member function version does not have the same possible sequences of
> execution as the normal version.
> The member function version has an object identity, it belongs to the object
> on which it is called.

I am maybe idiot or my English lacks but i can't parse what you say
here. The functions are equal for me only syntax of calling is
different.