I figured out my constructor problem. Apparently:
#define SFML_STATIC
is not equivalent to setting it in the preprocessor definitions, as the internet said.
Anyways, I have in fact given you a description of why I want const removed. Take a look at my AddSample method from before and see if you can get a working example of that (actually working) with const Chunk. You won't be able to; then you'll tell me that it's none of my business to write code intuitively like that and that I should just create a Chunk last minute. My response to that is that
I want to use Chunk for the same reasons that you did in SFML! Instead, I had to make my own stupid class:
class ManagedSoundThing
{
public:
short* data;
unsigned int numberOfSamples;
~ManagedSoundThing()
{
delete [] data;
}
};
Note that I have just shown you, in this code, yet another reason why it should not be const. Not only does my class store a short* and unsigned int at the same time, but if I were able to use a Chunk in it (properly), I would not be able to call "delete [] chunk.samples;" on it.
As I said from the beginning, this may seem like a minor problem to you, but it simply doesn't make sense to have inconsistent code. Why create a package for data that only you can use? The real life equivalent to this would be something like me having to mail you a keyboard and a mouse in separate packages even though I could have sent them both in one package - and you yourself are going to use your own combined package, but you won't let me use it.
Also, this has further implications for other code in SFML, which is also what I was getting at. A software library should have the goal of being as usable as possible in as many ways as possible. Unnecessary restrictions are the last thing you want to have.
Show Posts