View previous topic :: View next topic |
Author |
Message |
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Sat Jan 28, 2006 5:35 am Post subject: std.memory |
|
|
I figured I may as well devote a thread to each of the modules that exist so far, as it may help to solicit feedback on them. std.memory is the front-end for GC and other memory-related functionality. I'd considered a number of different interfaces, but finally decided on the existing one because it avoided inherent performance penalties (such as a virtual call), and at the same time allowed for future syntax changes that may go this direction (dynamic GC loading, etc). So while I'm not entirely happy with having the functionality all tie back to a set of extern (C) functions, I think it's unavoidable in this case.
At the moment, I'm most interested in what people think of GC.realloc, as I'm still debating the interface. My motivation for adding it was to allow for optimal resizing, mostly to support D's built-in arrays. What I don't like about the current semantics is that there's no way to tell if the reallocation has failed simply by checking the function return value. You have to call gc.sizeOf(p) to make sure the array has been resized correctly. I've considered changing the return type to bool (to indicate success) and changing the pointer param to be inout, but I'm a tad leery of side-effects here for some reason. Any suggestions? |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Sat Jan 28, 2006 12:06 pm Post subject: Re: std.memory |
|
|
Took a look at the code: this looks great!
sean wrote: | At the moment, I'm most interested in what people think of GC.realloc, as I'm still debating the interface. My motivation for adding it was to allow for optimal resizing, mostly to support D's built-in arrays. What I don't like about the current semantics is that there's no way to tell if the reallocation has failed simply by checking the function return value. You have to call gc.sizeOf(p) to make sure the array has been resized correctly. I've considered changing the return type to bool (to indicate success) and changing the pointer param to be inout, but I'm a tad leery of side-effects here for some reason. Any suggestions? |
Well, the additional call to gc.sizeOf(p) to verify the resizing could be done as an assert within the call to resize(). That way, it can be thrown out much like the bounds-checks et al do during a "release" build. Otherwise, it could be done as a version() so that it can be switched on/off independently of the rest of the codebase.
Other that that, I see why you're hesitant about the C-level tiebacks to lower level code. However, this design does get the door open wide enough to allow a whole flood of improvements and custom GC designs; it is worth the hackyness of getting things to work with phobos' GC. _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Mon Jan 30, 2006 12:04 pm Post subject: |
|
|
I was being dumb. The functions will throw an OutOfMemoryException on failure, so no need to check for success. I'll document accordingly. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|