Erm... I a potential issue is that this is moving some logic that could be considered runtime stuff into the GC. Should the GC simply accept a pointer to a custom finalization routine instead?
For Andrei's suggestion, I think it's a good one, but I don't think it would work for arrays of structs. On Jul 14, 2010, at 8:44 AM, Sean Kelly wrote: > 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 _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
