##Exiting from programs Exceptions aren't the only way. There are times when cerr/exit are acceptable, but personally, I almost never do that. The answer to your question is kind of long.
I tend to think like a library developer (i.e., code reuse is always on my mind). If your function calls exit(), that makes it impossible to use in other contexts that might not care about whatever error condition is causing you to want to exit. "But what about contexts where the error is truly unrecoverable?" In those cases, exit() inhibits debugging, use abort() instead. This should be reserved for truly egregious errors--those which you'll want to get a core dump for (exit won't give you a core, abort can).
This commit wasn't so much about exit() or preferring exceptions to checking return values, but rather eliminating return values from functions that have no defined failure path. If a function always returns true, then its return value has no meaning. Returning true/false when there is a defined failure path is a perfectly valid thing to do.
side note: cmdline parsing code that uses getopt is an example of something where std::exit(1) doesn't bother me that much (you probably don't mean std::exit(-1)--you'll get an exit status of 255). I still don't do it myself (I prefer boost::program_options to getopt/getopt_long, and I throw), but options parsing code is less likely to be reusable than most other things anyhow.
exit() is also bad for testability. Although my preferred unit test framework (gtest) supports "death tests" (tests that assert that a program exits), it's much more convenient and portable to test that an exception is thrown.
##Constructor/Destructor cleanup My general rule is: use initializer lists except when you can't. Also, don't write empty constructors / destructors [unless the destructor actually needs to be virtual]. See here for an explanation:
http://en.cppreference.com/w/cpp/language/rule_of_three
The gist is: the compiler is required to generate these for you in the relevant cases.
Also, class, struct, enum, and union definitions need a trailing semicolon. Function definitions do not.
The return type of std::vector::size is not int it is almost certainly std::size_t. Technically, it is std::vector::size_type. This may be relevant to your interests: