May be totally wrong about this but I always thought that ManagedBuffer(Pointer) would be really useful in conjunction w/ Metal. In particular, MTLBuffer gives you a region of memory that is in common configurations shared btwn the CPU and GPU. I believe the idea is you write your vertex data or textures or whatever into that region, which you then associate with a particular command you issue to the GPU.
-Colin > On Oct 19, 2016, at 6:28 PM, Alexis via swift-evolution > <swift-evolution@swift.org> wrote: > > A bit late to this game, because I didn’t fully understand the “point” of > ManagedBuffer(Pointer). After a good week of messing around with these in > Dictionary/Array/String, I now have Opinions. > > I agree ManagedBufferPointer is largely unnecessary. However it’s seeming a > lot like ManagedBuffer (and its equivalents) are suboptimal for the standard > library’s purposes too! > > In particular, pretty much every one of these buffers that I see wants to be > a subclass of some NS* collection so that it can be toll-free bridged into > objective C. This means that all those types are forced to directly drop down > to allocWithTailElems, rather than using a nice abstraction that does it for > them. Array does this right now, and I’ve got a PR up for review that’s doing > the same thing to the HashedCollections. It’s an outstanding bug that String > isn’t doing this (forcing its buffer to be wrapped in another class to be > bridged). > > I don’t really feel any pain from directly using allocWithTailElems, it’s a > great API. It just leaves me at a loss for when I’d reach for ManagedBuffer > at all, as it’s very limited. > > >> On Oct 13, 2016, at 3:11 PM, Erik Eckstein via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I created a proposal: https://github.com/apple/swift-evolution/pull/545 >> <https://github.com/apple/swift-evolution/pull/545> >> >>> On Oct 11, 2016, at 11:32 PM, Dave Abrahams via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> >>> on Tue Oct 11 2016, Károly Lőrentey <swift-evolution@swift.org >>> <mailto:swift-evolution@swift.org>> wrote: >>> >>>> +1 >>>> >>>> ManagedBuffer has been really useful a couple of times, but I never >>>> found a use for ManagedBufferPointer. I can’t even say I’m entirely >>>> sure what need it was originally designed to fulfill. >>> >>> The real need is/was to be able to do the same kind of storage >>> management in classes not derived from ManagedBuffer. This can be >>> important for bridging, where the buffers of various native swift >>> containers need to be derived from, e.g., NSString or NSArray. That is, >>> however, an extremely stdlib-specifc need. >>> >>> >>>>> On 2016-10-11, at 00:12, Erik Eckstein via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>> The purpose of ManagedBufferPointer is to create a buffer with a custom >>>>> class-metadata to be able >>>> to implement a custom deinit (e.g. to destroy the tail allocated elements). >>>>> It was used in Array (before I replaced it with the new >>>>> tail-allocated-array-built-ins). But now >>>> it’s not used anymore in the standard library. >>>>> >>>>> As a replacement for ManagedBufferPointer one can just derive a class >>>>> from ManagedBuffer and implement the deinit in the derived class. >>>>> >>>>> final class MyBuffer : ManagedBuffer<MyHeader, MyElements> { >>>>> deinit { >>>>> // do whatever needs to be done >>>>> } >>>>> } >>>>> >>>>> // creating MyBuffer: >>>>> let b = MyBuffer.create(minimumCapacity: 27, makingHeaderWith: { myb in >>>>> return MyHeader(...) }) >>>>> >>>>> IMO ManagedBuffer is much cleaner than ManagedBufferPointer (it doesn’t >>>>> need this custom >>>> bufferClass to be passed to the constructor). Also ManagedBufferPointer >>>> doesn’t use SIL >>>> tail-allocated arrays internally. Although this is not something visible >>>> to the programmer, it makes >>>> life easier for the compiler. >>>>> >>>>> So I suggest that we deprecate ManagedBufferPointer. >>>>> >>>>> Erik >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>> >>> -- >>> -Dave >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
