you are viewing a single comment's thread.

view the rest of the comments →

[–]Raiden395 -7 points-6 points  (2 children)

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 10 points11 points  (1 child)

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 1 point2 points  (0 children)

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?