On 3/7/2012 1:09 AM, Peter Alexander wrote:
> On Wednesday, 7 March 2012 at 02:25:41 UTC, Walter Bright wrote:
>> On 3/6/2012 4:27 AM, Manu wrote:
>>> On 26 February 2012 00:55, Walter Bright <newshound2@digitalmars.com
>>> Most straight up GC vs malloc/free benchmarks miss something crucial. A GC
>>> allows one to do substantially *fewer* allocations. It's a lot faster to not
>>> allocate than to allocate.
>>> Do you really think that's true?
>>
>> Yes.
>
> I think you're both right. GC does definitely allow you to do less allocations,
> but as Manu said it also makes people more allocation happy.

I don't regard the latter as a problem with GC.


>>> Are there any statistics to support that?
>>
>> No, just my experience using both.
>>
>> Consider strings. In C, I'd often have a function that returns a string. The
>> caller then (eventually) free's it. That means the string must have been
>> allocated by malloc.
>
> I'd say it is bad design to return a malloc'd string. You should take a
> destination buffer as an argument and put the string there (like strcpy and
> friends). That way you can do whatever you want.

strcpy() is a known unsafe function. And the problem with passing a buffer is you usually do not know the size in advance. I don't agree with your contention that this is a bad design (for C).

On 3/6/2012 9:59 PM, Sean Kelly wrote:
> Slice ten bytes out of the middle of a ten MB buffer and the entire buffer sticks around.

True.

On Wed, Mar 07, 2012 at 02:26:28AM -0800, Walter Bright wrote:
> On 3/6/2012 9:59 PM, Sean Kelly wrote:
> >Slice ten bytes out of the middle of a ten MB buffer and the entire buffer sticks around.
[...]

Isn't there some way of dealing with this? I mean, if the GC marks the highest & lowest pointers that point to a 10MB block, it should be able to free up the unused parts. (Though I can see how this can be tricky, since the GC would have to understand which pointers involve arrays, so that it doesn't truncate long slices, etc.).


T

-- 
Marketing: the art of convincing people to pay for what they didn't need before which you can't deliver after.