Is it legal code?

[Paul]

I also generally think of a function as a sequence of opcodes in memory(
function definition), however that is not the *only* way I can think of a
function.
I am also able to think of a function as a sub-process, a runtime entity.
Most of the people here who argue with me seem to lack this ability.

--That is perfectly valid to think about function invocations as part of
--process. However on one hand an object is not that process or part of
--it (so how can such invocation be part of object?) and on other hand
--same function may be invoked hundreds of times during program run from
--different parts of process (so function feels not a single thing but
--whole cloud of invocations by that view).

But an object is part of the calling process when we invoke a member
functions.

One way to demonstrate this is to consider the difference between the
following two functions:
obj.membfunction();
ordinaryfunction(p_obj);

An ordinary function can be recursive with each recursion invoked with a
different object parameter:
void ordinaryfunction(T* p_obj){
call overwrite(p_obj ); /*asm subroutine to overwrite the object with a
new one in exactly the same region of memory. Dunno if it can be done in C++
*/
ordinaryfunction(p_obj); /*a new object for each recursion*/
}

The same cannot be done with a member function because the function belongs
to the object:
void memberfunction(){
call overwrite();
this->memberfunction() /*'this' is not modified but it points to a
different object */
/*ptr_to_thisfunction() Using a pointer to the opcode makes no
difference*/
}

The rules of C++ disallow member functions(instances of functions) to be
invoked with a different object thus .. the instance of the function belongs
to the object on which it was invoked.
Assuming you agree with above it follows that:
The sequence of execution for a member function is not always the same as
that of an ordinary function, for no other reason that the fact that the
function(or function invokation, if you need this directive) is a member of
an object.


My explanation is based on thiscall convention as explained here :
"4.thiscall: This convention is mainly used in C++ member functions and
parameters are pushed from right to left. this pointer is stored in ECX
register instead of pushing into a stack. Callee will clean up the stack.
this pointer is passed in ECX register."

ref: http://www.yashks.com/2011/01/stack-internals/


Ty for reading
Paul.

 

[Paul]

The sequence of execution for a member function is not always the same as
that of an ordinary function, for no other reason that the fact that the
function(or function invokation, if you need this directive) is a member
of an object.

Correction:
The sequence of execution that arises from a member function invocation
<snip>

 

[Öö Tiib]

--That is perfectly valid to think about function invocations as part of
--process. However on one hand an object is not that process or part of
--it (so how can such invocation be part of object?) and on other hand
--same function may be invoked hundreds of times during program run from
--different parts of process (so function feels not a single thing but
--whole cloud of invocations by that view).

But an object is part of the calling process when we invoke a member
functions.

Indeed. Object participates in the invocation. That member function is
called for it. I do not see difference if it was passed as parameter
of function ... it still would participate i feel.

One way to demonstrate this is to consider the difference between the
following two functions:
obj.membfunction();
ordinaryfunction(p_obj);

An ordinary function can be recursive with each recursion invoked with a
different object parameter:
void ordinaryfunction(T* p_obj){
    call overwrite(p_obj ); /*asm subroutine to overwrite the object with a
new one in exactly the same region of memory. Dunno if it can be done in C++
*/
    ordinaryfunction(p_obj); /*a new object for each recursion*/

}

In C++ you usually use operator=() with what you can assign new value
to object. Object itself remains still same (same region of storage).
If you are using assembler for doing something then it is perhaps for
platform specific effects that C++ does not allow or provides ways to
do inefficiently. Each such case is better to discuss in newsgroup
dedicated to that particular platform.

The same cannot be done with a member function because the function belongs
to the object:
void memberfunction(){
    call overwrite();
    this->memberfunction() /*'this' is not modified but it points to a
different object */
    /*ptr_to_thisfunction() Using a pointer to the opcode makes no
difference*/

}

I am not sure what you mean. If you overload operator=() for example
(assigning is commonly accepted way of setting new values to whole
objects) then it should be overloaded as member function. You can call
it ( do "*this = something_else();") from some other member functions
if you need, it is not invalid code.

[...]

ref:http://www.yashks.com/2011/01/stack-internals/

The link is discussing implementation details of Win32, Visual C++ on
Intel x86 architecture. Such details are certainly valuable knowledge
when it is your platform of choice. The knowledge however does not
apply to C++ as language in general, you may apply it only on
particular platform.

 

[Paul]

--That is perfectly valid to think about function invocations as part of
--process. However on one hand an object is not that process or part of
--it (so how can such invocation be part of object?) and on other hand
--same function may be invoked hundreds of times during program run from
--different parts of process (so function feels not a single thing but
--whole cloud of invocations by that view).

But an object is part of the calling process when we invoke a member
functions.

--Indeed. Object participates in the invocation. That member function is
--called for it. I do not see difference if it was passed as parameter
--of function ... it still would participate i feel.

