I think you guys are going over the top with the answer, unless I am mistaken the basic question was wether or not a vector needs to be cleared before exiting the application it was used in, not really a question about scope.

The vector is automatically released because it goes out of scope. It doesn't matter that it happens to be the end of the main function. We mention scope because it is exactly that what is causing it to be automatically released.

I am curious as well about that, I often wonder if my code is leaving junk in the systems memory after a coding session... initially I assumed when the application ended all its resources was freed, but when I starting getting into SDL the tutorials I was following insisted in freeing the surfaces and quiting SDL before the application finished.

So basically your question is: is it all right to write sloppy and bad code that doesn't automatically manage object lifetimes and leak resources just because you can? No, it is not all right to do that in my opinion. Releasing resources at the end of the program is no different that releasing resources at any other point in your program when the resources aren't needed anymore. If you have properly designed resource handlers, then exiting the program is no different than any other situation where a resource shall be released.

Would you ask whether you need to release the resources when you, say, leave a level the user has just played in your game? I assure you, you would not leave those resources hanging around unreferenced within your program. The same solution that automatically handles the release of those resources should handle your program exit as well.

C++ offers one set of guarantees about cleanup when a process terminates normally and the client operating system may or may not offer another set of guarantees on top of that. On modern operating systems, the OS will do its best to clean up any resources it knows about; however, there are some resources that, either by accident or design, the OS will not free. For example, on Windows, ATOMs created by the GlobalAddAtom() function are explicitly noted to not be freed by application exit. Another fun one is that handles to a Windows semaphore are closed automatically by application exit; however, semaphore count is not affected by application exit, so other processes that are waiting on the semaphore to be signaled may wait forever on it.