Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > function calls

Reply
Thread Tools

function calls

 
 
Paul
Guest
Posts: n/a
 
      02-24-2011

"Öö Tiib" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On Feb 23, 10:52 am, "Paul" <(E-Mail Removed)> wrote:
> " Tiib" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
> <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 belongs to*/
> (*this).sort(); /*re-invoke this function is not possible, what does
> 'this' point to?*/
> }


--Does not compile. What compiles is:

It's not suppose to compile it was psuedo code, I repeat what I said in the
other thread:

An object is part of the calling process when we invoke a member
function.

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.




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

Please state what you don't understand about the above and I will clarify.


 
Reply With Quote
 
 
 
 
Öö Tiib
Guest
Posts: n/a
 
      02-24-2011
On Feb 24, 8:19*pm, "Paul" <(E-Mail Removed)> wrote:
> " Tiib" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
> On Feb 23, 10:52 am, "Paul" <(E-Mail Removed)> wrote:
>
>
>
>
>
> > " Tiib" <(E-Mail Removed)> wrote in message

>
> >news:(E-Mail Removed)....
> > <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 hasno
> > > > 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 belongs to*/
> > (*this).sort(); /*re-invoke this function is not possible, what does
> > 'this' point to?*/
> > }

>
> --Does not compile. What compiles is:
>
> It's not suppose to compile it was psuedo code, I repeat what I said in the
> other thread:


But lets agree that we from now on use for sake of simplicity real C++
code that compiles and no pseudo code.

struct T
{
void sort();
// other members
};

void T::sort()
{
// lot of code that involves
// re-assignment of value of object
*this = T();
// and recursive calls
sort();
}

void sort( T& that )
{
// lot of code that involves
// re-assignment of value of object
that = T();
// and recursive calls
sort( that );
}



> Please state what you don't understand about the above and I will clarify..


What is so different about the two functions above (and please avoid
pseudo code that does not compile).
 
Reply With Quote
 
 
 
 
Paul
Guest
Posts: n/a
 
      02-24-2011

"Öö Tiib" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On Feb 24, 8:19 pm, "Paul" <(E-Mail Removed)> wrote:
> " Tiib" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
> On Feb 23, 10:52 am, "Paul" <(E-Mail Removed)> wrote:
>
>
>
>
>
> > " Tiib" <(E-Mail Removed)> wrote in message

>
> >news:(E-Mail Removed)...
> > <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 belongs to*/
> > (*this).sort(); /*re-invoke this function is not possible, what does
> > 'this' point to?*/
> > }

>
> --Does not compile. What compiles is:
>
> It's not suppose to compile it was psuedo code, I repeat what I said in
> the
> other thread:


--But lets agree that we from now on use for sake of simplicity real C++
--code that compiles and no pseudo code.

You can't do it with compileable code for a member function;
And for an ordinary function you would need to write an asm routine and
compile it to an obj file.

-- struct T { void sort(); // other members
--};

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

What does the above code do?
invoke a copy constructor?
It doesn't replicate my code, to overwrite the object.

-- sort();
-- }

--void sort( T& that ) {
-- that = T();

Again what does this do?
Does it overwrite the old object? Why use type T , why not
that =Another Type()?

-- sort( that );

Why does your example not pass a pointer type, to replicate 'this' pointer?
'this' is simply a pointer stored in a register.
Your example places the constraint on the ordinary function, that it must
take a reference of the same type as the original object.
-- }

You have just demonstrated another reason why member functions are different
from ordinary functions:
An ordinary function can take any type of parameter. A member functions
'this' pointer cannot be type-casted.


> Please state what you don't understand about the above and I will clarify.


--What is so different about the two functions above (and please avoid
--pseudo code that does not compile).

Your code does not replicate the same process as mine did.

 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      02-25-2011
On Feb 24, 10:08*pm, "Paul" <(E-Mail Removed)> wrote:
> " Tiib" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
> On Feb 24, 8:19 pm, "Paul" <(E-Mail Removed)> wrote:
>
>
>
>
>
> > " Tiib" <(E-Mail Removed)> wrote in message

>
> >news:(E-Mail Removed)....
> > On Feb 23, 10:52 am, "Paul" <(E-Mail Removed)> wrote:

>
> > > " Tiib" <(E-Mail Removed)> wrote in message

