Re: Add 1 more variable to print
* James Kanze:
On Apr 19, 2:17 am, "Alf P. Steinbach" <al...@start.no> wrote:
[...]
At the technical level (which was only what I was commenting on) mostly
[...]
* the assumption that argv[0] will be the name of the
program name, and
Regarding the program name assumption, it may be valid in
*nix, but not formally (formally it may an empty string
there), and in practice it's not valid in Windows, due to C++
runtime libraries for Windows getting that part wrong:
In which way? As far as I know, the situation in Windows is
identical to that of Unix. And it's not guaranteed; strictly
speaking, Unix doesn't provide the name of the program, so
there's no way an implementation could get it correct.
According to Posix, argv[0] is whatever the program which
started your program wants it to be---the usual shells *do* put
something related to the name of the program here, but other
programs may not. (There's also the question what is actually
required if a value is furnished: the C standard says "the name
of the program", the C++ "the name used to invoke the program".
Neither of which necessarily means anything, at least in certain
contexts.)
It may be as you imply that *nix in practice offers as little guarantee as
Windows C++ runtime libraries do.
However, it is my very strong impression that this is not the case.
I.e., that your "strictly speaking" above is about some formalism, not practice;
that in practice, in *nix argv[0] is whatever the process should /assume/ is its
invocation name (whereas in Windows that is not so).
Windows, of course, has a GetCommandLine function, which Unix
doesn't, but this still leaves the question open: what does it
return if the process wasn't invoked from the command line?
(What does it return, for example, if the lpCommandLine argument
of CreateProcess was NULL?)
GetCommandLine isn't the right Windows API to obtain the name of the program.
For that, use e.g. GetModuleFileName.
This is, by the way, most likely how the Windows C++ runtime libraries manage to
get it wrong, by using the wrong API. That they do get it wrong was illustrated
below.
Also, argv[0] may be NULL (if argc is 0).
(All this to say that there's not much you can *portably* count
on. Depending on the program and the environment from which it
is started, of course, you can often obtain useful information
from it, of course, but it's not really portable.)
Right.
<code>
#include <iostream>
int main( int argc, char* argv[] )
{
std::cout << "Usage: " << argv[0] << " FILENAME" << std::endl;
}
</code>
<example>
C:\temp> md "gah! urgh"
C:\temp> gnuc x.cpp -o "gah! urgh"\teach
C:\temp> c:\temp\gah!^ urgh\teach
Usage: c:\temp\gah! FILENAME
C:\temp> _
</example>
At the design level, of course, some better message would be
desirable...
:-). Of course, you have to deal with the information available
to you. Under Unix, I trim everything up to and including the
last '/', and hope for the best.
Have you ever experienced that to fail?
I see a few minor sytlistic things, but nothing too major.
First of all, streams should probably have been used here,
rather than the old printf-style function. I would have
specified argv[0], rather than using *argv.
I'm not sure any of those two would have been an improvement.
Both are more idiomatic.
Not IME, no.
It's difficult to put numbers on it since "*argv" also typically occurs in
declarations, but Google code search turns up some 320K occurrences of C++ use
of "*argv" and only some 120K occurrences of "argv[0]". :-)
And ostream actually works, despite
its flaws, and isn't an error waiting to be triggered.
Which "error waiting to be triggered" do you see resulting from not using
ostream in this case?
Or is that a general argument?
For the general argument one should bear in mind that iostreams also have a
heap of UB. They are a only little bit more typesafe for simple usage. And due
to their awkward usage model (in particular statefulness) and inherent
complexity -- after all, there aren't that many books, if any, dedicated to
explaining use of FILE*, but there are books dedicated to explain use of
iostreams -- I wouldn't count on use of iostreams to reduce defect rates.
Using iostreams may increase the size of a little program such
as this some orders of magnitude. Hm. I hate iostreams.
And it may not. It tends to increase the size (and the compile
times) on some systems because it is a template---this is an
obvious design error introduced by the standards committee. But
in this case, the apparent increase in the size of the
executable is probably due to the fact that you can't
dynamically link a template (at least in most implementations).
Yes, that's probably part of the explanation.
But whatever the explanation is in any particular case, it's really annoying.
Dietmar Kuehl once wrote an implementation of iostream that
didn't suffer from these problems---the standard certainly
allows an explicit specialization for char and wchar_t, which
could be placed in a shared library. But no one seems to have
been interested---he made the code freely available, but none of
the implementations I know took advantage of it.
Some of his techniques/ideas may have ended up in Dinkumware's implementation.
I asked him about it once but I don't recall any firm answer.
However, we'd both had a few beers. :-)
Which leads me
to conclude that there aren't any problems in practice with the
current implementations of iostream, at least with regards to
size or performance. To tell the truth, that surprises me, but
you can't argue with the facts.
The facts can't be argued with but the reasoning certainly can.
For example, many alternatives to MS-DOS were available at the time of that OS's
popularity, and were very well known, in contrast to Dietmar's iostreams, or for
that matter Andrei's (incomplete) STL implementation YASTLI.
However, since people and companies did not, generally, replace MS-DOS with
those alternatives, we can by your logic conclude that MS-DOS was bestest, or at
the very least, did not have any serious problems. :-)
And I don't think anyone should deal with code using argv
without understanding pointer dereferencing and indexing,
where it's just a matter of taste.
The use of argv is, in the end, more or less conventional. You
follow the conventions, and don't worry about how it is
implemented. In practice, there's certainly no need to think of
it as a pointer. (On the other hand, I'd seriously suggest that
the first thing one do is copy it into a vector<string>. But I
don't think that that's "existing practice".)
The language and standard library lacks general functionality to access
"environment", as some other languages' standard libraries have.
This is unfortunate since it is in a much more basic class than functionality
such as database access, graphics, networking, windowing, filesystem, and so on.
I think it should be there.
Cheers,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!