I have explained an important* difference, I dont know why you seem to be
incapable of understanding what I am explain.

One way to demonstrate this is to consider the difference between the
following two functions:
obj.membfunction();
ordinaryfunction(p_obj);

An ordinary function can be recursive with each recursion invoked with a
different object parameter:
void ordinaryfunction(T* p_obj){
call overwrite(p_obj ); /*asm subroutine to overwrite the object with a
new one in exactly the same region of memory. Dunno if it can be done in
C++
*/
ordinaryfunction(p_obj); /*a new object for each recursion*/

}

--In C++ you usually use operator=() with what you can assign new value
--to object. Object itself remains still same (same region of storage).
--If you are using assembler for doing something then it is perhaps for
--platform specific effects that C++ does not allow or provides ways to
--do inefficiently. Each such case is better to discuss in newsgroup
--dedicated to that particular platform.

overwrite() is a C++ function call to an asm implemented function which does
as I explained, thats all we need to know for the sake of this discussion.
Overloading brackets does not affect the mechanisms of the function call and
I don't see the need to introduce this.

The same cannot be done with a member function because the function
belongs
to the object:
void memberfunction(){
call overwrite();
this->memberfunction() /*'this' is not modified but it points to a
different object */
/*ptr_to_thisfunction() Using a pointer to the opcode makes no
difference*/

}

--I am not sure what you mean. If you overload operator=() for example
--(assigning is commonly accepted way of setting new values to whole
--objects) then it should be overloaded as member function. You can call
--it ( do "*this = something_else();") from some other member functions
--if you need, it is not invalid code.

Please explain what you don't understand and I will explain it in more
detail to make it 100% understandable.
It has nothing to do with overloading brackets as this does not affect the
calling mechanisms of functions.


[...]

ref:http://www.yashks.com/2011/01/stack-internals/

--The link is discussing implementation details of Win32, Visual C++ on
--Intel x86 architecture. Such details are certainly valuable knowledge
--when it is your platform of choice. The knowledge however does not
--apply to C++ as language in general, you may apply it only on
--particular platform.

Function calling mechanisms are platform specific, we need to live wih this
fact.
I gave thicall is an example of a C++ calling convention but there are
similar conventions on any C++ implementation. It doesn't really matter what
calling convention is used but it helps to realise the events that take
place.

 

[Öö Tiib]

--Indeed. Object participates in the invocation. That member function is
--called for it. I do not see difference if it was passed as parameter
--of function ... it still would participate i feel.

I have explained an important* difference, I dont know why you seem to be
incapable of understanding what I am explain.




--In C++ you usually use operator=() with what you can assign new value
--to object. Object itself remains still same (same region of storage).
--If you are using assembler for doing something then it is perhaps for
--platform specific effects that C++ does not allow or provides ways to
--do inefficiently. Each such case is better to discuss in newsgroup
--dedicated to that particular platform.

overwrite() is a C++ function call to an asm implemented function which does
as I explained, thats all we need to know for the sake of this discussion..
Overloading brackets does not affect the mechanisms of the function call and
I don't see the need to introduce this.

Hmm ... operator=() is not overloading brackets. It overloads
assignment.

--I am not sure what you mean. If you overload operator=() for example
--(assigning is commonly accepted way of setting new values to whole
--objects) then it should be overloaded as member function. You can call
--it ( do "*this = something_else();") from some other member functions
--if you need, it is not invalid code.

Please explain what you don't understand and I will explain it in more
detail to make it 100% understandable.
It has nothing to do with overloading brackets as this does not affect the
calling mechanisms of functions.

What i don't understand ... is what is your point. There are some
things that i can not do from free function. I can not access private
members from free function. I can not accept non-const references to
temporary object as free function's parameter (despite temporary is
mutable). You discuss neither case so i don't get it.

Assignment "A& A:perator=(B const&)" is called with syntax "a = b",
function call "void A:perator()(B&)" is called with syntax "a(b)".
These are both member functions with specific calling syntax and i was
discussing assignment and not function call (that one might name as
brackets).

 

[Paul]

--Indeed. Object participates in the invocation. That member function is
--called for it. I do not see difference if it was passed as parameter
--of function ... it still would participate i feel.

I have explained an important* difference, I dont know why you seem to be
incapable of understanding what I am explain.




--In C++ you usually use operator=() with what you can assign new value
--to object. Object itself remains still same (same region of storage).
--If you are using assembler for doing something then it is perhaps for
--platform specific effects that C++ does not allow or provides ways to
--do inefficiently. Each such case is better to discuss in newsgroup
--dedicated to that particular platform.

overwrite() is a C++ function call to an asm implemented function which
does
as I explained, thats all we need to know for the sake of this discussion.
Overloading brackets does not affect the mechanisms of the function call
and
I don't see the need to introduce this.

Hmm ... operator=() is not overloading brackets. It overloads
assignment.