>
> > >news:(E-Mail Removed)....
> > > <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 whatwe
> > > > > 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 belongs to*/
> > > (*this).sort(); /*re-invoke this function is not possible, what does
> > > 'this' point to?*/
> > > }

>
> > --Does not compile. What compiles is:

>
> > It's not suppose to compile it was psuedo code, I repeat what I said in
> > the
> > other thread:

>
> --But lets agree that we from now on use for sake of simplicity real C++
> --code that compiles and no pseudo code.
>
> You can't do it with compileable code for a member function;
> And for an ordinary function you would need to write an asm routine and
> compile it to an obj file.
>
> -- struct T { * void sort(); * * // other members
> --};
>
> *--void T::sort() {
> -- * * * **this = T();
>
> What does the above code do?
> invoke a copy constructor?
> It doesn't replicate my code, to overwrite the object.


It does 3 things: dereferences this pointer, default constructs
temporary object of type T and copy-assigns the constructed temporary
objects value to dereferenced this object overwriting its contents
(unless there is user-defined copy-assignment operator that does
something else). I am not sure how this code does not overwrite the
object by your school of philosophy. :-/

> -- * * * * sort();
> -- }
>
> *--void sort( T& that ) {
> -- that = T();
>
> Again what does this do?
> Does it overwrite the old object? Why use type T , why not
> that =Another Type()?


It does exactly same thing like first code, only that since "that" is
passed by reference it is already dereferenced.

>
> *-- * * sort( that );
>
> Why does your example not pass a pointer type, to replicate 'this' pointer?
> 'this' is simply a pointer stored in a register.


Because "this" can not be NULL nor modified and so reference is
behaving more similarly.

> Your example places the constraint on the ordinary function, that it must
> take a reference of the same type as the original object.


Please elaborate. I can not parse what that constraint is. I pass most
of the non-fundamental parameters by reference in my code. Passing by
value involves copying and passing with pointer makes it optional, so
i have to check that pointer for NULLness inside function. In C++ when
i have function with optional parameter i prefer using an overload of
function that lacks the parameter instead of making it pointer. In C
language there are no references nor overloads so there i use
pointers.

> -- }
>
> You have just demonstrated another reason why member functions are different
> from ordinary functions:
> An ordinary function can take any type of parameter. A member functions
> 'this' pointer cannot be type-casted.


It was that people argued with you that ordinary function can behave
like a member function. It has to have parameters that fit with that
task? You may cast pointer returned by keyword "this" in member
function to something else, but i don't understand what it has to do
with our discussion.

> > Please state what you don't understand about the above and I will clarify.

>
> --What is so different about the two functions above (and please avoid
> --pseudo code that does not compile).
>
> Your code does not replicate the same process as mine did.


That is perhaps because i did not understand what your pseudo-code was
doing. Please explain or write in C++, then i likely understand it
better.
 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      02-25-2011

"Öö Tiib" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On Feb 24, 10:08 pm, "Paul" <(E-Mail Removed)> wrote:
> " Tiib" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
> On Feb 24, 8:19 pm, "Paul" <(E-Mail Removed)> wrote:
>
>
>
>
>
> > " Tiib" <(E-Mail Removed)> wrote in message

>
> >news:(E-Mail Removed)...
> > On Feb 23, 10:52 am, "Paul" <(E-Mail Removed)> wrote:

>
> > > " Tiib" <(E-Mail Removed)> wrote in message

>
> > >news:(E-Mail Removed)...
> > > <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 belongs to*/
> > > (*this).sort(); /*re-invoke this function is not possible, what does
> > > 'this' point to?*/
> > > }

>
> > --Does not compile. What compiles is:

>
> > It's not suppose to compile it was psuedo code, I repeat what I said in
> > the
> > other thread:

>
> --But lets agree that we from now on use for sake of simplicity real C++
> --code that compiles and no pseudo code.
>
> You can't do it with compileable code for a member function;
> And for an ordinary function you would need to write an asm routine and
> compile it to an obj file.
>
> -- struct T { void sort(); // other members
> --};
>
> --void T::sort() {
> -- *this = T();
>
> What does the above code do?
> invoke a copy constructor?
> It doesn't replicate my code, to overwrite the object.


--It does 3 things: dereferences this pointer, default constructs
--temporary object of type T and copy-assigns the constructed temporary
--objects value to dereferenced this object overwriting its contents
--(unless there is user-defined copy-assignment operator that does
--something else). I am not sure how this code does not overwrite the
--object by your school of philosophy. :-/


You do know the differnece , think about it:
If there were two objects types Cat and Dog, for completeness lets say the
both implement base class Animal.
Cat cat
Dog dog;
dog = Dog(); /*This is equivalent to your code.* /
overwrite(p_dog, p_cat); /*My code trully overwrites the object, it doesn't
just change a few values.*/

The term overwrite could mean for example...overwrite with a completely new
data structure.


> -- sort();
> -- }
>
> --void sort( T& that ) {
> -- that = T();
>
> Again what does this do?
> Does it overwrite the old object? Why use type T , why not
> that =Another Type()?


--It does exactly same thing like first code, only that since "that" is
--passed by reference it is already dereferenced.

Then see my comments on the first code.
Assigning values to an object is not the same as overwriting its memory IMO.

>
> -- sort( that );
>
> Why does your example not pass a pointer type, to replicate 'this'
> pointer?
> 'this' is simply a pointer stored in a register.


--Because "this" can not be NULL nor modified and so reference is
--behaving more similarly.

'this' can be modified and so can the object it points to.
Remember for example, thiscall uses ECX, ECX is not a read only register so
how can I not modify the 'this' pointer. However this is irrelllevant
because I don't need to modify the 'this' pointer to change the object it
points too.

> Your example places the constraint on the ordinary function, that it must
> take a reference of the same type as the original object.


--Please elaborate.

I have elaborated enough for you to understand now.
I need to go out, so I'm snipping the rest.


Please let me know if you still do not understand and I will re-explain
again.

 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      02-28-2011
On Feb 25, 11:07*am, "Paul" <(E-Mail Removed)> wrote:
>
> Please let me know if you still do not understand and I will re-explain
> again.


Your code does not work. You can not overwrite object 'Dog dog;' in a
way that Cat's destructor is called for it when that dog leaves
scope ... Dog's destructor is called for it on all C++ compilers i
could reach. What destructor will be called is pre-decided and set
already compile time. So it seems that you do not understand yourself
what you are talking about.
 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      02-28-2011

"Öö Tiib" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On Feb 25, 11:07 am, "Paul" <(E-Mail Removed)> wrote:
>
> Please let me know if you still do not understand and I will re-explain
> again.


--Your code does not work. You can not overwrite object 'Dog dog;' in a
--way that Cat's destructor is called for it when that dog leaves
--scope ... Dog's destructor is called for it on all C++ compilers i
--could reach. What destructor will be called is pre-decided and set
--already compile time. So it seems that you do not understand yourself
--what you are talking about.

#include <iostream>
class Animal{};
class Dog: public Animal{};
class Cat: public Animal{};

int main()
{
Cat* p_cat = new Cat;
std::cout<< p_cat << std::endl;
delete p_cat;
Dog* p_dog = reinterpret_cast<Dog*>(p_cat);
p_dog = new Dog;
std::cout << p_dog;
}

 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      02-28-2011
On Feb 28, 9:45*pm, "Paul" <(E-Mail Removed)> wrote:
> " Tiib" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
> On Feb 25, 11:07 am, "Paul" <(E-Mail Removed)> wrote:
>
>
>
> > Please let me know if you still do not understand and I will re-explain
> > again.

>
> --Your code does not work. You can not overwrite object 'Dog dog;' in a
> --way that Cat's destructor is called for it when that dog leaves
> --scope ... Dog's destructor is called for it on all C++ compilers i
> --could reach. What destructor will be called is pre-decided and set
> --already compile time. So it seems that you do not understand yourself
> --what you are talking about.
>
> #include <iostream>
> class Animal{};
> class Dog: public Animal{};
> class Cat: public Animal{};
>
> int main()
> {
> *Cat* p_cat = new Cat;
> *std::cout<< p_cat << std::endl;
> *delete p_cat;
> *Dog* p_dog = reinterpret_cast<Dog*>(p_cat);
> *p_dog = new Dog;
> *std::cout << p_dog;
>
>
>
> }


What does this code overwrite?
Also ... most compilers optimize the two lines:

*Dog* p_dog = reinterpret_cast<Dog*>(p_cat);
*p_dog = new Dog;

Into something like:

*Dog* p_dog = new Dog;

 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      02-28-2011

"Öö Tiib" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On Feb 28, 9:45 pm, "Paul" <(E-Mail Removed)> wrote:
> " Tiib" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
> On Feb 25, 11:07 am, "Paul" <(E-Mail Removed)> wrote:
>
>
>
> > Please let me know if you still do not understand and I will re-explain
> > again.

>
> --Your code does not work. You can not overwrite object 'Dog dog;' in a
> --way that Cat's destructor is called for it when that dog leaves
> --scope ... Dog's destructor is called for it on all C++ compilers i
> --could reach. What destructor will be called is pre-decided and set
> --already compile time. So it seems that you do not understand yourself
> --what you are talking about.
>
> #include <iostream>
> class Animal{};
> class Dog: public Animal{};
> class Cat: public Animal{};
>
> int main()
> {
> Cat* p_cat = new Cat;
> std::cout<< p_cat << std::endl;
> delete p_cat;
> Dog* p_dog = reinterpret_cast<Dog*>(p_cat);
> p_dog = new Dog;
> std::cout << p_dog;
>
>
>
> }


--What does this code overwrite?
--Also ... most compilers optimize the two lines:

--Dog* p_dog = reinterpret_cast<Dog*>(p_cat);
--p_dog = new Dog;

--Into something like:

-- Dog* p_dog = new Dog;

It doesn't trully overwrite anything but its the closet example I can give,
using C++ code.

Here is some code that demonstrates a similar thing:

#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);
}


