FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

std.memory

 
Post new topic   Reply to topic     Forum Index -> Ares
View previous topic :: View next topic  
Author Message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Sat Jan 28, 2006 5:35 am    Post subject: std.memory Reply with quote

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
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Sat Jan 28, 2006 12:06 pm    Post subject: Re: std.memory Reply with quote

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
View user's profile Send private message Yahoo Messenger
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Mon Jan 30, 2006 12:04 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Ares All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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