--I am not sure what you mean. If you overload operator=() for example
--(assigning is commonly accepted way of setting new values to whole
--objects) then it should be overloaded as member function. You can call
--it ( do "*this = something_else();") from some other member functions
--if you need, it is not invalid code.

Please explain what you don't understand and I will explain it in more
detail to make it 100% understandable.
It has nothing to do with overloading brackets as this does not affect the
calling mechanisms of functions.

--What i don't understand ... is what is your point. There are some
--things that i can not do from free function. I can not access private
--members from free function. I can not accept non-const references to
--temporary object as free function's parameter (despite temporary is
--mutable). You discuss neither case so i don't get it.

The point is that in C++ a member function is bound to the object on which
its called.
Some peope are arguing that its no different from a normal function but it
is, you have given another couple of reasons above why it is different.
Altohugh they are valid reasons I accpet they are just superficial
syntaxical reasons that are enforced by a compiler. I am providing further
more fundamental reasons.

--Assignment "A& A:perator=(B const&)" is called with syntax "a = b",
--function call "void A:perator()(B&)" is called with syntax "a(b)".
--These are both member functions with specific calling syntax and i was
--discussing assignment and not function call (that one might name as
--brackets).

All this stuff is just syntax, I think the standard makes it clear that
syntaxically a member function is different from an ordinary function. I was
being reasonable and accepting the argument put to me , ignoring the syntax
imposed by a compiler and addressing the underlying calling mechanics.

 

[Öö Tiib]

--What i don't understand ... is what is your point. There are some
--things that i can not do from free function. I can not access private
--members from free function. I can not accept non-const references to
--temporary object as free function's parameter (despite temporary is
--mutable). You discuss neither case so i don't get it.

The point is that in C++ a member function is bound to the object on which
its called.

Yes but ordinary function's call is also bound to arguments given to
it. In that direction i see no difference.

Some peope are arguing that its no different from a normal function but it
is, you have given another couple of reasons above why it is different.
Altohugh they are valid reasons I accpet they are just superficial
syntaxical reasons that are enforced by a compiler. I am providing further
more fundamental reasons.

Sure, couple of differences there are and there i don't argue. I
choose by it. When a function needs access to private members of class
then i implement it as member function. When function does not need
access to private members of class then i implement it as ordinary
function. I generally avoid friend functions in order to keep that
line clear.

Also i generally write virtual member functions (besides virtual
destructors) private to keep them as implementation detail. Leigh
started to argue a lot against it, last i said it. I don't impose it
as rule upon others. Maybe such idiom does not fit with their problems
or style ... for mine it is perfect. I feel it makes the interfaces
written by me cleaner, simpler and more robust.

--Assignment "A& A:perator=(B const&)" is called with syntax "a = b",
--function call "void A:perator()(B&)" is called with syntax "a(b)".
--These are both member functions with specific calling syntax and i was
--discussing assignment and not function call (that one might name as
--brackets).

All this stuff is just syntax, I think the standard makes it clear that
syntaxically a member function is different from an ordinary function. I was
being reasonable and accepting the argument put to me , ignoring the syntax
imposed by a compiler and addressing the underlying calling mechanics.

Yes, OK. So lets put calling syntax entirely aside. It is reasonable
since C++ gives us lot of freedom to manipulate that syntax by
overloading various operators as we please. I still don't see the more
fundamental reasons that you said you will provide.

 

[Paul]

--What i don't understand ... is what is your point. There are some
--things that i can not do from free function. I can not access private
--members from free function. I can not accept non-const references to
--temporary object as free function's parameter (despite temporary is
--mutable). You discuss neither case so i don't get it.

The point is that in C++ a member function is bound to the object on which
its called.

--Yes but ordinary function's call is also bound to arguments given to
--it. In that direction i see no difference.

No it isn't:
The data the pointer-parameter-points-to has nothing to do with the
mechanics of calling a normal function.

Some peope are arguing that its no different from a normal function but it
is, you have given another couple of reasons above why it is different.
Altohugh they are valid reasons I accpet they are just superficial
syntaxical reasons that are enforced by a compiler. I am providing further
more fundamental reasons.

--Sure, couple of differences there are and there i don't argue. I
--choose by it. When a function needs access to private members of class
--then i implement it as member function. When function does not need
--access to private members of class then i implement it as ordinary
--function. I generally avoid friend functions in order to keep that
--line clear.

I also avoid friend functions, although I think they can be usefull in
advanced class designs.

--.Also i generally write virtual member functions (besides virtual
--destructors) private to keep them as implementation detail. Leigh
--started to argue a lot against it, last i said it. I don't impose it
--as rule upon others. Maybe such idiom does not fit with their problems
--or style ... for mine it is perfect. I feel it makes the interfaces
--written by me cleaner, simpler and more robust.

