argv[] comparison

[Jon Harrop]

What is the safest way to make an argv[] comparison? The code below
works.

If you use a language with pattern matching and type inference, like OCaml
or F#, then you can just write:

let () = match Sys.argv with
| [|_; test|] when test = "NKDT" ->
printf "\nComparison is true. Have program do something.\n"
| _ ->
printf "\nComparison is false. Have program do something else.\n"

The catchall pattern handles everything else safely and simply.

 

[peter koch]

What is the safest way to make an argv[] comparison? The code below
works.

[snipped off-topic content]
My advice to you, Jon, is to get a life and refrain from spamming
comp.lang.c++ with off-topic content.

/Peter

 

[Lionel B]

* Lionel B:

I'm not sure that the effect of the OP's code was intentional,and the
question was how to deal with argv, not how to replicate the effect of
the original code (still I posted such replication else-thread).

To be clear: your code throws when no args are supplied. Surely it is
very common indeed for a program to be validly runable with or without
args - and which will do different things accordingly. Again, I've no
reason to believe the OP either did or didn't intend this and I've no
inclination to second-guess them.

Anyway, it's silly and just plain argumentative to object to getting too
generally useful code.

That clearly wasn't my objection; this was (snipped quote restored):

Anyway, this is all pretty trivial.

 

[James Kanze]

std::vector is part of the standard.
std::string is part of the standard.

What about these is complex ?

There exists a minimum complexity. employing char * is usually bad news
and is prone to far more subtle complexity that is exemplified by the
OP's question.

Alf's code does more like what you would expect.

I think part of the point of Alf's code is that significant
parts of it will eventually end up in a library. For a quicky,
just using something like:

std::vector< std::string > args( argv + 1, argv + argc ) ;

is probably sufficient. But real programs have a tendancy to
grow, to acquire options, etc. And it's a lot easier to adopt
Alf's solution to these evolutions than something as primitive
as the above.

 

[Alf P. Steinbach]

* James Kanze:

I think part of the point of Alf's code is that significant
parts of it will eventually end up in a library. For a quicky,
just using something like:

std::vector< std::string > args( argv + 1, argv + argc ) ;

is probably sufficient. But real programs have a tendancy to
grow, to acquire options, etc. And it's a lot easier to adopt
Alf's solution to these evolutions than something as primitive
as the above.

Well yes, right on. If I weren't so lazy I'd add it as a project
template in Visual Studio, or have it as a file I could copy. But I
just type it in manucally whenever I need a small tool for something
(perhaps I'm not lazy enough -- this bears thinking about!). Thought
I should share it, and I couldn't imagine that it would generate any
debate. And as mentioned, I think similar code is given in Accelerated
C++, presumably for the same reason: a simple, reusable skeleton for a
small toy program that needs to handle main arguments.

 

[*PaN!*]

Well yes, right on. If I weren't so lazy I'd add it as a project template
in Visual Studio, or have it as a file I could copy. But I just type it
in manucally whenever I need a small tool for something (perhaps I'm not
lazy enough -- this bears thinking about!). Thought I should share it,
and I couldn't imagine that it would generate any debate. And as
mentioned, I think similar code is given in Accelerated C++, presumably
for the same reason: a simple, reusable skeleton for a small toy program
that needs to handle main arguments.

Just a question about your code (which I appreciated as a good example).

Why did you use:

(1)
arguments.size() > 1
|| throwX( "usage: myprog ARG1" );

and not a plain if as in

(2)
if (aruments.size() <= 1) {
throwX( "usage: myprog ARG1" );
}

I've never seen this use, but of course I can understand it (even if I
haven't found it very readable at first sight).
Is (1) written that way because you wanted the condition (arguments.size() >
1) to have the form of a precondition?

 

[Alf P. Steinbach]

* *PaN!*:

Just a question about your code (which I appreciated as a good example).

Why did you use:

(1)
arguments.size() > 1
|| throwX( "usage: myprog ARG1" );

and not a plain if as in

(2)
if (aruments.size() <= 1) {
throwX( "usage: myprog ARG1" );
}

I've never seen this use, but of course I can understand it (even if I
haven't found it very readable at first sight).
Is (1) written that way because you wanted the condition (arguments.size() >
1) to have the form of a precondition?

Yes, and it's shorter, and it's a very common convention in languages
like Perl (except instead of throwX it's usually "die"). But it's a bit
unconventional. So I would not use it in code that had to maintained by
others not familiar with the idiom.

 

[Zeppe]

* *PaN!*:

Yes, and it's shorter, and it's a very common convention in languages
like Perl (except instead of throwX it's usually "die"). But it's a bit
unconventional. So I would not use it in code that had to maintained by
others not familiar with the idiom.

I have to admit that I don't like it that much in C++. I think the if
statement is much more readable. In perl, the readability is
non-existent anyway Probably the statement

do_something or die "with an error";

is one of the most readable

Regards,

Zeppe

 

[*PaN!*]

[... preconditions with "cond || throw"...]

I would not use it in code that had to maintained by others not familiar
with the idiom.

Indeed, that was exactly my problem here =)
I was thinking about switching from the actual macro-based approach in a
specific project with other 3 developers, who have a not-too-deep knowledge
of C++.
It's probably a bad idea =)

Thank you,
Marco