You cannot do this type of recursion with a member function, a member
function belongs to the object with which its called.


 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      03-01-2011

"Leigh Johnston" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ...
> On 28/02/2011 23:54, Paul wrote:
>>
>> "Öö Tiib" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>> On Feb 28, 9:45 pm, "Paul" <(E-Mail Removed)> wrote:
>>> " Tiib" <(E-Mail Removed)> wrote in message
>>>
>>> news:(E-Mail Removed)...
>>> On Feb 25, 11:07 am, "Paul" <(E-Mail Removed)> wrote:
>>>
>>>
>>>
>>> > Please let me know if you still do not understand and I will
>>> > re-explain
>>> > again.
>>>
>>> --Your code does not work. You can not overwrite object 'Dog dog;' in a
>>> --way that Cat's destructor is called for it when that dog leaves
>>> --scope ... Dog's destructor is called for it on all C++ compilers i
>>> --could reach. What destructor will be called is pre-decided and set
>>> --already compile time. So it seems that you do not understand yourself
>>> --what you are talking about.
>>>
>>> #include <iostream>
>>> class Animal{};
>>> class Dog: public Animal{};
>>> class Cat: public Animal{};
>>>
>>> int main()
>>> {
>>> Cat* p_cat = new Cat;
>>> std::cout<< p_cat << std::endl;
>>> delete p_cat;
>>> Dog* p_dog = reinterpret_cast<Dog*>(p_cat);
>>> p_dog = new Dog;
>>> std::cout << p_dog;
>>>
>>>
>>>
>>> }

>>
>> --What does this code overwrite?
>> --Also ... most compilers optimize the two lines:
>>
>> --Dog* p_dog = reinterpret_cast<Dog*>(p_cat);
>> --p_dog = new Dog;
>>
>> --Into something like:
>>
>> -- Dog* p_dog = new Dog;
>>
>> It doesn't trully overwrite anything but its the closet example I can
>> give, using C++ code.
>>
>> Here is some code that demonstrates a similar thing:
>>
>> #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);
>> }
>>
>>
>> You cannot do this type of recursion with a member function, a member
>> function belongs to the object with which its called.
>>

>
> In C++ a member function does not belong to a particular object; in C++ a
> non-static member function is invoked on an object; in C++ a member
> function is a member of a class not an object.
>


If its a member of the class its also a member of the object you f*#"&i%$
moron.
If its a member of a class and not a member of an object it can only be a
static class member.

Please keep your ignorant, negative , spamming comments to yourself if you
have no reasoning to support your argument.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
This function has an onClick event that calls a function that calls This function Bob Javascript 5 10-24-2006 04:11 PM
ods calls business object then method calls ta with output params andy6 ASP .Net 2 06-09-2006 01:54 AM
How override ALL function calls? (Is there a "function call function"?) seberino@spawar.navy.mil Python 2 08-01-2005 12:38 PM
MoVoIP - FREE MOBILE Inetrnet Phone Calls - FREE Internet Phone Calls ubifone VOIP 0 07-29-2005 04:31 PM
Sequence of constructor calls and destructor calls. Honne Gowda A C++ 2 10-31-2003 09:31 AM



Advertisments