GC.calloc

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Jul 17 14:51:54 PDT 2013


On Wed, Jul 17, 2013 at 11:46:57PM +0200, David wrote:
> Am 17.07.2013 20:17, schrieb deadalnix:
> > On Wednesday, 17 July 2013 at 18:00:03 UTC, David wrote:
> >> Why doesn't GC.calloc follow the function signature of stdc.calloc?
> >>
> >> calloc(num, size_per_element)
> >>
> >> I think this should be changed, if no reason speaks against it, I can
> >> look into changing this.
> >> Of course this will break backwards compatability, but I think this is
> >> worth it?
> > 
> > We wont think anything if you don't give us something to think about.
> > You may start by explaining why you think it is better.
> 
> Well the obvious reason is, it will have the same api as the stdc.calloc
> 
> GC.calloc(num, Data.sizeof) will not do what
> stdc.calloc(num, Data.sizeof) does
> 
> If you naivly assume they do the same (because that compiles), you will
> end up getting rather strange segmentation faults.
> 
> D tries to be C compatible a lot, I heared it also in someones talk
> recently, that this is indeed a goal, something that works in C and D
> has to do the same, in this case GC.calloc does something entirely
> different.

C does not have a native GC. I think expecting GC.calloc to be the same
as stdc.calloc is fallacious. But I agree that perhaps "calloc" isn't a
good name for the GC method.


T

-- 
In a world without fences, who needs Windows and Gates? -- Christian Surchi


More information about the Digitalmars-d mailing list