Sure all this is part of the C++ language and overwhelming evidence that a
C++ member function is different from a normal C++ function.

--Assignment "A& A:perator=(B const&)" is called with syntax "a = b",
--function call "void A:perator()(B&)" is called with syntax "a(b)".
--These are both member functions with specific calling syntax and i was
--discussing assignment and not function call (that one might name as
--brackets).

All this stuff is just syntax, I think the standard makes it clear that
syntaxically a member function is different from an ordinary function. I
was
being reasonable and accepting the argument put to me , ignoring the
syntax
imposed by a compiler and addressing the underlying calling mechanics.

--Yes, OK. So lets put calling syntax entirely aside. It is reasonable
--since C++ gives us lot of freedom to manipulate that syntax by
--overloading various operators as we please. I still don't see the more
--fundamental reasons that you said you will provide.

Its not just the calling syntax, access specifiers and constantness etc are
also C++ syntax.
For example the rules regarding the 'this' pointer are implemented with C++
syntaxical rules. We know that 'this' pointer is simply a register value in
the underlying mechanics of a function call.

So lets put *all* c++ syntaxical rules aside and look only at the underlying
mechanics, now going back to a similar example I showed before:

void ordinaryfunction(T* p_obj){
call overwrite(p_obj ); /*asm subroutine to overwrite the memory p_obj
points to*/
ordinaryfunction(p_obj); /*a new object for each recursion*/
}
The above function is a perfectly reasonable function.

void memberfunction(){
call overwrite(); /*as descirbed above*/
this->memberfunction() /* Hang on this is not possible*/
}
This member function call is not reasonable, what does 'this' point to after
you have overwritten the memory it points to?
It is not possible because the fundamental structure of the C++ language is
designed to support OOP, the member function belongs to the object.
You may prefer to say the invocation of the member function belongs to the
object. But neither term can be either correct or incorrect, its simply a
matter of context.
Someone may have the view that the member function doesn't exist, as a
member function, until its invoked. It's simply an ordinary function unless
it is invoked as a member function.
There are a few possible ways of looking at this correctly.

Someone may have the view that it's never a member function of the object,
it's only ever a member of a class.( this I disagree with and I think is
incorrect ). A *class* member function is a static member function and this
obviously does not apply to objects.

HTH
Paul.

 

[Paul]

--Yes but ordinary function's call is also bound to arguments given to
--it. In that direction i see no difference.

No it isn't:
The data the pointer-parameter-points-to has nothing to do with the
mechanics of calling a normal function.



--Sure, couple of differences there are and there i don't argue. I
--choose by it. When a function needs access to private members of class
--then i implement it as member function. When function does not need
--access to private members of class then i implement it as ordinary
--function. I generally avoid friend functions in order to keep that
--line clear.

I also avoid friend functions, although I think they can be usefull in
advanced class designs.

--.Also i generally write virtual member functions (besides virtual
--destructors) private to keep them as implementation detail. Leigh
--started to argue a lot against it, last i said it. I don't impose it
--as rule upon others. Maybe such idiom does not fit with their problems
--or style ... for mine it is perfect. I feel it makes the interfaces
--written by me cleaner, simpler and more robust.

Sure all this is part of the C++ language and overwhelming evidence that a
C++ member function is different from a normal C++ function.



--Yes, OK. So lets put calling syntax entirely aside. It is reasonable
--since C++ gives us lot of freedom to manipulate that syntax by
--overloading various operators as we please. I still don't see the more
--fundamental reasons that you said you will provide.

Its not just the calling syntax, access specifiers and constantness etc
are also C++ syntax.
For example the rules regarding the 'this' pointer are implemented with
C++ syntaxical rules. We know that 'this' pointer is simply a register
value in the underlying mechanics of a function call.

So lets put *all* c++ syntaxical rules aside and look only at the
underlying mechanics, now going back to a similar example I showed before:

void ordinaryfunction(T* p_obj){
call overwrite(p_obj ); /*asm subroutine to overwrite the memory p_obj
points to*/
ordinaryfunction(p_obj); /*a new object for each recursion*/
}
The above function is a perfectly reasonable function.

void memberfunction(){
call overwrite(); /*as descirbed above*/
this->memberfunction() /* Hang on this is not possible*/
}
This member function call is not reasonable, what does 'this' point to
after you have overwritten the memory it points to?
It is not possible because the fundamental structure of the C++ language
is designed to support OOP, the member function belongs to the object.
You may prefer to say the invocation of the member function belongs to the
object. But neither term can be either correct or incorrect, its simply a
matter of context.

Correct the above sentence , what I mean is:
You can't say one is correct and the other is incorrect, both are valid
points of view.

 

[Gerhard Fiedler]

void ordinaryfunction(T* p_obj){
call overwrite(p_obj ); /*asm subroutine to overwrite the memory p_obj
points to*/
ordinaryfunction(p_obj); /*a new object for each recursion*/
}
The above function is a perfectly reasonable function.

