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
