> On 26. Mar 2018, at 00:00, Eliot Miranda <[email protected]> wrote:
>
> Hi Holger,
Hey!
> Is the intent of CCallOut with: aBlock to collect and defer deallocations
> until the block completes? I think it's nice but complex and wonder how
> general it is. But it seems like it would impact a lot of code and require a
> lot of effort changing existing code bases. My handle scheme is only
> intended to fix the issue of images crashing on startup. The problems with
> crashing on startup being a) one loses one's work and b) the issue is hard to
> debug. That, for me, motivates something like the simple fix I p[roposed.
> I'm not standing in the way of something more beautiful, but I do believe
> that one shouldn't make the perfect the enemy of the good.
By all means, let's have a smart pointer! It will be beneficial for freetype
and many other places. Nobody likes crashing images (for a mistake made in a
previous run).
My intent with the CCallOut is inhibit image saving until the code is outside a
sequence of (interruptible, hence the backward jump int the example) C calls
working with one or more pieces of manually managed memory. But maybe it is
best to call it by what it does instead of finding a name of where it is used.
I can't come up with a better example right now. But I think a Smartpointer
wouldn't be of much help with a sequence of strtok calls.
word := CStringAPI strtok: cStringPtr safeBytes separator: '\r'.
[word isNil] whileFalse: [
word = 'Foo'...
word = 'Bla'...
word := CStringAPI strtok: nil separator: '\r'
------------- Image Save happening right here and word is not nil -----
].
I hope this is more clear.
holger
