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 <newshou...@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).
