Why ValueTree::getPropertyAsValue is not const?

General JUCE discussion
1

Is there a reason why ValueTree::getPropertyAsValue is not const whereas for instance ValueTree::getPropertyPointer is. It’s not possible to pass a ValueTree by const reference to get the Value from it. Would it be dangerous?

2

ValueTree’s are very weird when it comes to constness.

Even if you have a const tree, you can take a non-const copy of it which gives write-access to the same underlying data as the const tree - making it completely redundant to ever have a const value tree.

As to why getPropertyPointer is const and getPropertyAsValue is not - getPropertyPointer returns a const juce::var* meaning the property you’re being given access to can’t be modified, where as the juce::Value returned by getPropertyAsValue is non-const, and so can be used to modify the tree’s property.

2 Likes
3

Oops, i didn’t noticed the const. :face_with_hand_over_mouth:

That’s why i asked. It doesn’t avoid anything and makes the class less usable.

4

sure, but in C++ you can have a const function return pointers/references to mutable data all you want…

struct DataWrapper
{
public:

    void* getData() const { return data; }

private:
    void* data;
};

The pointer can be modified through the return value of that function, but as far as DataWrapper is concerned, the act of calling that function does not mutate anything about the DataWrapper class’s state.

5

Const correcteness is a bit weird nowadays.
You have guidelines to prefer logical (use of mutable) vs physical correcteness.
And others that say that const cares about thread-safety.
It’s pretty hard to handle both.

2 Likes
6

As a workaround ; just make a temporary copy to get my method const using a ValueTree member?

juce::Value foo() const
{
    return juce::ValueTree (tree_).getPropertyAsValue (bar, nullptr);
}
7

You’d probably want to make the return type a const juce::Value too.

8

Why? (In general, I avoid to return const value in order to fully use move semantic.)

9

Fair point, suppose you’d be in the same situation of just being able to make a non-const copy of the value to modify it!

1 Like
10

The ValueTree/Value classes are designed for value semantic (supposed to be passed by value) whereas i still use const reference parameters (to avoid the (worth the cost?) extra RCO increment). This is the origin of the mess. I should probably always pass by value. :thinking:

11

Yeah I always used to pass pretty much any non-primitive types by ref-to-const, but there’s many classes in JUCE where pass-by-value is almost always a better choice.

1 Like