RE: [Dev-C++] Another newbie question about fn's returning STL containers

[P.D. v. Z. <pa...@my...>]

Hi,

Returning an STL container from a function is valid, but it will give you a
performance decrease. Every time you call this function, a new container is
created, filled, and then returned, upon which the entire container gets
copied over to the destination (element by element). Can't really recommend
a better way to solve it though, I usually lay my designs out differently :)

Regards,


Paul

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Matt Kerr
Sent: Friday, October 24, 2003 11:17 AM
To: dev...@li...
Subject: [Dev-C++] Another newbie question about fn's returning STL
containers

I'm generating a stack of custom board class objects, and was wondering what
the proper way to do this is (this is all for a board game-- tic-tac-toe in
this case).

What I have is a board member function called Generate_Moves that returns a
stack of boards (ie. stack<board> ) of new possible selections.

In the calling fn, I have a passed in variable of type board called state
and do this:

stack<board> moves;
moves = state.Generate_Moves( p ); // p is the player whose turn it is

Is this valid? Or should I be making "moves" a pointer, and then return a
pointer to the new stack from Generate_Moves (and call delete on it when I'm
done ? ).

I was thinking that the way I have it right now is going to lose the "moves"
stack in memory and cause a leak because it will add another lost guy every
time the containing fn is called....

Implementing this minimax algorithm for tic-tac-toe was so much simpler in
LISP :(



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users