This question already has an answer here:
- Alternatives to the singleton pattern 9 answers
Unlike many libraries SDL and OpenGL are designed to provide global resources; you can access them at any time from any class. There are justifications for this: They are written in C, meant to be readily cross-platform and designed to be fast.
They are not object oriented though, and global state is supposed to be a Very Bad Idea normally. It adds dramatically to the number of inputs to every function in your code.
Let's say you're working in C++ or some other object oriented language with one of these libraries. You know what functionality you need. At that point isn't it a good idea to encapsulate what you need into X and Y classes and say "every time you need to work with this library, use X and Y"?
For example, with SDL, it seems like a good idea to have a class which calls SDL_Init in the constructor and cleans everything up in the destructor. This manager class only allows you to create windows and renderers while SDL is active.
A good cause for a singleton perhaps? I'd rather not. The Google Testing Blog gives a good example of a case against singletons: http://googletesting.blogspot.co.uk/2008/08/root-cause-of-singletons.html
So really my questions are 1) if encapsulating part of a library is a good idea or pure madness and 2) how to approach managing global resources without singletons.
EDIT: Paul K's answer here gives a really good, concise introduction to dependency injection, which removes the need for singletons. However it's still unclear how to deal with the state which is unfortunately made global by a library such as OpenGL or SDL. The extensive global state provided by these libraries can't easily be passed by reference unless it is collected together and managed by a wrapper class. Even once this is done the client can still use the library directly.