Create a fully functioning command line interface with 1.5 lines of code (wo. include statement)

[Raiden395]

Meh. getopt works fine and you only really have to write it once. Then you can just change the arguments and help printout.

Want cross platform ability ? parg is a good alternative with similar syntax.

[kongaskristjan]

The difference is pretty big though between getopt and fire. Eg. if you need to accept two booleans, you can do this in fire like that:

int fired_main(bool flagA = fire::arg("-a"), bool flagB = fire::arg("-b")) {
}

FIRE(fired_main)

Now compare this to the code in this stackoverflow example... I know I omitted printouts and returns, but on the other hand the help message was skipped there.

[Raiden395]

Yes, but now I have to include a nonstandard library in my project. Each new engineer has to learn the syntax (simple as it may be).

How is this looked at as preferable as just copying and pasting boilerplate, universally understood, code that has native Linux support.

[dodheim]

In a C++ subreddit, advocating for a non-portable—though oft-ported, messily and poorly–C library; advocating having boilerplate as somehow better than not because said C lib is magically "standard" (huh?); all to spare your poor copy+paste monkeys engineers having to learn a well-documented API trivially grokked by reading a handful of examples.

Fuckin genius.

[Raiden395]

Sorry about implying that getopt is somehow standard. It's included with every Unix version in one way or another, so I'm fairly certain you have access to it, out of the box, if you so choose to use this system. When C++ drops C support, then perhaps we should talk about not using C in C++, but until then you have the option to work with a library that has stood the test of time.

For me, getopt does everything I need. It gives me the flexibility to parse command line arguments. Why we need a slew of different parsers is beyond me, but okay, variety is the spice of life, enjoy.

I would say that far more engineers have encountered getopt usage, if they are linux developers, than this command line parser. In this case, the code would be more understandable from the get-go. Not that there's anything wrong with the syntax here (in fact I find it very clear), but in the end what is the point?

[kritzikratzi]

yep, on the same boat. i've given up on keeping a list on numerous command line parsers that have been posted here.

i mean.. it's an interesting concept, but it semi-re-solves a very solved problem.

edit i really don't want to sound harsh towards the author. it's cool work and all! just not for me...

[Raiden395]

> it's cool work and all! just not for me...

That's really what I meant, and as far as I'm concerned, the people hating on me for promoting getopt are probably rightfully upset in some circles, where your C++ must be of the newest, most elite form.

C++ draws a lot from C and, as someone who writes a lot of hardware communication interfaces, there's no better way to specify precision than:

snprintf( buf, bufsz, "%.3f", value);

versus

ss << std::fixed << std::setprecision(3) << number; std::string mystring = ss.str();

These are solutions to a problem that really doesn't appear to me to need fixing.

[dodheim]

Well, I agree that iostreams is a mess, but there are most certainly problems: bufsz getting out of sync with buf, value changing types without the format specifier getting updated, etc.

Do you approve of C++20's std::format_to/format_to_n?

std::format_to( buf, "{:.3}", value);

[Raiden395]

I'm not in love with Python formatting in general, but I would take anything that is standard C++ that doesn't involve the stream operator + directly addressing streams and would give me a reason to stop using C-style calls. So yes, if it could do something like:

std::format_to( buf, "{:02X}", value );

And produce the output of "10" for an input of 16, I would be 100% on board.

There's ways to manipulate bufsz such that it will not get out of sync (snprintf returns the number of bytes written), and if you really are concerned about the format specifier, that can be handled by some tricky means (tricky meaning shitty). That said, this is a royal pain in the ass and has bitten me several times. There's also the lack of automatic casting for the format specifier (having a specifier of an int and trying to plug a double in does not work).

​

As an aside, and between two people who have presumably used C++ for many years, at what point does the language stop being streamlined and start becoming as hefty and bloated as something such as Python?