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 <[email protected]> >> To: Discuss the phobos library for D <[email protected]> >> 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 >> [email protected] >> http://lists.puremagic.com/mailman/listinfo/phobos >> > > > > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
