recursion order question

[lig]

hi ,
i am trying to do something that is not working (cuz i tried that)
so i hope for some ideas about it.

ok, so i have this recursive function, lets call it recFun
and i wanted to be able to call it in a specific order.

in a simple way : evaluating some expression in its original order

see the following part of code:

class retType
{
....
retType doSomething(som eType4,retType) ;
....
};

retType recFun(someType 3 ,someType1)
{
....
someType1 b,d;
someType2 c;
someType3 a;
....
return recFun(a,b).doS omething(c,recF un(a,c))
....
}

well , i was sure (for some weird reason...) that the first call
will be recFun(a,b) but actually the first call was recFun(a,c) .

the problem is that i wanted a specific order (first first
then the second .. obviously..) and it wont do it.

some of my limitations are: i dont want to keep any copies
of the results of the calls ( it creates more nodes in some tree ...
which obviously i dont want to count)
and the second is that i need the keep the order due some
other dependencies .

so any ideas/revelations will be most welcomed .

bye
lig

p.s.
this is my first post on this kind of groups so excuse me if
i dont meet the protocol rules ...

[John Harrison]

Re: recursion order question

lig wrote:[color=blue]
> hi ,
> i am trying to do something that is not working (cuz i tried that)
> so i hope for some ideas about it.
>
> ok, so i have this recursive function, lets call it recFun
> and i wanted to be able to call it in a specific order.
>
> in a simple way : evaluating some expression in its original order
>
> see the following part of code:
>
> class retType
> {
> ...
> retType doSomething(som eType4,retType) ;
> ...
> };
>
> retType recFun(someType 3 ,someType1)
> {
> ...
> someType1 b,d;
> someType2 c;
> someType3 a;
> ...
> return recFun(a,b).doS omething(c,recF un(a,c))
> ...
> }
>
> well , i was sure (for some weird reason...) that the first call
> will be recFun(a,b) but actually the first call was recFun(a,c) .[/color]

The order is undefined, a compiler could do either, and both would be right.
[color=blue]
>
> the problem is that i wanted a specific order (first first
> then the second .. obviously..) and it wont do it.
>
> some of my limitations are: i dont want to keep any copies
> of the results of the calls ( it creates more nodes in some tree ...
> which obviously i dont want to count)[/color]

Maybe you can use a reference

const retType& tmp = recFun(a,b);
return tmp.doSomething (c,recFun(a,c)) ;

but you would have to change the function signature to be const.
[color=blue]
> and the second is that i need the keep the order due some
> other dependencies .[/color]

I'd seriously look at relaxing that restriction.
[color=blue]
>
> so any ideas/revelations will be most welcomed .
>
> bye
> lig
>[/color]

john

[Howard]

Re: recursion order question


"lig" <arbelig@gmail. com> wrote in message
news:1126804840 .079779.269780@ g14g2000cwa.goo glegroups.com.. .[color=blue]
> hi ,
> i am trying to do something that is not working (cuz i tried that)
> so i hope for some ideas about it.
>
> ok, so i have this recursive function, lets call it recFun
> and i wanted to be able to call it in a specific order.
>
> in a simple way : evaluating some expression in its original order
>
> see the following part of code:
>
> class retType
> {
> ...
> retType doSomething(som eType4,retType) ;
> ...
> };
>
> retType recFun(someType 3 ,someType1)[/color]

Are someType3 and someType1 classes? Are they defined somewhere? Why don't
you have names for them here? Aren't you planning on using them inside the
function somewhere?

(Also, are you sure you want to pass those by value?)
[color=blue]
> {
> ...
> someType1 b,d;
> someType2 c;
> someType3 a;[/color]

These are local variables. What about the parameters that were passed in.
As it is, you're ignoring them entirely.
[color=blue]
> ...
> return recFun(a,b).doS omething(c,recF un(a,c))[/color]

You've said above that c is of the type "someType2" , but you're passing as
the first parameter to doSomething, which expects a variable of type
"someType4" . You're also passing it as the second parameter of recFun,
which is expecting a "someType1" variable.
[color=blue]
> ...
> }
>
> well , i was sure (for some weird reason...) that the first call
> will be recFun(a,b) but actually the first call was recFun(a,c) .[/color]

How else could it work? It has to pass a retType variable to doSomething.
In order to do that, it first needs to call recFun, in order to get back the
retType result, right? So, before it can call doSomething, it has to
execute recFun.
[color=blue]
>
> the problem is that i wanted a specific order (first first
> then the second .. obviously..) and it wont do it.
>
> some of my limitations are: i dont want to keep any copies
> of the results of the calls ( it creates more nodes in some tree ...
> which obviously i dont want to count)[/color]

If you don't want copies, then you probably don't want to pass and return by
value. But what you _do_ want is really impossible for me to tell, because
your code doesn't really make sense.

(And how does doSomething create a retType object. You left out that code.)
[color=blue]
> and the second is that i need the keep the order due some
> other dependencies .[/color]

I'm not sure what order it is you need to keep. But there's no way to
execute doSomething unless you give it the values it needs, which means you
have to somehow compute those values first (unless doSomething itself can
make a function call to get the value it needs, instead of passing it that
second parameter).

-Howard

[Howard]

Re: recursion order question


"Howard" <alicebt@hotmai l.com> wrote in message
news:7LiWe.4585 5$qY1.21373@bgt nsc04-[color=blue][color=green]
>>
>> well , i was sure (for some weird reason...) that the first call
>> will be recFun(a,b) but actually the first call was recFun(a,c) .[/color]
>
> How else could it work? It has to pass a retType variable to doSomething.
> In order to do that, it first needs to call recFun, in order to get back
> the retType result, right? So, before it can call doSomething, it has to
> execute recFun.
>[/color]

Oops, my mistake. You were talking about the two calls to recFun, not the
call to doSomething. As John stated, the order of those calls is not
defined. But you can put them in separate statements like he showed to
control the order.

-Howard

[Jack Klein]

Re: recursion order question

On Thu, 15 Sep 2005 18:01:18 GMT, John Harrison
<john_andronicu s@hotmail.com> wrote in comp.lang.c++:
[color=blue]
> lig wrote:[/color]

[snip]
[color=blue][color=green]
> > return recFun(a,b).doS omething(c,recF un(a,c))
> > ...
> > }
> >
> > well , i was sure (for some weird reason...) that the first call
> > will be recFun(a,b) but actually the first call was recFun(a,c) .[/color]
>
> The order is undefined, a compiler could do either, and both would be right.[/color]

ITYM "unspecifie d", not "undefined" . A world of difference.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++

http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

[John Harrison]

Re: recursion order question

Jack Klein wrote:[color=blue]
> On Thu, 15 Sep 2005 18:01:18 GMT, John Harrison
> <john_andronicu s@hotmail.com> wrote in comp.lang.c++:
>
>[color=green]
>>lig wrote:[/color]
>
>
> [snip]
>
>[color=green][color=darkred]
>>> return recFun(a,b).doS omething(c,recF un(a,c))
>>>...
>>>}
>>>
>>>well , i was sure (for some weird reason...) that the first call
>>>will be recFun(a,b) but actually the first call was recFun(a,c) .[/color]
>>
>>The order is undefined, a compiler could do either, and both would be right.[/color]
>
>
> ITYM "unspecifie d", not "undefined" . A world of difference.
>[/color]

Right, in other words it is one order or the other.

john

[lig]

Re: recursion order question

first thanks for the ideas .

second , yea i did a type mistake there above ... (tried to keep it
simple)

i'll think i'll try the local copy option. i missed the part that the
dtor of
retType class (which i didnt wrote myself) is removing his projection
from the tree , so the limitation of not keeping copies is no longer
relevant.

thanks again for your ideas.

lig