[phobos] custom BlkAttr flags

[Sean Kelly]

But in both cases, TypeInfo could be supplied (either at the point of allocation or set later).  A bit would be more efficient however.  Regarding how this would all work, I was thinking of redefining calloc as:

void* calloc(TypeInfo ti, size_t count);

So the TypeInfo would replace the 'size' argument from C.  This makes calloc a lot more useful than just "malloc with bzero" as it is now.

On Jul 14, 2010, at 3:26 AM, Steve Schveighoffer wrote:

> I added the fix for the comma, sorry for that.  All the other places had an 
> ALL_BITS enum member, so the NO_MOVE line that I copied and changed had a 
> comma.  I thought I compiled before I checked in, but I guess I did not.
> 
> Regarding the bit being flipped, yes I want the default meaning to be "no 
> append" because anyone can allocate memory via GC.malloc for any purpose, and 
> GC.malloc does not initialize the "allocated length" field inside the block, so 
> it is not appendable.  It does not mean you cannot append to the block, it just 
> means the first append will reallocate into an appendable block.
> 
> Regarding using the typeinfo, that doesn't work.  Arrays can easily be created 
> out of blocks that weren't allocated via the array creation routines.  Think of 
> void[], and GC.malloc above.
> 
> -Steve
> 
> 
> 
> 
> ----- Original Message ----
>> From: Sean Kelly <sean at invisibleduck.org>
>> To: Discuss the phobos library for D <phobos at puremagic.com>
>> Sent: Wed, July 14, 2010 12:25:09 AM
>> Subject: Re: [phobos] custom BlkAttr flags
>> 
>> On Jul 13, 2010, at 8:09 AM, Steve Schveighoffer wrote:
>>> 
>>> What I  propose to fix this is to allocate one of the block attribute flags 
>> to 
>> 
>>> designate that a block is appendable.  The odd part about it, is that the  
>> GC is 
>> 
>>> not aware of appending, so it is somewhat of a "user-defined"  flag.
>>> 
>>> My question is, how should we declare the flag?  I  currently only defined it 
>> in 
>> 
>>> lifetime.d, outside the gc, but I'm  thinking it should be defined in the GC 
>> as 
>> 
>>> well.  Also, should I  allocate the next bit, or one of the higher order 
>> bits?
>>> 
>>> I'm  going to check in my code that defines it in lifetime.d only, and 
>> depending 
>> 
>>> on the responses to this, I'll add it to the GC definition  too.
>> 
>> Your checkin doesn't compile.  I added the requisite comma for  now to fix 
>> this.  That aside, assuming this design were to be kept I think  the meaning of 
>> the bit has to be flipped.  The bit defaults to unset, so  that should be the 
>> default meaning.  You really don't want all blocks to be  appendable by default, 
>> do you?  More generally, if we start holding  TypeInfo references in the GC then 
>> we should be able to determine appendabiility  based on whether the TypeInfo is 
>> an array type.  This may not make the next  release, but I'd like to address it 
>> once I've polished std.concurrency a bit  more.
>> _______________________________________________
>> phobos mailing  list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
> 
> 
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos