Custom SoundStream

[leiradel]

I'd love if SFML had more thread primitives, conditions and semaphores are really *not* advanced features, and SFML should really provide them in a cross-platform way.

What's wrong with using the C++ standard library for that?

Compiler support for them is still a problem, and I don't want to bring in boost as a dependency. But then again, it's hard to find a thread library that goes beyond the *nix/Windows world, so I might just unroll my own code for conditions and semaphores.

[Laurent]

Compiler support for them is still a problem

Really? What compiler(s) do you use? And what problems do you have?

[leiradel]

Compiler support for them is still a problem

Really? What compiler(s) do you use? And what problems do you have?

Many compilers for old consoles don't have good c/c++ stdlib support, and most don't even know what C++11 is. I don't think I'll be targeting them for this particular project though.

Even then I think I'll write some wrappers over pthreads and the Windows API. What do current Macs use? pthreads?

[eXpl0it3r]

You are aware that std::thread is juat doing that as well?

Anyways, this is getting offtopic. You might want to ask such questions on StackOverflow or similar.

[Hapax]

The thing I dislike about SFML is its use of the standard library. I tried to use SDL2 before going to SFML because of that, but SDL2 don't seem to allow me to render the audio (it imposes a power-of-two audio buffer and libretro cores can send audio frames of any length.)

C++ > C
therefore:
SFML > SDL
 

I'm scared of what you can't see, like how it manages memory.

You might want to start with writing your own OS then.

[Jesper Juhl]

Compiler support for them is still a problem, and I don't want to bring in boost as a dependency. But then again, it's hard to find a thread library that goes beyond the *nix/Windows world, so I might just unroll my own code for conditions and semaphores.

Gcc has had reasonable C++11 support since ~4.7, clang since ~3.4 and visual studio since v2013 and even Intels compiler and IBMs are not too far behind the game. Good C++11 support has been available on most platforms with multiple compilers for years. There's no excuse for not moving to it (IMHO) - especially since it's such a huge improvement over C++98.
And your comments about being scared about the mem allocations etc that you cannot see; in my experience you should be more scared about the manual memory management code you write yourself. Chances are good that the C++ standard library got it right and you'll get it wrong.

[leiradel]

You might want to start with writing your own OS then.

Nah, VirtualAlloc and mmap are your friends, it's possible to write/use nice memory allocators on top of them.

[Nexus]

Nah, VirtualAlloc and mmap are your friends, it's possible to write/use nice memory allocators on top of them.

I don't think it makes sense to reinvent wheels here, especially because a self-written allocator will almost definitely be less efficient than existing solutions. There are heavily optimized allocators for all kinds of scenarios, I would go with the "use" option rather than "write"