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