Embrace OptionalScopedPointer?

JUCE has several (6 that I found at least) classes whose constructors take delete...WhenDeleted arguments, and most implement it with OptionalScopedPointer internally.

  • Sometimes, like in BufferingAudioSource the deleteSourceWhenDeleted parameter doesn’t come right after the source parameter that it refers to but there are more arguments in between.
  • Additionally there are classes like BufferingAudioReader which just take the ownership but it’s unclear why those are different.

I would like to suggest what I think is an improvement to the interface:

  • Change these classes to take an OptionalScopedPointer instead of the pair of pointer and boolean
  • Make the casts from std::unique_ptr and from references to OptionalScopedPointer implicit rather than explicit, and additionally make it also support casts from unique_ptr of sub-classes. This would make the usage very ergonomic - if you have a unique_ptr you can just std::move it into arguments to juce classes. Or you can even use std::make_unique<Stuff> right in the arguments.

I also made a branch to demonstrate these changes.

Cheers, Yair

Nice one, unfortunately I’m out of votes at the moment


Btw did you know that you get back the votes for implemented features? If there’s no bug then it seems that you should have one free vote, sorry for the stalking heh but that’s virtual lobbying I guess :wink:

Hehe, just adding it was said you would get votes back automatically once the topic closed, but it seems you still have to claim them back. And you can claim votes back at any time from any issue.

From my experience it was this way at first but it was fixed.

Uhm, didn’t work for me about three weeks ago, but well… Hard to test since it doesn’t happen to often… :wink:

1 Like

Ah! you’re right, I’m constantly out of votes so I didn’t even check but it looks like I got one back somehow. Here it goes!

1 Like