From: Dirk R. <di...@in...> - 2007-09-17 20:53:22
|
Hi Allen, Allen Bierbaum wrote: > Carsten: > > I appreciate the detailed description. I think I have to read it a few > more times to fully grasp the internal details. > > What I think would be useful would be to describe the the user-level API > would look like. For example, will a user application only use > RefPtr's? Will these handle all the internal details automatically? > How will user apps handle aspects or will this be hidden? When the user > needs a true cptr, how will they get them. > > I guess what I am saying is that I am asking a much simpler question of > what will everything look like to users. I am just trusting that you > and Dirk will be able to get everything working correctly internally. :) I can try to take a shot at that, given that there are a lot of my Christmas wishes in there. ;) Applications would be forced to use RefPtrs to store the values they get back from the factory or ::create. That way we can be sure that at least one RefPtr is used and at least one ref is there. Internally apps would be strongly encouraged to use RefPtrs to store FCs, but we won't enforce it. .get() will give you a regular C ptr if you want it. It's recommended to do that for passing parameters or for temporaries (as long as there is a guaranteed other ref) anyway. Aspects won't be hidden. RefPtrs are only valid in the aspect they were initialized in. I was planning on enforcing that, but it might make sense to have a test in there for debugging purposes. To go between threads you would have to use a MTRefPtr. That one behaves pretty much like the current FCs: whenever it is dereferenced it returns a CPtr for the current thread's aspect. So the impact on user code except for the forced RefPtr at the beginning should be minimal. So far we haven't looked at the CoredRefPtrs. Are you using those? I don't they need any changes, but if there are ways to make them better, no is the time to do it. Dirk |