Here's a simplified look at some of my code:
proc1
var/roads
proc2(roads)
usr << "[roads]"
proc2(var/roads)
if(blah)
roads++
proc3(roads)
proc3(var/roads)
if(blah) // may recursively call proc2 a few times
proc2(roads)
I had hoped the variable roads would be passed back up as well as down, but it doesn't seem to be working. I know I could just use a global variable instead, but I would prefer to keep it defined within proc1 (another complication is that not all these procs are within the same obj).
Any suggestions?
Thanks.
ID:179191
 Feb 5 2002, 11:10 am
|
|
|
Feb 5 2002, 11:13 am
|
|
Dramstud
 |
I forgot to mention that I also have another variable (a list) which is being passed at the same time as roads. However, the list seems to be working fine.
|
All objects (this includes areas, turfs, objs, mobs, lists, and a few other things) are passed by reference. That is, there is only one copy of the object, and each routine modifies the same copy. That's why it works with lists. Other types (numbers, text, etc) are passed by value, so each routine gets a copy of that value. What you'll need to do in that case is return the value in each proc back to the calling proc. Something like this:
proc1 | |
but what if I'm already returning a different variable?(which is the case, though I left it out of my simplified example)
| |
Ah, then what you could do is create a datum that will hold the roads variable across procedure calls. Like all objects, the datum is passed by reference.
RoadTracker | |
ok, that solved the problem. Thanks Mapster!
Air Mapster wrote: Ah, then what you could do is create a datum that will hold the roads variable across procedure calls. Like all objects, the datum is passed by reference. > RoadTracker | |
Here's a fairly detailed write-up straight from the minds of Minolta, er, Dantom, if it helps:
id:3231 | |
I'm not that familiar with datum so I was wondering something. Would you want to delete the datum thingamajig after your finished with the procs so you don't effectively have a memory leak or is the datum not actually "created" in the world where it stays until deleted?
| |
The way I understand it, DM protects you from memory leaks by automatically deleting any object which no longer has a pointer to it. For instance, if you have a list of objects, and you change it's length to zero, all the objects are deleted (assuming nothing else points to them). In my case, once I exit the proc where I created the datum, it should get deleted automatically.
Perhaps someone with more DM experience could confirm this? English wrote: I'm not that familiar with datum so I was wondering something. Would you want to delete the datum thingamajig after your finished with the procs so you don't effectively have a memory leak or is the datum not actually "created" in the world where it stays until deleted? | |
dramstud wrote:
The way I understand it, DM protects you from memory leaks by automatically deleting any object which no longer has a pointer to it. For instance, if you have a list of objects, and you change it's length to zero, all the objects are deleted (assuming nothing else points to them). In my case, once I exit the proc where I created the datum, it should get deleted automatically. That's correct. Note that non-player atoms must be at loc==null to be deleted, since otherwise they would be in the contents list of some other object (world.contents is ignored for the garbage collector). | |