Passing around const ValueTree& and setProperty

Hi,
Is const ValueTree& the safest way to share around ValueTrees and subValueTrees. If so, is there a trick to use const ValueTree& with functions like setProperty?
Is ( const_cast<ValueTree&>(valueTree) ) ok?
thank you

@dave96’s talk about ValueTrees from ADC explains that ValueTrees are trivial to copy, that they just result in an increment in the SharedObject’s use counter.

@6:50

Hi,
Is this ok practice-

void setProperty (const ValueTree& valueTree, const UndoManager& undoManager, const Identifier& identifier, const var& newValue)
{
    const_cast<ValueTree&>(valueTree).setProperty (identifier, newValue, &const_cast<UndoManager&>(undoManager) );
}

Thank you

const_cast is almost never right. In that function, just pass the ValueTree (and the UndoManager) by mutable reference since the intention is to modify it anyway. The added const doesn’t give you any benefit.

2 Likes

Why are you writing a helper function to set properties on a valuetree? Are you using multiple value trees in the same class and want one interface to modify them?

Hi,
That was a basic example. I am passing ValueTrees and UndoManagers throughout my whole plug-in from the processor.
Thank you

Nevertheless, the added consts for the references are useless if you need to modify the objects anyway.

I might be wrong, but I think you should just have one undo manager in the plugin.

1 Like

Yeah it is probably going to be a mess to have multiple UndoManagers…

I have separate UndoManagers for separate ValueTrees and only one UndoManager associated with the AVPTS. Is that ok?
I was also hoping that the const_cast<ValueTree&>.setProperty might only change the associated var and not the tree. I can see that the &const_cast<UndoManager&>(undoManager) is probably out of the question.
Cheers
Thanks for the time

If you change a property of the ValueTree, you change the tree, there’s not really a way around that. What are you actually trying to do?

I have been using const ValueTree& to pass around ValueTrees owned by the processor. I am using the occasional const_cast<ValueTree&>. It is a lot of code and classes. It appears really stable changing to const ValueTree&, but I will use ValueTree& instead.
Thank you for your help

Pass by const reference when you’re just want to have something be read only.

Pass by reference when you want to edit something owned by some other object

Ok, that sounds pretty standard. Jules says not to use ValueTree*, but is ValueTree* const be better than ValueTree& until I need to start switching trees.
Cheers

It sounds like you are missing some fundamental knowledge about c++. I’ll suggest you read about passing references around at learncpp.com

Thanks for the link. I have gone through a similar course online, but I am learning on the fly. Many hours on stack overflow. Lost my two programmers at different times over the last 5 years, without documentation and in the last case he included bonus changes to the JUCE core code. I will never trust someone doing the core work for me again. Starting from scratch.
I was trying to keep the original address of the ValueTree constant. I do not want my plugin to able to swap that original address, but I also wanted to be able to change property values and create non-constant sub ValueTrees& from the original reference. That is why I proposed ValueTree* const. I will do more reading and digging.
I was wrongly thinking there was a little more magic to const ValueTrees& (as light references one can throw around) than there is. I apologize for my original proposal, it does look stupid when I think about it.
Hope I have not wasted too much of your time.
Really appreciated the help.