void memberfunction(){
call overwrite(); /*as descirbed above*/
this->memberfunction() /* Hang on this is not possible*/
}

This member function call is not reasonable, what does 'this' point to after
you have overwritten the memory it points to?

AIUI, both is undefined according to the C++ standard, and the outcome
may be anything -- depending on a specific implementation.

But considering a straightforward implementation... if you overwrite
p_obj so that the outcome is a valid object of type T, in the second
case "this" would point to the overwritten object, and memberfunction()
would be called on the overwritten object, just like in the first case.

Gerhard

 

[Paul]

AIUI, both is undefined according to the C++ standard, and the outcome
may be anything -- depending on a specific implementation.

In what way would the ordinary function cause UB?

But considering a straightforward implementation... if you overwrite
p_obj so that the outcome is a valid object of type T, in the second
case "this" would point to the overwritten object, and memberfunction()
would be called on the overwritten object, just like in the first case.

There is not a single valid object type, there is valid object types(plural)
that we must consider reasonable for the argument.

With the ordinary function the valid object types are more flexible with
arays and built-in types (for example an pointer to integer type could just
as easily be a pointer to array of integers)
This is yet further reasons why ordinary function differ but lets consider
only objects of class-types.

A valid type for this argument is an object of class-type T or derived from
that class type.
So lets say the objects are Dog and Cat, both derived from Animal, all
objects have an non virtual eat() method.

void normalfunction(p_obj){
overwrite(p_obj) /*dog with a cat , cat with animal , any variation*/
normalfunction(p_obj); /*The object, the pointer parameter points to,
has nothing to do with the function call*/
}

void memberfucntion(){
overwrite(this) /*overwrite of different types is not ok*/
this->member function(); /*this function cannot be re-invoked on a
different object*/
}

OK so now you could argue that could can overwrite the memberfunction with
an object of the same Type T but using a different example I can show that
this is not correct:

In C++ an object is a region of storage, so if object is at address DS:0002
and you overwrite this with another object of the same type you aren't
actually creating a new object. You just change the values of the original
object. So lets say we have 2 objects contiguous in memory at DS:0002 and
DS:000C( 10 byte objects).

void ordinaryfunction(p_obj){
change_object_pointed_to(p_obj); /*adjust the pointer to point to
theother object.*/
ordinaryfunction(p_obj); /*no problem here*/
}

void memberfunction(){
adjust_this_pointer(); /*point to other object. Not standard C++ I
think, but defintely possible */
this->memberfunction(); /*WTF is going on here?*/
}

As you can see this member function doesn't know what object it belongs to
and the whole thing is a very confused mess, IF it was even possible to do
with standard C++.

So these are some of the reason why a member function is different form an
ordinary function, without even touching on virtuals.

 

[Martin]

OK so now you could argue that could can overwrite the memberfunction with
an object of the same Type T but using a different example I can show that
this is not correct:

In C++ an object is a region of storage, so if object is at address DS:0002
and you overwrite this with another object of the same type you aren't
actually creating a new object. You just change the values of the original
object. So lets say we have 2 objects contiguous in memory at DS:0002 and
DS:000C( 10 byte objects).

void ordinaryfunction(p_obj){
    change_object_pointed_to(p_obj); /*adjust the pointer to point to
theother object.*/
    ordinaryfunction(p_obj); /*no problem here*/

}

You don't specify how the p_obj parameter is passed, so I will assume
that it is passed by value. (Which would more closely match how the
this pointer is passed to a member function). That means that the
change_object_pointed_to function exhibits undefined behavior. While
an implementation is allowed to do anything it wants, most of the
implementations I've worked with would either pass the new value of
p_obj to the ordinaryfunction function, or pass the old value of p_obj
to the ordinaryfunction function. Which would depend greatly on how
much optimization you told it to do.

void memberfunction(){
    adjust_this_pointer(); /*point to other object. Not standard C++ I
think, but defintely possible */
    this->memberfunction(); /*WTF is going on here?*/

}

Here the adjust_this_pointer function exhibits undefined behavior.
While an implementation is allowed to do anything it wants, most of
the implementations I've worked with would either pass the new value
of this to the memberfunction function, or pass the old value of this
to the memberfunction function. Which would depend greatly on how
much optimization you told it to do.

As you can see this member function doesn't know what object it belongs to
and the whole thing is a very confused mess, IF it was even possible to do
with standard C++.

So these are some of the reason why a member function is different form an
ordinary function, without even touching on virtuals.

I'm afraid I don't see a difference here.

Martin

 

[Paul]

OK so now you could argue that could can overwrite the memberfunction with
an object of the same Type T but using a different example I can show that
this is not correct:

