This is my final listing for the small example program in the prior post. I present it again and comment on the changes made and why they were made.

#include <exception>#include <iostream>#include <boost/program_options.hpp>using std::cout;using std::cerr;using std::exception;using boost::program_options::options_description;using boost::program_options::value;using boost::program_options::variables_map;using boost::program_options::store;using boost::program_options::parse_command_line;using boost::program_options::notify;int main(int argc, char *argv[]) {options_description options("Options");options.add_options()("help", "Help using application.")("compression", value<int>(), "Set compression level to integer value");try {variables_map varmap;store(parse_command_line(argc, argv, options), varmap);notify(varmap);if (varmap.empty() or varmap.count("help")) {cout << options << "\n";}if (varmap.count("compression")) {cout << "Compression level set to "<< varmap["compression"].as<int>;() << "\n";}}catch (exception &amp;ex) {cerr << "Error: " << ex.what() << "\n";cerr << "\n" << options << "\n";return -1;}return 0;}

The using Conundrum

When C++ namespaces were introduced, they also provided a way to avoid having to preface every namespace element with the namespace name, such as std::cout. That feature was the using namespace declaration, such as using namespace std. My problem with that is it completely obfuscates those function that are part of the std namespace, which can be a real pain when you’re trying to read code you’re not familiar with, or worse, your code that you haven’t touched in a while under stressful circumstances. Of course if you don’t use using namespace std then you’re going to put the namespace declaration in front of every standard library element, wherever they’re being used. I was pleasantly surprised with the using variant, where the namespace can be combined with the element, allowing you to just use the element in the body of you code. That’s what I did in lines 5-13 highlighted above.

Two good things have occurred. First, I have a list of every element I’m using in all the namespaced libraries at the top of the code in a list I can quickly read. Second, I can use the bare elements within the code body, producing cleaner code, more quickly. It might not be perfect, but it’s better that the first two original options, and it’s a coding standard I think I’m going to stick with from now on.

The End of Line Conundrum

I have seen quite a bit of C++ code these days that uses "\n" at the end of a line, instead of std::endl. For example:

std::cout << options << "\n";

versus

std::cout << options << std::endl;

I haven’t read anywhere that might explain why it appears std::endl has fallen out of favor as it were. I personally would rather use the simpler form, and from this point forward, I will just as I have in the listing at the top of this post.

Wrap Up

I removed that last else statement because it made no sense to have it. I then broke up the remain if statements into two smaller conditional blocks, which makes it easier to read. The entire program is organized in a logical fashion from declarations to initializations to work sections, and the try/catch block handles all the exceptions you can throw at it. It might not be perfect, but it’s good enough for me. Bitter experience has taught me over the decades that perfect is always the enemy good.