Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

function calls

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

"Öö Tiib" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On Feb 22, 8:58 pm, "Paul" <(E-Mail Removed)> wrote:
> "James Kanze" <(E-Mail Removed)> wrote in message
>
> -- 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*/
}


Your post is presented well (in a way that makes one think about it).


--Now if to think about flexibility of interface ... then in C++ i
--actually don't even know exactly whose member function was called in
--first line and if there was a function called at all in second line.

Yep because it could be an constructor (still a function I guess but I'm
with ya I think)

--Maybe first line called operator()() of public data member of bag1
--named "sort"
This loses me I'm afraid, I will need to think some more on this.

-- and second line maybe constructed temporary of type
--"sort".
Yep as I commented above I see that.

Alot of this has to do with OO design I think.
Ty for your post.
Paul.




 
Reply With Quote
 
 
 
 
Öö Tiib
Guest
Posts: n/a
 
      02-23-2011
On Feb 23, 2:43*am, "Paul" <(E-Mail Removed)> wrote:
> " Tiib" <(E-Mail Removed)> wrote in message
>
> --Maybe first line called operator()() of public data member of bag1
> --named "sort"
> This loses me I'm afraid, I will need to think some more on this.


I meant like that:

struct A
{
void operator()() { }
};

struct B
{
A sort;
};

int main()
{
B bag1;
bag1.sort();
}
 
Reply With Quote
 
 
 
 
Paul
Guest
Posts: n/a
 
      02-23-2011

"Öö Tiib" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On Feb 23, 2:43 am, "Paul" <(E-Mail Removed)> wrote:
> " Tiib" <(E-Mail Removed)> wrote in message
>
> --Maybe first line called operator()() of public data member of bag1
> --named "sort"
> This loses me I'm afraid, I will need to think some more on this.


--I meant like that:
--struct A { void operator()() { } };
--struct B { A sort; };

-- int main(){
-- B bag1;
-- bag1.sort();
-- }
Oh yes, I understand this.
But I'm not sure about the point you were making about the flexibility of
the interfase.

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

"Paul" <(E-Mail Removed)> wrote in message
news:RKY8p.30888$(E-Mail Removed)2...
>
> "Öö Tiib" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> On Feb 22, 8:58 pm, "Paul" <(E-Mail Removed)> wrote:
>> "James Kanze" <(E-Mail Removed)> wrote in message
>>
>> -- 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?

<snip>

 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      02-23-2011
On Feb 23, 4:06*am, "Paul" <(E-Mail Removed)> wrote:
> "Paul" <(E-Mail Removed)> wrote in message
>
> news:RKY8p.30888$(E-Mail Removed)2...
>
>
>
>
>
> > " Tiib" <(E-Mail Removed)> wrote in message
> >news:(E-Mail Removed)....
> > On Feb 22, 8:58 pm, "Paul" <(E-Mail Removed)> wrote:
> >> "James Kanze" <(E-Mail Removed)> wrote in message

>
> >> -- 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).
 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      02-23-2011

"Öö 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?*/
}

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


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

I hope I have explained well.

TY
Paul.

 
Reply With Quote
 
Rolf Magnus
Guest
Posts: n/a
 
      02-23-2011
Paul wrote:

> 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*/


You can't change the this pointer. It is constant, so the compiler will bail
out with an error at this point.

> (*this).sort(); /*re-invoke this function is not possible, what does
> 'this' point to?*/
> }
>
> sort(anObj){
> anObj = new anObjTye; /*replacing the object( heap or stack whatever,
> the code is psuedo)*/
> pointertothisfunction(anObj) /*Ok to call this function, recursion is
> ok
> with a new object.*/
> }
>
>
> The member function version does not have the same possible sequences of
> execution as the normal version.
> The member function version has an object identity, it belongs to the
> object on which it is called.


Within the member function, the this-pointer is const, and so you can't
assign to it. If you declare your non-member function as:

sort(sometype* const anObj)

you'll have the same problem as with the member function.

 
Reply With Quote
 
gwowen
Guest
Posts: n/a
 
      02-23-2011
On Feb 23, 8:52*am, "Paul" <(E-Mail Removed)> wrote:
> The member function version does not have the same possible sequences of
> execution as the normal version.


What does this mean?

> The member function version has an object identity,


What does this mean?
 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      02-23-2011

"Rolf Magnus" <(E-Mail Removed)> wrote in message
news:ik2n1f$2cn$01$(E-Mail Removed)-online.com...
> Paul wrote:
>
>> 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*/

>
> You can't change the this pointer. It is constant, so the compiler will
> bail
> out with an error at this point.


This is psuedo code, you can change the object 'this' points to using any
code you like, obviously that's assuming the object is not stored in
read-only memoery.
Sorry I should've made a specific note about psuedo code. I presumed it was
obvious following from the context of my previous example.

>
>> (*this).sort(); /*re-invoke this function is not possible, what does
>> 'this' point to?*/
>> }
>>
>> sort(anObj){
>> anObj = new anObjTye; /*replacing the object( heap or stack whatever,
>> the code is psuedo)*/
>> pointertothisfunction(anObj) /*Ok to call this function, recursion is
>> ok
>> with a new object.*/
>> }
>>
>>
>> The member function version does not have the same possible sequences of
>> execution as the normal version.
>> The member function version has an object identity, it belongs to the
>> object on which it is called.

>
> Within the member function, the this-pointer is const, and so you can't
> assign to it. If you declare your non-member function as:
>
> sort(sometype* const anObj)
>
> you'll have the same problem as with the member function.
>

The constantness is not rellevant to understand the point as code can be
written to overcome that.
Neither the stack nor the heap is read only. The object 'this' points to is
likely to be in one of these areas, therefore overwriteable.

Ty for reading
Paul.

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

"gwowen" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On Feb 23, 8:52 am, "Paul" <(E-Mail Removed)> wrote:
> The member function version does not have the same possible sequences of
> execution as the normal version.


>>What does this mean?

It means the member function stops but the normal function is recursive.


> The member function version has an object identity,?


>>What does this mean?

It means each function invokation is attached to a unique object

 
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