Take a look at Buffer:free --
free { arg completionMessage;
server.listSendMsg( this.freeMsg(completionMessage) );
}
It instructs the server to release the buffer, but does nothing else.
A Buffer (on the client) is really just a placeholder for the buffer number. Client-side Buffer objects don't know about changes in a server-side buffer's status. In your example, b was actually freed on the server, but "b" means (with respect to server communication), "Do stuff with whatever is being held at that buffer number right now." The other buffer object, d, puts new stuff at the same location that b is pointing to.
b and d are distinct objects on the client, but they point to the same buffer number on the server.
A sloppy C programmer can do something similar with a pointer variable that wasn't cleared properly -- i.e., try to access a memory location that is no longer allocated, or that is currently allocated for something else. There, the consequence is probably that the program crashes, rather than an unexpected response to .play.
We could argue about whether Buffer:free should clear the bufnum variable. I'm skeptical because it might break code.
If b's content is no longer meaningful in your code after freeing it, why not clear it? b = nil -- Cleaning up your garbage is a generally good programming practice anyway.
hjh
On Jul 20, 2008, at 9:14 AM, thor wrote:
b.play // but I thought I'd freed b?
b.bufnum // and now b and d share same bufnum !!!
: H. James Harkins
: jamshark70@...
: http://www.dewdrop-world.net
.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:
"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman
