Smart Questions in the Wild: a one-flag lesson from Boost.Program_options

Why “smart questions” matter

Good questions buy you time. They compress context for volunteers, make the problem falsifiable, and often lead you to the answer while writing them. Eric S. Raymond’s How To Ask Questions The Smart Way argues for being precise about environment, showing what you tried, and supplying a minimal, reproducible example (MRE). Those habits aren’t just polite; they’re scalable engineering moves that reduce turnaround time for everyone. See: http://www.catb.org/esr/faqs/smart-questions.html and Stack Overflow’s MRE guidance: https://stackoverflow.com/help/minimal-reproducible-example.

A smart question in the wild (Stack Overflow)

Question (summary). A C++ user wants a simple CLI flag, --flag alone should set a bool to true, without writing --flag=true. Their current Boost.Program_options snippet uses value<bool>(&flag_value) and therefore requires an explicit value. They ask how to keep the option “value-less” yet land in a bool automatically.
Link: https://stackoverflow.com/questions/17853952/how-to-automatically-store-the-value-of-a-simple-flag-into-a-variable

Why it’s smart.

• Clear goal: “no-value flag that sets a boolean.”
• Tiny repro: shows the current value<bool>(&flag_value) usage and the undesired behavior.
• Narrow scope: concrete API usage, not open-ended design therapy.

Outcome. The top answer recommends boost::program_options::bool_switch(), a semantic that refuses explicit values and evaluates to true if present, false if absent. In practice:

#include <boost/program_options.hpp>
namespace po = boost::program_options;

int main(int argc, char** argv) {
  bool flag = false;
  po::options_description desc("opts");
  desc.add_options()
    ("flag", po::bool_switch(&flag), "simple on/off flag"); // --flag => true

  po::variables_map vm;
  po::store(po::parse_command_line(argc, argv, desc), vm);
  po::notify(vm);

  // Run:
  //   app --flag   -> flag == true
  //   app          -> flag == false
}

That’s a textbook “smart” exchange: a precise ask → an immediately actionable answer.

A “not so smart” counter-example (constructed)

Question (bad pattern). Help! My CLI flags don’t work!!!

• No environment (compiler/OS/Boost version), no repro, no “expected vs actual,” just a screenshot of errors.
  Typical outcome. Commenters must first extract basics: “What version?”, “Show a minimal snippet,” “What did you try?” Momentum dies; the thread becomes triage instead of problem-solving.

  The assignment permits a constructed “not smart” example. I mirror common anti-patterns: missing environment, no MRE, and a vague title.

What I learned

1. Lead with an MRE. Make it copy-paste-run; avoid unrelated code/headers.
2. State environment up front. e.g., Ubuntu 22.04, g++ 12, Boost 1.82.
3. Expected vs actual, verbatim. “--flag should set true; currently requires --flag=true.”
4. One question per post. Ask the thing someone can actually answer.
5. Close the loop. Edit the post with root cause and fix for the next reader.

My reusable template

• Title: “Boost.Program_options: make --flag a boolean with no explicit value”
• Context: OS / Compiler / Library versions
• MRE: 10–20 lines max.
• Expected vs actual: one bullet each.
• Attempts: list briefly (and why they fell short).
• Question: one line, answerable (“Which Boost semantic achieves this?”).

AI assistance: I used ChatGPT to outline this essay and polish grammar. The analysis, code, and reflections are mine.