# Safe to skip nullptr check for APVTS parameter pointers? **URL:** \ **Category:** Audio Plugins\ **Created:** [January 9, 2021, 9:04pm UTC](https://forum.juce.com/t/safe-to-skip-nullptr-check-for-apvts-parameter-pointers/43724 "2021-01-09T21:04:59Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![refusesoftware](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/refusesoftware/32/20561_2.png) [@refusesoftware](https://forum.juce.com/u/refusesoftware)\ **Post date:** [January 9, 2021, 9:04pm UTC](https://forum.juce.com/t/safe-to-skip-nullptr-check-for-apvts-parameter-pointers/43724/1 "2021-01-09T21:04:59Z")
In my plug-in code, I’m using a couple of the AudioProcessorValueTreeState methods that return raw pointers - [getParameter](https://docs.juce.com/master/classAudioProcessorValueTreeState.html#a9f0c5b406e32f94a7f2abb665044b395) and [getRawParameterValue](https://docs.juce.com/master/classAudioProcessorValueTreeState.html#aa2c12a8274038be9f6aa00d90f90ab11). Would it be considered safe to just check one time that these pointers are not nullptr (e.g. asserting in a constructor that the parameter specified in their `parameterID` does in fact exist), but then not continually check for nullptr after that point, every time you want to use one of the pointers? As far as I can tell, you cannot remove parameters from an AudioProcessorValueTreeState, and while technically you could destroy the AudioProcessorValueTreeState itself in your plug-in code, that would cause all kinds of hell to break loose. So, it would seem that you have a guarantee that those pointers will be valid for the lifetime of a (sane) plug-in instance. Is that a safe assumption to make? ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [January 9, 2021, 9:12pm UTC](https://forum.juce.com/t/safe-to-skip-nullptr-check-for-apvts-parameter-pointers/43724/2 "2021-01-09T21:12:05Z")
> [@refusesoftware](#): > > Would it be considered safe to just check one time that these pointers are not nullptr (e.g. asserting in a constructor that the parameter specified in their `parameterID` does in fact exist), but then not continually check for nullptr after that point, every time you want to use one of the pointers? I would say that is correct. The system is not designed to destroy the APVTS. While you could theoretically do that, there would probably many things break. I do the lookup in the constructor and assign it there to a dynamic\_casted variable. The next line is always a jassert with that pointer, so I will always know in a debug build, if I broke something (e.g. renaming a parameter ID or accidentally removing a parameter). After that there is no need to check over and over. ---
**Author:** ![refusesoftware](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/refusesoftware/32/20561_2.png) [@refusesoftware](https://forum.juce.com/u/refusesoftware)\ **Post date:** [January 9, 2021, 9:28pm UTC](https://forum.juce.com/t/safe-to-skip-nullptr-check-for-apvts-parameter-pointers/43724/3 "2021-01-09T21:28:34Z")
Thanks for lending your expertise to the question. It made sense to me that APVTS parameters and their pointers would be stable, but I wanted to make sure I wasn’t overlooking some important edge case. I’m curious, what is the dynamic casting that you’re doing? Do you mean casting the RangedAudioParameter pointer as a [AudioParameterBool, AudioParameterChoice, AudioParameterFloat, AudioParameterInt] pointer? ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [January 9, 2021, 9:32pm UTC](https://forum.juce.com/t/safe-to-skip-nullptr-check-for-apvts-parameter-pointers/43724/4 "2021-01-09T21:32:04Z")
> [@refusesoftware](#): > > Do you mean casting the RangedAudioParameter pointer as a [AudioParameterBool, AudioParameterChoice, AudioParameterFloat, AudioParameterInt] pointer? Yes exactly. This way parameter.get() returns thread safe the correct type, or getCurrentChoiceName()/gettIndex() in case of AudioParameterChoice.