create/destroy name change proposal

[Mark Beall]

Mark,

I didn't say that I think iMesh_destroyMesh SHOULD free memory, I just  
said that could be a reasonable requirement. That could be a problem  
for an implementation that uses a true garbage collecting memory  
manager (although one can usually force them to do their garbage  
collecting), it also assumes that implementations are written in a  
language that allows you to explicitly control memory management  
(which, practically, may be a reasonable assumption).

mark

On May 6, 2010, at 11:59 AM, Mark Miller wrote:

> On Thu, 2010-05-06 at 08:51, Tim Tautges wrote:
>
> iMesh_newMesh --> iMesh_createMesh
> iMesh_dtor --> iMesh_destroyMesh
>
> Yes, thats better than iMesh_new and iMesh_destroy. I agree.
>
>>
>> - I think we should allow apps to specialize on memory management,  
>> and the current API allows that well enough now
>>
>
> What about iMesh_destroyMesh? Like Mark B., I think that SHOULD free
> memory because it is destroying the whole of the iMesh instance and
> there is no valid argument I think for having some objects within it
> left around.
>
> So, I think that caller's should be made aware of the fact that if  
> they
> expect an iMesh_destroyXXX (or even iMesh_removeXXX) to free memory,
> that the iMesh specification makes no guarantees regarding free'ing of
> memory. I think that is a common expectation for user's calling a
> destroy (and maybe even a remove) function to have and I think they
> should be forewarned that such expectation is not valid.
>
> Mark
>
> -- 
> Mark C. Miller, Lawrence Livermore National Laboratory
> ================!!LLNL BUSINESS ONLY!!================
> miller86 at llnl.gov      urgent: miller86 at pager.llnl.gov
> T:8-6 (925)-423-5901     M/W/Th:7-12,2-7 (530)-753-851
>