«

"Gerhard Fiedler" <> wrote in message
news:401wsvmp6ved$....
> Paul wrote:
>
>> 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.

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.

On Feb 25, 11:54*am, "Paul" <pchris...@yahoo.co.uk> wrote:
> 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

"Martin" <> wrote in message
news:e4b4eeb0-3616-48bf-9a4f-...
On Feb 25, 11:54 am, "Paul" <pchris...@yahoo.co.uk> wrote:
> 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 ****ing 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

On Feb 26, 12:03*am, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Martin" <martin.sh...@yahoo.com> wrote in message
>
> news:e4b4eeb0-3616-48bf-9a4f-...
> On Feb 25, 11:54 am, "Paul" <pchris...@yahoo.co.uk> wrote:
>
>
>
> > 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 ****ing 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 belongsto
> > and the whole thing is a very confused mess, IF it was even possible todo
> > with standard C++.
>
> > So these are some of the reason why a member function is different forman
> > 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

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

"Martin" <> wrote in message
news:0c743b77-1c11-4286-813d-...
On Feb 26, 12:03 am, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Martin" <martin.sh...@yahoo.com> wrote in message
>
> news:e4b4eeb0-3616-48bf-9a4f-...
> On Feb 25, 11:54 am, "Paul" <pchris...@yahoo.co.uk> wrote:
>
>
>
> > 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 ****ing 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

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

Paul wrote:

> 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

"Gerhard Fiedler" <> wrote in message
news:47hao38wygfk$....
> Paul wrote:
>
>> 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.
>
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.

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

Assignment operator modifies an object it doesn't overwrite it with a
completely new object.
>
>> 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.
>
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.

Paul wrote:

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

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

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

"Gerhard Fiedler" <> wrote in message
news...
> Paul wrote:
>
>>> 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.
>
> 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.

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

"Gerhard Fiedler" <> wrote in message
news:47hao38wygfk$....
> Paul wrote:
>
>> 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);
}