I've tried both allegro and sdl for a week each. I cant find many advanced allegro tutorials and I eventually want to move onto 3-d programming. What I really want is to be able to find a library that I can stick with til the end, no matter how hard or easy it is to learn.
Does anyone have suggestions on what I can use?

Also here is a tutorial I have used and it is great for starting out in SFML. It shows you how you can set up SFML and any other library in Visual Studios C++. It also shows you how to make a pong game with SFML.

SFML: Great for Graphics, Input, and Sound. It makes manipulating images extremely easy because of built in functionality (Unlike Allegro or SDL).
SDL: Functional programming, Great for input and has a large community
Allegro: Slowly moving to Object Oriented Programming (Like SFML). It's fallen out of popularity but is a great library.

For 3d you can either use:
DirectX: For windows platform only.
OpenGL: Android, Windows, and I believe Mac?
Ogre3d: A rendering engine. I don't like it. There's a lot of good stuff, however it's slow (From what I've heard). I wouldn't use it, however I recommend you try it out and see if you like it.

Overall, you should try out all the options available for a little bit and see what you like. No matter which one you choose, they all have the same end resolution. (If you're going to be dealing with OpenGL however, use SDL, it's far better than SFML or Allegro currently)

Well, you have to choose if you want to use the low-level 3D library (OpenGL, Direct3D) which only handle things like drawing triangles, skinning etc. and program the advanced functionality (loading models, skeletal animation, et cetera). It takes a LONG TIME to comprehend (I would say 2-3 years at least to move to the current state of art technology), so be prepared. The upside is that you can make unusual games (e. g. space simulators) – the library won't limit you much – and you can fine-tune the graphics. Also take note that OpenGL and Direct3D (and drivers for them) are developed by professionals and don't suffer from "opensourceness" – known bugs and missing features not being fixed/added because the developers don't think they are important. The support is also much better because almost every programmer in game programming field knows one of them.

If you use the Direct3D, you can run your game only on Windows (and maybe Wine), so the best windowing library is the Windows API.

If you use OpenGL, you must choose a windowing library:

Windows API (as demonstrated by NeHe) is not recommended to use. You lose your portability and it's messy.

GLUT was a nice library, it has been discontinued by the author, but its fork FreeGLUT looked fine to me.

I personally prefer GLFW, it is a lightweight library, so don't expect much, but it is clean and stable.

SFML is another choice, but I found its documentation lacking and the library kind of new and missing important features. The sprite-manipulation API looks half-done to me at this point.

Allegro and SDL are heavy-weight libraries, having 2D functionality, more helper functions and so on. I would recommend the latter as it has much larger community.

To summarize, if you just want a window created for drawing and input polled, use GLFW or FreeGLUT. If you need more from the library (2D drawing, audio), use SDL.

If you want to use graphics engines (Ogre3D, Irrlicht), you will have to cope with incomplete documentation, some bugs and inflexibility. But you will learn it (and make a game with it) much sooner than a 3D library. I used only Ogre3D and I have to say that it is a rapid and sufficient tool to make a game with. You can always modify it (MIT license). Some people say that Irrlicht is good, but I don't know.

In the end, the thing that matters is whether you want to make an engine or a game.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.