Hey, is there a special reason these virtual methods are not just declared const?
AudioFile AudioClipBase::getPlaybackFile()
juce::String getName()
bool Clip::usesSourceFile()
Seems like they could/should be?
I took a quick look at this, getName() can be const, but the others can’t because the audio clip needs to build it’s hash internally, that needs to build and cache the segment list. Maybe the segment list can become mutable, bit it will require some refactoring to work.
1 Like
Ah, I see. Just saw the updates on develop - thanks!
This is more of a philosophical debate… There’s a sting argument that virtual functions shouldn’t be const because you don’t know how derived classes will be implemented and if they can conform to the constness.
What’s the situation where this is a problem? There might be a better way around it.
2 Likes
I thought that might be the reason.
I don’t think I’ve ever had a problem in terms of not being able to do what I wanted to do. It’s more in terms not being able to express the intention of something not being supposed to make changes. It just feels wrong that I can’t retrieve the name of a plugin or clip in a const way.
I’ve been bumping into this a couple of times, being forced to make some functions or arguments non-const even though they’re getters that don’t change anything.
This sums up the issue I have with const in general. It is contagious. If you have the habit of “const correctness” in your code, it inevitably becomes a headache dealing with code which doesn’t have such correctness. So everything has to be perfect everywhere or it causes more trouble than it’s worth.
I think it’s a better use of time to use it when it’s not creating more problems than it’s solving. To be honest I very rarely witness it solving any real problem and run into annoyances with it all the time.
My opinion
4 Likes
I recently bumped into this article, might be of interest: `const` all the things? – Arthur O'Dwyer – Stuff mostly about C++
1 Like