I am making a game, and I just started to think about how I am going to update and render all the sprites on the screen. Should I store all sprites in some type of list (vector or something?) and then call the draw and render method on all those? I'm using SFML and C++ if that helps.
The answer to your question is: yes, you will generally have a render list that you draw during the draw phase of the game loop.
After saying that, I must mention something I am seeing in your post... most notably that you are thinking of the sprites(the graphics representing your game object) as the things in the game(the game object themselves). This is a common misconception early on in game development that eventually leads to all manners of woe and gnashing of teeth. I recommend attempting to think separately in terms of game objects (the things represented in the game work with classes and code) and the sprites (the things that get rendered to the screen to give the player the illusion that the game objects exist). While there is certainly a relationship between these two things, they are not the same.
That depends on how many sprites you have in your world at a given time. If it's in the hundreds or low thousands, you should be fine just using a set, and shoving all sprites into that set. (I'd use a set rather than a list because you will probably need to add and remove sprites frequently.)
If you have hundreds of thousands of sprites in your world, and only a few are visible at once, you have more work. Obviously you don't want to render sprites that aren't in the current view.
In that case, keep things simple. Split up your world into chunks based on X-Y coordinates. Identify which chunks are visible in the current view. Only render sprites from those.
You should be able to identify the visible chunks very quickly -- if you have them in a 2d array and they're of fixed size, just divide the viewport rectangle by the chunk size. Otherwise, keep the list of visible chunks in memory; whenever the viewport moves, look at the neighbors for all the currently visible chunks to see if they're now visible and clear the no-longer-visible ones from your list.
Like moving a picture frame over graph paper.
What is your concern, exactly? Performance, or code beauty?
With C#/XNA, a common, simple, practical solution is to have a sprite manager component, which subscribes to the main class (and thus its update/draw methods get called regularly). You can easily duplicate this code without having the actual component API.
Speaking of components, occasionally the question of making every single instance a component comes up. It seems a reasonable enough idea, and it's always mentioned that you shouldn't do it, but I could never figure out why. Anyway, point is, that's an option too.