In C++ an object is a region of storage, so if object is at address
DS:0002
and you overwrite this with another object of the same type you aren't
actually creating a new object. You just change the values of the original
object. So lets say we have 2 objects contiguous in memory at DS:0002 and
DS:000C( 10 byte objects).

void ordinaryfunction(p_obj){
change_object_pointed_to(p_obj); /*adjust the pointer to point to
theother object.*/
ordinaryfunction(p_obj); /*no problem here*/

}

You don't specify how the p_obj parameter is passed, so I will assume
that it is passed by value. (Which would more closely match how the
this pointer is passed to a member function). That means that the
change_object_pointed_to function exhibits undefined behavior. While
an implementation is allowed to do anything it wants, most of the
implementations I've worked with would either pass the new value of
p_obj to the ordinaryfunction function, or pass the old value of p_obj
to the ordinaryfunction function. Which would depend greatly on how
much optimization you told it to do.
................................................................................................

Man it's pointless to try and ocnverse with anyone in this newsgroup they
are obviously ALL as thick as hell.

WOW how can a whole gorup of individuals ALL be so fucking thick

GL yOU WILL NEED IT.

void memberfunction(){
adjust_this_pointer(); /*point to other object. Not standard C++ I
think, but defintely possible */
this->memberfunction(); /*WTF is going on here?*/

}

Here the adjust_this_pointer function exhibits undefined behavior.
While an implementation is allowed to do anything it wants, most of
the implementations I've worked with would either pass the new value
of this to the memberfunction function, or pass the old value of this
to the memberfunction function. Which would depend greatly on how
much optimization you told it to do.

As you can see this member function doesn't know what object it belongs to
and the whole thing is a very confused mess, IF it was even possible to do
with standard C++.

So these are some of the reason why a member function is different form an
ordinary function, without even touching on virtuals.

I'm afraid I don't see a difference here.
///////////////////////////////////////////////////////////////////////////////////////////////////////////

If you cannot tell the difference between a member ufnction and an ordinary
you are obviously very very very very very very THICK
goodluck

 

[Martin]

You don't specify how the p_obj parameter is passed, so I will assume
that it is passed by value.  (Which would more closely match how the
this pointer is passed to a member function).  That means that the
change_object_pointed_to function exhibits undefined behavior.  While
an implementation is allowed to do anything it wants, most of the
implementations I've worked with would either pass the new value of
p_obj to the ordinaryfunction function, or pass the old value of p_obj
to the ordinaryfunction function.  Which would depend greatly on how
much optimization you told it to do.
................................................................................................

Man it's pointless to try and ocnverse with anyone in this newsgroup they
are obviously ALL as thick as hell.

WOW how can a whole gorup of individuals ALL be so fucking thick

GL yOU WILL NEED IT.





Here the adjust_this_pointer function exhibits undefined behavior.
While an implementation is allowed to do anything it wants, most of
the implementations I've worked with would either pass the new value
of this to the memberfunction function, or pass the old value of this
to the memberfunction function.  Which would depend greatly on how
much optimization you told it to do.



I'm afraid I don't see a difference here.
///////////////////////////////////////////////////////////////////////////////////////////////////////////

If you cannot tell the difference between a member ufnction and an ordinary
you are obviously very very very very very very THICK
goodluck

That's the best counter your have? I seriously doubt that my
thickness has any relationship to the technical points under
discussion.

But, what gave you the idea that I couldn't tell the difference? I
certainly didn't say that. You can tell the difference between them
because the member functions belong to a class, while the free
functions don't. There are also some differences between the syntax
used to call them and a special mode for passing the (implicit) first
argument to the member function. (The closest one can get in a free
function is T * const). You are claiming that there is some
difference in the behavior of the member function and the free
function that is exemplified by the code you posted. I pointed out
that there is neither a difference in their defined behavior (both are
undefined), nor in the actual behaviors that a compiler is likely to
produce.

Martin

 

[Paul]

You don't specify how the p_obj parameter is passed, so I will assume
that it is passed by value. (Which would more closely match how the
this pointer is passed to a member function). That means that the
change_object_pointed_to function exhibits undefined behavior. While
an implementation is allowed to do anything it wants, most of the
implementations I've worked with would either pass the new value of
p_obj to the ordinaryfunction function, or pass the old value of p_obj
to the ordinaryfunction function. Which would depend greatly on how
much optimization you told it to do.
...............................................................................................

Man it's pointless to try and ocnverse with anyone in this newsgroup they
are obviously ALL as thick as hell.

WOW how can a whole gorup of individuals ALL be so fucking thick

GL yOU WILL NEED IT.





Here the adjust_this_pointer function exhibits undefined behavior.
While an implementation is allowed to do anything it wants, most of
the implementations I've worked with would either pass the new value
of this to the memberfunction function, or pass the old value of this
to the memberfunction function. Which would depend greatly on how
much optimization you told it to do.



I'm afraid I don't see a difference here.
///////////////////////////////////////////////////////////////////////////////////////////////////////////

