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?

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.

On Jul 17, 2013, at 11:00 AM, David <d@dav1d.de> 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?

I sent a proposal to the runtime list ages ago about revamping the GC API.  But really, I'd like to eliminate GC.calloc entirely.  I'd rather have an allocation routine that takes a TypeInfo and uses that to initialize the block rather than just doing a memset(0) as per calloc.

Sean Kelly:

> I'd like to eliminate GC.calloc entirely.  I'd rather have an allocation routine that takes a TypeInfo and uses that to initialize the block rather than just doing a memset(0) as per calloc.

I think both are needed. The GC calloc is probably handy in some cases.

Bye,
bearophile

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.

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

> 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

Why not, it's exactly named like calloc, same with malloc, qalloc and free?

On Thu, Jul 18, 2013 at 12:38:37AM +0200, David wrote:
> > 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
> 
> Why not, it's exactly named like calloc, same with malloc, qalloc and free?
[...]

Naming it as "calloc" gives the false impression that perhaps it's equivalent to C's calloc, which is not true. Which is probably why you're complaining about the different order of parameters. :)


T

-- 
"Maybe" is a strange word.  When mom or dad says it it means "yes", but when my big brothers say it it means "no"! -- PJ jr.

On 7/17/13 1:33 PM, bearophile wrote:
> Sean Kelly:
>
>> I'd like to eliminate GC.calloc entirely. I'd rather have an
>> allocation routine that takes a TypeInfo and uses that to initialize
>> the block rather than just doing a memset(0) as per calloc.
>
> I think both are needed. The GC calloc is probably handy in some cases.

I don't find it all that useful as it's really an allocation followed by a fill.

Andrei

Am 18.07.2013 02:21, schrieb Andrei Alexandrescu:
> On 7/17/13 1:33 PM, bearophile wrote:
>> Sean Kelly:
>>
>>> I'd like to eliminate GC.calloc entirely. I'd rather have an allocation routine that takes a TypeInfo and uses that to initialize the block rather than just doing a memset(0) as per calloc.
>>
>> I think both are needed. The GC calloc is probably handy in some cases.
> 
> I don't find it all that useful as it's really an allocation followed by a fill.
> 
> Andrei
> 
> 

I use it all the time, e.g. I have an array of blocks (65536*12Byte) and I don't want the GC to care about this chunk of data (since it exists up to 961 times) but I can't just have it filled with random data -> calloc. Often when I was relativly new to C I always called malloc followed by a memset to 0, until I learned about calloc (but that's getting offtopic).