gianlucaelia

@capital-G I've just found a minor thing regarding `.extension-indicator-ctr` that we might have lost in the middle of things, could you fix it please? I reopened the conversation above

Thanks for your comments, I tried to summarize main points emerged so far in the PR description above. My comments: 1. **stop throwing**: I'm not savvy enough to advocate for...

> > I think it would be nice to release unused memory when Ctors fail > > Definitely! It would be a memory leak otherwise. Just for the sake of...

> Also, we would have to look at sclang because it also uses `AllocPool`. However, the pool is growable and allocation only fails if the OS can't give any more...

> Memory management is the responsibility of the plugin author. There are several different approaches. Actually, with C++ you could use standard containers with a custom allocator, but it has...

Great! However, for the sake of this issue alone, changing that allocator wouldn't change the relationship to exceptions and NULL checks, so we can regard it as a separate issue,...

Excuse my definitely not enough experience with RAII, but I have a questions: an approach like ScopedPtr would be mainly useful for plugins written as proper classes with proper lifecycle,...

> I'm not sure what "proper classes with proper lifecycle" are. Do you mean Units that have a destructor function? ScopedPtr and CleanUp are meant to be used as local...

> Where does e.what() come from? Sorry, was a leftover from the previous version, which caught an exception. I edited it out now. > you would need to set all...

Also, about releasing eventual previously allocated memory when one RTAlloc fails, I'm suspecting it wouldn't be a good idea to call the Unit Dtor directly. Especially in UGens written as...