Thank you guys for the feedback.
Although Salem brings some valid technical points, which Ill touch later, it seems most of the issues you raise pertain to clarity and readability. After much deliberation, I have to concede on this point.
To me, the approach is no more complicated than the established way, and it has a certain appeal from an organizational point of view. Yet this is exactly the problem; one does not write code for oneself, but for others to read. Similarly, one writes a program for others to use, and if a design choice makes this goal harder, then it is the wrong choice.
This reminds me of a guy I knew who refused to indent his code. He would write huge squared blocks like:
Code:
var = functioncall();
if (var == value)
do something
else dosomethingother()
otherfunctioncall()
which he claimed was aesthetically pleasing and helped him understand his code better.
I felt silly thinking Im sort of doing the same here.
Salem,
The idea is the program arguments would come first, then the options and anything after would be option arguments; the order in which they appear indicating the option they belong to.
Code:
program [program arguments] -option1 -option2 -option3 optarg1 optarg2 optarg3
If we want to omit option2s argument, we would need to change the position:
Code:
program [program arguments] -option1 -option3 -option2 optarg1 optarg3
But as you notice, things can get unruly when the number of options increases, even I have to admit that.
Your approach is actually harder to use in the case of creating a program to drive your program.Instead of incrementally adding
flag value flag value to an argv, I would have to maintain a separate list of values to append to argv, once I'd finished adding flags.
Very valid point.
I'm curious as to how you handle filenames which begin with a minus.
I actually hadnt thought of that, why would anyone put minus at the beginning of a file is beyond me, but it is a legal character so I guess it could happen.