It seems like your main question is how GUIs and CLIs can exist together at the same time, such as the Windows command console (cmd.exe).
It's actually not as complicated as you might think. First, remember that even a GUI needs to be able to render text, so you can read filenames, labels on controls, or work with text inside of programs. It does this by having font files that contain descriptions of how to turn various characters into glyphs (shapes) on-screen or in a printout.
Once you understand that basic principle, the answer is obvious: you can make a console program on top of a GUI by having an emulation layer that renders the text the way a CLI would and a font file that looks like console text. (Note: I'm not actually claiming that that's the way Windows does it. I don't know how it works under the hood. But it could easily be done that way.)
As for the second part of your question, as to how graphics get rendered, yes, there's a special memory location somewhere that holds pixel data. That's called a frame buffer. Back in the old days, you could get direct access to the frame buffer and play around with its pixels directly. Nowadays, that's highly discouraged if not impossible, for various reasons. Instead, you go through higher-level graphic-drawing APIs, where you describe to the system what you want to do and it takes care of the details.
This has several advantages. First, it means that you don't need to know where the framebuffer is in memory or how exactly its data is formatted. Second, and closely related to the first point, different video card manufacturers can set up their framebuffers in different ways, and you don't need to know how to write specific graphics code for each version. You let the graphics APIs take care of that. And third, (and closely related to the second point,) it means that things can change in the future without breaking existing code.
For example, there was a major change in the way Windows handles forms ("windows") when they introduced Vista, that you probably never noticed unless you do graphics programming. It used to be that every form got drawn directly to the screen. This meant, among other things, that if you dragged a second form over a visible form and then away again, the form on the bottom would have to repaint itself because that image data was lost.
But Vista introduced a compositing window manager, which basically means that each form gets its own virtual framebuffer somewhere in memory, and it just draws everything to the screen based on position and Z-order. Now you can drag one form in front of another all you want and it won't invalidate the other form's pixel data; forms only need to be repainted when their own content changes. And they were able to implement that and make it work just fine on existing programs because the existing programs all use predefined drawing APIs.
Your question is quite subjective (and might get closed for that), because there is no universally preferred practice when it comes to the use of in-class function definitions in C++.
One project that has a lot of large, header-only, libraries is Boost, and they don't seem to have a defined policy where the body of a method should go.
My personal preference when using a third-party library is (in order of preference)
- To have separate, comprehensive, searchable API documentation. This documentation could be generated from the source (for example, with a tool like Doxygen), but I should not have to open the source files myself to read the documentation, or
- Well-commented, well-organised class definitions, without the 'clutter' of in-class function bodies. Those implementation details can either come in the same file after the class(es), or in a separate file, or
- Well-commented, well-organised class definitions with in-class function bodies.
Best Answer
SDL is an excellent library with good Haskell bindings—and related libraries for images, audio, and text—for which enough tutorials exist to get you off the ground; being rather low-level, it requires a bit of care to keep things pretty and functional, but in my experience SDL and Haskell make a superb combination.