If you cannot tell the difference between a member ufnction and an
ordinary
you are obviously very very very very very very THICK
goodluck

--That's the best counter your have? I seriously doubt that my
--thickness has any relationship to the technical points under
--discussion.
Sorry I did not intend toward you personally , I should've said :
If *someone* cannot tell the difference they must be very very thick, which
I am sure you'll agree with.


--But, what gave you the idea that I couldn't tell the difference? I
--certainly didn't say that. You can tell the difference between them
--because the member functions belong to a class, while the free
--functions don't.
No a *static* member function belongs to a class. A nonstatic member
function is a very different entity, it belongs to both a class and object,
dependant on context.

--There are also some differences between the syntax
--used to call them and a special mode for passing the (implicit) first
--argument to the member function. (The closest one can get in a free
--function is T * const).
You say 'the closest you can get to it is....'. That suggests you cannot do
it in C++.
The rules of the C++ language(the syntax) force us to use a member function
as intended in the design of the language. But even putting this aside and
breaking these rules there are also fundametal programming differences, as I
demonstrated.

--You are claiming that there is some
--difference in the behavior of the member function and the free
--function that is exemplified by the code you posted. I pointed out
--that there is neither a difference in their defined behavior (both are
--undefined), nor in the actual behaviors that a compiler is likely to
--produce.

What is undefined about the normal function I posted ref:

void ordinaryfunction(p_obj){
overwrite(p_obj); /*overwrite the object p_obj points to*/
ordinaryfunction();
}

Please state what is wrong with this code as you may have a valid point
here, but IMHO this code is perfectly valid.
There are statements in C++ standard about sequence points in program
execution and this defines what is a valid C++ program, an implementation of
the overwrite() function is very do-able without breaking these rules.

What is the difference if I do :
void new_object(p_obj){
delete p_obj;
p_obj = new T;
}

The only difference is that the new object is in a different memory
location, from the old one. I used an example which made a new object in the
same memory location, with a theoretical asm routine. The reason I did it
this way was to emphasise the fact that the 'this' pointer was not even
being adjusted.[Note: Because I had the feleling someone would try to be
unreasonable and expect my code to comply with standards whereas the other
argument didn't comply, so I did it a way that my code *did comply* anyway..
End note]

Are you saying its illegal to overwrite an object? Please make your point
clear.


Before straying too far form the original subject please note that if my
ordinary function is valid C++ code then it proves that the sequence of
execution for a normal function is not always the same as for a nonstatic
member function.

 

[Gerhard Fiedler]

What is undefined about the normal function I posted ref:

void ordinaryfunction(p_obj){
overwrite(p_obj); /*overwrite the object p_obj points to*/
ordinaryfunction();
}

In an earlier incarnation of this you specifically used assembly to
overwrite p_obj in overwrite(). This is of course undefined behavior.

If you want to get anywhere with this argument, you'd have to start
using standard-conformant, compilable C++. The above is neither.

How exactly will you "overwrite" the class instance at p_obj?

Try to come up with a standard C++ example that involves a class and a
function operating on an instance of that class. I'm pretty sure that it
is possible to re-write that example using a member function. And vice
versa.

I used an example which made a new object in the same memory location,
with a theoretical asm routine. The reason I did it this way was to
emphasise the fact that the 'this' pointer was not even being
adjusted.[Note: Because I had the feleling someone would try to be
unreasonable and expect my code to comply with standards whereas the
other argument didn't comply, so I did it a way that my code *did
comply* anyway.. End note]

As long as we're talking about C++, we should stick to the C++ standard
-- or else what language are you /really/ talking about?

Are you saying its illegal to overwrite an object? Please make your point
clear.

It's not; we have assignment operators for that. It is you who is trying
to make a point that it's not possible to overwrite a class instance.

Before straying too far form the original subject please note that if
my ordinary function is valid C++ code ...

But so far it isn't. You have to do more work on this.

Gerhard

 

[Paul]

In an earlier incarnation of this you specifically used assembly to
overwrite p_obj in overwrite(). This is of course undefined behavior.

What is undefined about it?
The function is defined as:
a function that overwrites the memory the 'this' or 'p_obj' points to.

If you want to get anywhere with this argument, you'd have to start
using standard-conformant, compilable C++. The above is neither.

Can you show me an example where an ordinary function is the same as a
member function, using standard code?
If we were using only standard code then their argument wouldn't get off the
starting blocks.

How exactly will you "overwrite" the class instance at p_obj?

That doesn't matter it, has no impact on the calling mechanics of the
recursive function. All we need to know is that the object is erased from
memory and no longer exists.
It has been overwritten, wiped out.

Try to come up with a standard C++ example that involves a class and a
function operating on an instance of that class. I'm pretty sure that it
is possible to re-write that example using a member function. And vice
versa.

