argv[] comparison

[kaferro]

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

#include <iostream>
#include <string>

using namespace std;

int main(int argc, char *argv[])
{
string test;

if(argc>1)
test = argv[1];

if(test=="NKDT" )
cout << "\nComparis on is true. Have program do something.\n";
else
cout << "\nComparis on is false. Have program do something else.\n";

return 0;
}

[Jon Harrop]

ka*****@hotmail .com wrote:

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 "\nComparis on is true. Have program do something.\n"
| _ ->
printf "\nComparis on is false. Have program do something else.\n"

The catchall pattern handles everything else safely and simply.

--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/product...ournal/?usenet

[peter koch]

On 22 Maj, 22:11, Jon Harrop <j...@ffconsult ancy.comwrote:

kafe...@hotmail .com wrote:

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]

On Tue, 22 May 2007 18:39:43 +0200, Alf P. Steinbach wrote:

* Lionel B:

>>
Beside the point... the fact remains that (as far as we can know) the
"false" branch in the OP's code may be perfectly "unexceptional" . In
fact his/her action for the "false" branch was "Have program do
something else". That doesn't (to me) say "throw exception".

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):

>Sure, it's a fine idiom if deployed as the OP intended, which I'm not
convinced it was.

Anyway, this is all pretty trivial.

--
Lionel B

[James Kanze]

On May 22, 1:57 pm, Gianni Mariani <gi3nos...@mari ani.wswrote:

dave_mikes...@f astmail.fm wrote:

On May 21, 4:28 pm, "Alf P. Steinbach" <[e-mail] rote:

getting rid of the local variable 'test' and also the 'return 0' which
is implied (it's the default) in 'main', and just to make it extra
concise I also removed that darned 'else' which otherwise would use upa
very expensive line, and the keyword 'if' which is so much to read.

The OP's example was nothing like that. Conciseness does not
necessarily lead to obfuscation, your strawman notwithstanding .

I simply don't understand why so many programmers think conciseness isa
goal.

Nor I why so many tend to overcomplicate simple solutions to simple
problems.

They just end up not understanding their own code.

Same thing happens with over-engineered code.

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.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Alf P. Steinbach]

* James Kanze:

On May 22, 1:57 pm, Gianni Mariani <gi3nos...@mari ani.wswrote:

>dave_mikes...@ fastmail.fm wrote:

>>On May 21, 4:28 pm, "Alf P. Steinbach" <[e-mail] rote:

>>>getting rid of the local variable 'test' and also the 'return 0' which
is implied (it's the default) in 'main', and just to make it extra
concise I also removed that darned 'else' which otherwise would use up a
very expensive line, and the keyword 'if' which is so much to read.

>>The OP's example was nothing like that. Conciseness does not
necessarily lead to obfuscation, your strawman notwithstanding .

>>>I simply don't understand why so many programmers think conciseness is a
goal.

>>Nor I why so many tend to overcomplicate simple solutions to simple
problems.

>>>They just end up not understanding their own code.

>>Same thing happens with over-engineered code.

>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.

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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[*PaN!*]

"Alf P. Steinbach" <al***@start.no wrote in message
news:5b******** *****@mid.indiv idual.net...

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?

--
Marco

[Alf P. Steinbach]

* *PaN!*:

"Alf P. Steinbach" <al***@start.no wrote in message
news:5b******** *****@mid.indiv idual.net...

>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?

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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Zeppe]

Alf P. Steinbach wrote:

* *PaN!*:

>"Alf P. Steinbach" <al***@start.no wrote in message
news:5b******* ******@mid.indi vidual.net...

>>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.siz e() 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.

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!*]

"Alf P. Steinbach" <al***@start.no wrote in message
news:5b******** *****@mid.indiv idual.net...

[... 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