Unique_ptr in Processor Parameters


#1

Hello,
seeing several posts about unique_ptr i tried to apply them in my AudioParameters, so i did the following:
in PluginProcessor.h
std::unique_ptr Master;

in PluginProcessor.cpp - constructor
Master = std::unique_ptr(new AudioParameterFloat(“masterParam”, “Master”,-6.f, 0.f, 0.f));
addParameter(Master.get());

This compiles and standalone plugin runs ok but when hitting x button (exit) i get the following exception:
JUCE Message Thread (1): EXC_BAD_ACCESS (code=1, address=0x8)
in juce_ContainerDeletePolicy.h file
line 54

The .vst does not run at all

Am i in the correct direction or there is a completely different way to implement processorParameters with unique_ptrs?


#3

The documentation to AudioProcessor::addParameter() says:

The parameter object will be managed and deleted automatically by the list when no longer needed.

The unique_ptr will also manage the lifetime, which leads to deleting the parameter twice.

Also have a look at the syntax, how a unique_ptr is assigned, best to use
ptr = std::make_unique<MyClass> (arg1, ...);

HTH


#4

so, smart pointers wont work for processor parameters, if i got that right.
thanks guys!!


#5

No, you can’t say it this way. Wrapping everything in smart pointers generally is a quite good approach. However if you pass your instance currently owned by the std::unique_ptr to an object that will take over ownership, you want to use release instead of get. Maybe in this case it is not absolutely needed but there are many cases where you check if the instance you created is valid and then decide to release it to another object or otherwise just let the unique pointer go out of scope, so it will take care of deleting the invalid instance it holds


#6

Which will reset the unique_ptr to nullptr. So this is not what you usually want in that case. There are other smart pointers for that use case.

The AudioProcessor has only addParameter, there is no chance to get rid of the parameters other than destroying the whole processor. Hence it is safe to use a raw pointer here, as long as you only use it only in methods of the AudioProcessor.
You can also use it in processBlock, even though it is called from a different thread. But the framework makes sure, that it is not called in parallel with the destructor.


#7

Sorry, I had a totally different general scenario in mind (construction of something then passing it to some new owner and let the pointer used for construction go out of scope instead of using the pointer to access something later).
Should have read the actual question more carefully before providing a useless answer :grimacing:. Daniels answer is totally right