SFML community forums
Help => Audio => Topic started by: deadalnix on December 02, 2011, 11:56:18 pm
-
I'm not sure it make that much sense to subclass this, as long as all useful things are private.
If it is not meant to be subclassed, callback should be declared non virtuals.
If it is meant to be subclassed, internal buffer should be protected and/or callbacks too (to allow subclasses to recall parent's callback).
-
Why would you subclass it? If you want to implement your own sound recorder, inherit from sf::SoundRecorder directly.
-
That was what I thought. Even made private virtual function can still be redefined in subclasses. So I guess we should make callback non virtual in this class.
-
It is virtual, wether I use the 'virtual' keyword or not, because it is declared virtual in the base class. You can't stop a virtual function from being virtual.
-
Yes, but you can prevent someone to try to redefine it in subclasses.
-
How? Like I said, I can't. And anyway, if someone wants to do that for a very good reason, then... he can do it, SFML won't blow up ;)
-
You can rediefine virtual function in subclasses even if they are private. You cannot call them, but can define them.
Well it is a strangeness, but it is confusing, not dangerous.
-
You cannot call them
Which is good, if they are not meant to be called.
But anyway, what do you suggest?
-
I suggest one of thoses :
1/ Make mySamples protected, so callback function can use it when overloaded. With such a decision, SoundBufferRecorder can be subclassed in a usefull way.
Callback function could be delared protected too if we consider that the subclass can call SoundBufferRecorder's callback.
2/ Make callback's function non virtual. This will not change anything at runtime, because thay are called from SoundRecorder, so the function call will be virtual anyway.
But it makes it clear that the class is not meant to be overriden.
Let's explain what make me start this topic. I did look at the SoundBufferRecorder class and saw that it has some virtual function. So I wondered what I could do to subclass SoundBufferRecorder in a usefull way. And nothing that couldn't be done with SoundRecorder directly, because every additions in SoundBufferRecorder are private. At the end, this virtual stuff isn't usefull and can confuse a person reading the header file.
-
I have a different point of view. I always write 'virtual' in front of virtual functions, whether it makes sense or not in the derived class, because they are virtual.
If you can't find anything useful to do with SoundBufferRecorder as a base class, then don't use it. It's not meant to be used like this. The tutorial and documentation make it clear enough I think.
It will only confuse people like you, that try to derive SoundBufferRecorder for fun. People who have an actual problem to solve will most likely not get blocked by this "issue".