"SoundBuffer* s = new SoundBuffer;" freezes the application

[SuperV1234]

class TestClass {
TestClass() {
SoundBuffer* s = new SoundBuffer;
}
}

...

namespace GlobalScope {
TestClass t;
}
 

Having a heap SoundBuffer creation in global scope freezes my application.
By debugging via GDB, the program freezes here:

audioDevice = alcOpenDevice(NULL);

in the file AudioDevice.cpp

https://github.com/SFML/SFML/blob/master/src/SFML/Audio/AudioDevice.cpp

Is this normal? Does OpenAL have to init or something to allow me to declare SoundBuffer* in global scope?

[Laurent]

Yes, this is normal. Don't construct SFML resources at global scope (don't use globals at all if possible!).

[Ruckamongus]

That's odd, I didn't get a crash by throwing this in main():

sf::SoundBuffer* s = new sf::SoundBuffer;

Some people around here REALLY hate that you used "new" by the way, so maybe consider a unique/shared pointer?

At Laurent: Why can't we load resources on the heap? I've written "managers" that allocate things with new all the time and it seems to work. They are pretty simple, and they use a vector. Something like:

std::vector<sf::Whatever*> m_Whatevers;

Are sf::SoundBuffers an exception to this?

Edit: Nevermind. I'm dumb; he initialized on the global scope, not just the heap. The audio system probably doesn't exist at the time he calls "new". Disregard all the above junk.

[SuperV1234]

Alright, thanks for the quick reply.

I used a global because it was convenient to call:
Assets::getSound("mySound").play();

Is there any way I can keep the same syntax using a singleton or a non-global object?

[eXpl0it3r]

Is there any way I can keep the same syntax using a singleton or a non-global object?

Well one should always try to avoid globals, it's in mostly all cases just a bad design, which can quickly lead to fatal errors.
I strongly advise against (mostly) all sorts of globals and specially the singleton-pattern.

But if you really, really, really, really want to, you can have global accessible objects, but you can't initialize them in the global scope. Thus declare the object in the global scope but initialize it for instance in main().

[Ruckamongus]

I do sort of what eXpl0it3r says. For example, I have and init(), spriteManager(), and cleanup() functions. In main it looks like:

int main()
{
     if (!init()) {error and stuff}
     spriteManager.loadFromFile("...");
     ...
     cleanup();
}

Then globally I have:

namespace
{
     cSpriteManager* SpriteManager = nullptr;
}

bool init()
{
     if (SpriteManager == nullptr) SpriteManager = new cSpriteManager;
     return cSpriteManager != nullptr;
}

cSpriteManager& spriteManager() {return *cSpriteManager;}

void cleanup() {if (SpriteManager != nullptr) delete SpriteManager;}
 

There are probably better ways of doing this, but it works if you still want the global-ish syntax.

[Nexus]

I used a global because it was convenient to call:
Assets::getSound("mySound").play();

Can't you have an object that you pass only where you need it? Almost nothing is "just there" and needs to be global, you can mostly limit the scope.

assets.getSound("mySound").play();

Of course, you now need to think how you store and forward assets

But the approach is much better in the end, because you explicitly state the dependencies in your code. On one side, that makes overall design better -- you begin to reflect where you actually need sounds, instead of just using it anywhere. On the other side, you only have a small interface to the sound, which is less error-prone and can be easily maintained and debugged. For a global variable, it's very annoying to track access, it may happen from anywhere. In multithreaded environments, you additionally need to lock, which introduces more error sources and performance problems.

Some people around here REALLY hate that you used "new" by the way, so maybe consider a unique/shared pointer?

What is the reason not to use automatic variables?

sf::SoundBuffer s;