Its uneccessary as the way in which the object is overwritten has no effect
on the calling mechanism.

Why don't you do it , give me one example of how to overwrite memory for
each memory model possible on a x86, thats about 8 different examples to
cover all x86 implementations. If you have a spare day or two please try to
create such a function that will keep everyone happy.

I used an example which made a new object in the same memory location,
ko with a theoretical asm routine. The reason I did it this way was to
emphasise the fact that the 'this' pointer was not even being
adjusted.[Note: Because I had the feleling someone would try to be
unreasonable and expect my code to comply with standards whereas the
other argument didn't comply, so I did it a way that my code *did
comply* anyway.. End note]

As long as we're talking about C++, we should stick to the C++ standard
-- or else what language are you /really/ talking about?

I think the C++ standard is not applicable for discussing function calling
mechanisms.
As I said he other argument wouldn't even get of the starting blocks if we
were sticking to the standards.

It's not; we have assignment operators for that. It is you who is trying
to make a point that it's not possible to overwrite a class instance.

Assignment operator modifies an object it doesn't overwrite it with a
completely new object.

But so far it isn't. You have to do more work on this.

It's perfectly valid in C++ to call an asm routine.



You seem to want to create an abstract discussion about the way in which an
objects memory is overwritten. This makes no difference to the point I was
making about the ivocation of the function.

 

[Gerhard Fiedler]

I think the C++ standard is not applicable for discussing function
calling mechanisms. As I said he other argument wouldn't even get of
the starting blocks if we were sticking to the standards.

Then what are you actually arguing about -- if it isn't C++? Do you even
still know this?

It's perfectly valid in C++ to call an asm routine.

I'm not sure, but I'm pretty sure it is not part of the C++ standard and
if possible is a compiler-specific extension to the language.

Gerhard

 

[Paul]

Then what are you actually arguing about -- if it isn't C++? Do you even
still know this?

The C++ standard cannot cover every implementations calling mechanics, its
still a C++ function call.

I'm not sure, but I'm pretty sure it is not part of the C++ standard and
if possible is a compiler-specific extension to the language.

I'm talking about a function in pre-assembled object file.
The obj file code has nothing to do with the C++ standard , only the C++
function call itself is defined in C++ standard.

 

[Paul]

What is undefined about the normal function I posted ref:

void ordinaryfunction(p_obj){
overwrite(p_obj); /*overwrite the object p_obj points to*/
ordinaryfunction();
}

In an earlier incarnation of this you specifically used assembly to
overwrite p_obj in overwrite(). This is of course undefined behavior.

If you want to get anywhere with this argument, you'd have to start
using standard-conformant, compilable C++. The above is neither.

How exactly will you "overwrite" the class instance at p_obj?

Try to come up with a standard C++ example that involves a class and a
function operating on an instance of that class. I'm pretty sure that it
is possible to re-write that example using a member function. And vice
versa.

I used an example which made a new object in the same memory location,
with a theoretical asm routine. The reason I did it this way was to
emphasise the fact that the 'this' pointer was not even being
adjusted.[Note: Because I had the feleling someone would try to be
unreasonable and expect my code to comply with standards whereas the
other argument didn't comply, so I did it a way that my code *did
comply* anyway.. End note]

As long as we're talking about C++, we should stick to the C++ standard
-- or else what language are you /really/ talking about?

Are you saying its illegal to overwrite an object? Please make your point
clear.

It's not; we have assignment operators for that. It is you who is trying
to make a point that it's not possible to overwrite a class instance.

Before straying too far form the original subject please note that if
my ordinary function is valid C++ code ...

But so far it isn't. You have to do more work on this.

I think this proves the same point using standard C++ code:

#include <iostream>
class Animal{public:
virtual void eat(){std::cout<< "Animal Eating"<< std::endl;}
virtual int getID()=0;
static int count;
};
class Dog: public Animal{
public:
void eat(){std::cout<< "Dog Eating"<< std::endl;}
int getID(){return 1;}
};
class Cat: public Animal{
public:
void eat(){std::cout<< "Cat Eating"<< std::endl;}
int getID(){return 0;}
};
int Animal::count =10;

Dog* overwriteCat(Animal* ptr){
delete ptr;
Dog* p = reinterpret_cast<Dog*>(ptr);
p = new Dog;
return p;
}

Cat* overwriteDog(Animal* ptr){
delete ptr;
Cat* p = reinterpret_cast<Cat*>(ptr);
p = new Cat;
return p;
}


void ordinary_function(Animal* obj){
Animal::count--;
std::cout<<"Address of obj: " <<obj << " ";
obj->eat();
if(obj->getID()){overwriteDog(obj);}
else {overwriteCat(obj);}
if(Animal::count){
ordinary_function(obj);
}
}

int main()
{
Cat* p_cat = new Cat;
Animal* p_anim = p_cat;

ordinary_function(p_cat);
}