Don't Overlook Efficient C/C++ Cmd Line Processing 219
An anonymous reader writes "Command-line processing is historically one of the most ignored areas in software development. Just about any relatively complicated software has dozens of available command-line options. The GNU tool gperf is a "perfect" hash function that, for a given set of user-provided strings, generates C/C++ code for a hash table, a hash function, and a lookup function. This article provides a reference for a good discussion on how to use gperf for effective command-line processing in your C/C++ code."
Re:Speed in options parsing? (Score:5, Informative)
If you don't like the nasty nested ifs, make the keys in your dictionary the command line options and the values delegates, then just loop through your list of options passed on the command-line, invoking the delegate as appropriate. Eliminates the if, there are no switch statements either, and each of your command line arguments is now handled by a function dedicated to it, bringing all of the benefits of compartmentalizing your code rather than stringing it out in a huge processing function.
Re:Speed in options parsing? (Score:3, Informative)
-Peter
Broken handling of vtables in linkers (Score:5, Informative)
Equivalent Python (Score:0, Informative)
def function_1 (...):
functions = {'a': function_1,
'b': function_2,
'c': self.method_1,
func = functions[value]
if __name__ == '__main__':
args = sys.argv[1:]
func(args)
# The variable "functions" is set to a Python dictionary.
# Built-in dictionaries already use fast hash-table lookups.
It is if the linker complains about not finding it (Score:5, Informative)
Re:C++ I get (Score:5, Informative)
You are wrong about 3):
Source: http://archive.gamespy.com/e32002/pc/carmack/ [gamespy.com]
And 4) as well:
Source: http://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/G_002b _002b-and-GCC.html [gnu.org]
devkitARM (Score:3, Informative)
only relevent to static linking (Score:5, Informative)
Again, to be clear, dynamically linking with the c++ standard library is not going to increase your executable size. Please don't try to roll your own code that exists in the standard library. It is a real nuisance when people do that.
I should qualify that by saying that template instantiations do (of course) increase executable size, but that they do so no more than if you had rolled your own.
Character encoding conversion (Score:3, Informative)
Re:C++ I get (Score:4, Informative)
Of course C++ exceptions are what I meant. What else would I mean when using the word "exceptions" in this context?
And yes, C++ exceptions can be expressed in C. After all, C is a glorified assembler and the resulting code from C++ translation is assembler as well. It all depends in the level of abstraction at which write the C code is written and on the amount of uglyness/inefficiency you're willing to take on board (and also the trade-off between both of the latter). But that's not the point. The point of this thread is that nowadays it makes no sense to make use of this capability in a C++ compiler. Especially not when considering that a user of a C++ compiler wants more than just a compiler. He also wants a debugger that is able to meaningfully link up the binary and the original C++ source. If you're a C++ compiler vendor, using C as an IL does nothing but complicate your own life. Twice.Re:And the standard says... (Score:2, Informative)
Oh, and as far as I know, those functions aren't in VC++, which is what a hefty chunk of C/C++ development is done on.
Boost.Program_Options? (Score:2, Informative)
What about Boost.Program_Options [boost.org]? I thought I'd see a post on it here somewhere, but not one person has mentioned it (yet).
A few months ago, I was looking around for a C++ library for parsing command line options. I checked out get_opt and I thought that there must be something that uses std::string instead of char*. After some googling, I found Boost.Program_Options seemed to be exactly what I was looking for. It supports long and short options (-s,--short) and I was able to start using it quite easily after looking at the tutorials.
Re:C++ I get (Score:4, Informative)
The main problem (but not the only one) is called "object destructors". You have to make sure they are called. All of them, and in the correct order, at all the nested scopes of execution you are in when the exception occurs. And you need to make sure not to call them on any object not yet constructed (always remember that constructors can throw exceptions too) and never to call a destructor twice (I've seen this kind of bug multiple times in multiple compilers). And then there is the fun of exceptions thrown by destructors, not to mention the possibility that it all happens in the middle of constructing or destructing an array of objects.
All that is why setjmp()/longjmp(), also known as C's non-local goto, don't cut it, which in turn means that you need to complicate function return mechanisms. And just when you think you got that problem sorted out, you need to be aware that C++ functions can call (library) C functions that were never compiled to even know about exceptions but that in turn can call C++ functions that may again throw an exception. The entire construction needs to be able to handle this.
As I wrote in an other post [slashdot.org] in this thread, it can be done. But it is not easy. Note that the entire object destructor issue also applies within a single scope, which is why life is not as easy as replacing every "throw" statement by "goto end;".
Re:All the world is not a PC (Score:2, Informative)
Re:It is if the linker complains about not finding (Score:3, Informative)
Re:It is if the linker complains about not finding (Score:2, Informative)
I love FreeBSD. (I once changed the motherboard, rebooted, went, "Oh.. shit," and proceeded to login. All drivers are compiled as modules, in less time than my lean linux kernel.
I sidestepped the license issue, stripped out extraneous header files, changed a couple referenced to _getprogname() (either to static string "" or to a global var, as it is in libc), read the man page to figure out how to use it and had a short-form option parser in.. probably under an hour.
Some things you have to code. For everything else, the Regents of the University of California has done it for you.
Re:It is if the linker complains about not finding (Score:3, Informative)
Again, on the off chance that this helps anyone reading this pitifully long and silly thread: it is trivial to make getopt work on Win32, just like it was trivial to make strsep work on Linux when it only had strtok. I object to the argument that "portability" has anything whatsoever to do with whether you'd use getopt to parse arguments.
Like most of the other comments on this post, I find the idea of using gperf for "high performance argument parsing" superfluous and convoluted. In fact, I find the idea of a general-purpose perfect hash tool a bit superfluous as well; gperf languishes in obscurity for a reason.
Re:Speed in options parsing? (Score:4, Informative)
How about "macro"? [jhu.edu]