How do you deal with very high numbers of possible options

[NumLock]

Potentially a ridiculous newbie question, but here goes

Just for fun I was running the "man gcc" command on my linux machine. I must admit I had never expected the gcc compiler to have that many options for doing this and that and seemingly everything. So I started thinking what would the gcc code that deals with command-line user input look like. Are there like a thousand if or switch statements in there for every "gcc -xx" option ? How are such programs written in real life, meaning not study projects and such. Is it usual in real life programming to have code with a thousand, two thousand or nine thousand if or switch statements (supposing there are nine thousand possibilities to process), or are such problems dealt with in other ways?

I am just curious, but if anyone has any ideas, I would be happy to hear them

[Salem]

Well since gcc is open source, you could (in theory) answer your own question.

[nonoob]

Thousands? Maybe hundred. But I haven't looked. Sure, programs may have dozens of switches allowable. It's probably implemented as whole bunch of if statements or personally I'd put the choices in an array and look them up as they are encountered using standard library binary search function.

[iMalc]

Not every switch applies everywhere in the code. E.g. if it's deciding whether or not to ouput a specific warning to the user then it isn't going to care what the optimisation settings are to make the call.
Depending on what the code is doing, anywhere from say 1 to 6 different options might need to be taken into account, and more often it's going to be the lower number.

[anduril462]

gcc is actually a fairly complicated beast compared to your "average" command line tool. It has a preprocessor, compiler proper, and linker. Some options only apply to one of those pieces, some to two or all 3. It supports the C89 and (most of) the C99 standards, and there are options to tell it what the code it's compiling should conform. There are options to allow or disallow each individual extension to the C language and options to individually control each potential warning/error and any of a huge number of optimizations. It also supports multiple target architectures (Intel, Motorola, etc), and there are options specific to each possibility there. There's probably a whole bunch more I didn't even cover.

I would not say that gcc is the best place to see "real world" usage of command line options due to it's complexity. Something a little simpler like the "ls" command might be a good place to start. Often, for such programs, the options are parsed, and some sort of configuration struct/object is populated with the values, along with perhaps relevant environment variables and data from .ini files, etc. Also, the option parser may enforce any rules about which options must or must not be used together. For example, asking for a directory listing in both single-column and wide format doesn't make sense, so something must be done. GNU ls just goes with the last one, but they could have decided to print a usage message and error out.

In practice, they will probably use library functions like getopt() and getopt_long() in a loop, along with a switch statement or long sequence of if-else if statements, but usually the number of options is much less than 100, maybe a few dozen at the most. If you actually had to switch between hundreds or thousands of things, you would probably want to handle it in a manner like nonoob suggested, using a large, statically defined array. You could, also, at a small cost to performance, break the options up into categories and parse the option list multiple times. The first time through, you might look for general options including which phase of your program to run, then, go run the option parsing routine for just that phase. That will keep things more manageable.

[CommonTater]

Potentially a ridiculous newbie question, but here goes

Just for fun I was running the "man gcc" command on my linux machine. I must admit I had never expected the gcc compiler to have that many options for doing this and that and seemingly everything. So I started thinking what would the gcc code that deals with command-line user input look like. Are there like a thousand if or switch statements in there for every "gcc -xx" option ? How are such programs written in real life, meaning not study projects and such. Is it usual in real life programming to have code with a thousand, two thousand or nine thousand if or switch statements (supposing there are nine thousand possibilities to process), or are such problems dealt with in other ways?

I am just curious, but if anyone has any ideas, I would be happy to hear them

As the others have already pointed out (indirectly) comparing something as complex as GCC to your average user program is decidedly not a good idea. Compilers tend to live in and come from a world all their own.

Yes there are user programs (esp. for Windows GUI mode) that can and do have hundreds or even thousands of settings. For the most part these are not passed as command line arguments. Instead they are stored in initialization (.INI) files or the system registry (or linux equivalent thereof) and are loaded into structs, arrays, and/or bitfields for runtime use. It is very common to see statements like...

if (range < 30 && setting.safety == 1)
  DisableCannon();

scattered all through source code. There's not much to do with an option once it's loaded so most programmers tend to deal with them as they encounter them.

[NumLock]

Thanks everyone !!

I think I am beginning to understand the idea here

[grumpy]

gcc is actually a fairly complicated beast compared to your "average" command line tool. It has a preprocessor, compiler proper, and linker.

The actual architecture (conceptual organisation) of gcc is actually not all that complex. gcc itself (the main program users actually pass parameters and switches to) is a relatively simple driver program. All it does is examine and filter command line parameters (including switches), make decisions about what other programs (preprocessor, assembler, compiler(s), back end optimiser, linker, etc) to execute and then invokes each program with an appropriate set of parameters.

Some of the programs invoked by the gcc driver program are fairly complex beasts in their own right, but others are relatively simple. Put them together, however, and the whole system is more complex than the parts - hence the gcc driver itself appears to accept a bewildering array of command line options that change all sorts of things.