In article <11**********************@l41g2000cwc.googlegroups .com>,
Peter Nilsson wrote:
Keith Thompson wrote: "Peter Nilsson" <ai***@acay.com.au> writes: > Juggler wrote:
> > I have a shell script which takes three arguments, how can
> > I call this script from within a C++ program.
[...] But the answer happens to be the same in C and C++: use the
system() function.
[...] But think about it, Keith...
Since <stdlib.h> is deprecated in C++, then giving them a _C_
solution is the _wrong_ answer, even if it happens to be
correct in clc.
The fact that stdlib.h is deprecated in C++ is only of academic
interest, if at all. The C++ standardization committee still actively
tries to keep the language as compatible with C as possible (``... but
no more!''), so removal of the C headers would be about the most
nonsensical step they could take, since it would instantly break source
compatibility with virtually every (complete) piece of C code for
absolutely no good reason. Don't expect it to happen within the next
decade.
And even if they will be removed some time in a very distant future,
then you can wait for an even longer time, or indeed forever, for the
implementors to drop support as well (and as I'll explain below, many if
not most typical implementations of the standard C++ library *still* do
not even get the C++ replacements for the C headers right.)
There are other valid reasons against using the C headers, but the
deprecation one is certainly not one that weighs much at all, and you
can ignore it if you feel that your C++ code should be using them (e.g.
because you may wish to compile the code with both C and C++ compilers,
whether that is a good thing to wish or not aside.)
A *good* reason is that the C++ versions ought to keep the namespace
clean by placing most of what is in the C headers into the standard
namespace and making it available only upon explicit request. But
unfortunately, even this one usually does not hold in practice, because
many C++ libraries implement the C++ versions atop of the C headers, and
they do *not* keep the namespace clean as they should.
SuSE Linux with libstdc++-devel-3.3-23:
/home/nils [0]> cat new.cpp
#include <cstdio>
typedef int FILE;
int
main(void) {
}
/home/nils [0]> c++ new.cpp -o new
new.cpp:3: error: conflicting types for `typedef int FILE'
/usr/include/stdio.h:46: error: previous declaration as `typedef struct
_IO_FILE FILE'
HP-UX 11i with HP's aC++ A.03.50:
nils@Ariel:~> aCC new.cpp -o new -AA
Error 173: "new.cpp", line 3 # Redefinied symbol 'FILE': previously
defined at ["/usr/include/stdio.h", line 45]
typedef int FILE;
^^^^
(Note that the above code is actually illegal because the C++ standard
says that:
For each type T from the Standard C library, the types ::T and
std::T are reserved to the implementation and, when defined, ::T
shall be identical to std::T.
However, I used this example only for the illustrative error messages.
You can e.g. call printf() without explicitly prepending it with std::
or using an equivalent ``using'' directive to test the implementation,
as well.)
--
My real email address is ``nils<at>gnulinux<dot>nl''
