I'm not sure what your example is attempting to accomplish, but the reasons system is bad are fourfold:
1) It teaches you to use non-c++ methods to accomplish goals in c++.
2) It opens security holes and can cause memory problems.
3) It takes up an extremely large amount of processor time.
4) It's platform specific, and not portable. In linux, it causes compiler faults.
To be quite honest, the 'system' is the alternative to proper c++ programming. I would recommend just looking for or building a method to do whatever it is that you're trying to do properly, it will help you more in the end.
I guess those old unix guys who invented the pipe never got around to patenting it?
A pipe might be better for the example shown but its not that different from using system in that you are relying on an external program to do some of your work.
This sort of thing is common in sysadmin using scripting languages like perl but is not really a c++ role. But there is nothing to stop you using it for that.
In c++ its more usual to rely on libraries to do things for you.
system("PAUSE"); will not work because most Linuxes don't *have* a utility called PAUSE. The same goes for system("CLR");. However, neither will cause compiler faults.
As an FYI, the Linux equivalents that I know of are: read -n1 -r -p "Press any key to continue..."
Could you please clarify these points in a little more detail, I don't really understand.
1) It teaches you to use non-c++ methods to accomplish goals in c++.
I believe system() is part of the standard c library, and thus part of c++. This is perhaps an argument against launching external programs, but the argument would still apply with CreateProcess or exec. This is not a fault of system()
2) It opens security holes and can cause memory problems
Could you give an example of the relevant security holes that do not occur with the alternative methods of launching an external process?
Can you give an example of the memory problems to which you refer?
3) It takes up an extremely large amount of processor time.
I'm not aware of this, could you please explain?
4) It's platform specific, and not portable. In linux, it causes compiler faults.
I don't think that's true, I believe system() runs the passed command line in the current user's shell on whatever platform it's running on. How is that platform specific?
1. Actually, yes, the same argument applies to exec() in some cases. If you're launching external programs to accomplish a task you could easily do internally, you're doing something wrong. :/
2.
Duoas wrote:
Because you have no guarantee that the program you are executing
1 is a valid command
2 does the same thing on all systems
3 hasn't been compromised with malicious code, or
4 is the program you think it is
At least with the other commands, I believe Microsoft went through some trouble to ensure that 1, 2, and 4 are true. If they didn't, though... I wouldn't be surprised! :P
As for the memory problems... I'm not sure to what he's referring.
I think you've missed my point. What I was trying to say was that there is nothing inherently bad about system(), the problem is with launching external programs to do tasks that are in most cases better accomplished by libraries.
By answering the OPs question (an alternative to system) with CreateProcess, you have solved almost none of the issues you have raised.
People should not be attacking the use of system(), they should be attacking the use of external executables.
I wasn't the one who raised those issues nor was I the one who suggested CreateProcess. The CreateProcess solution described there is somewhat less dependent on the shell than the system() call, and hopefully it does solve some of the problems that were described above. If it doesn't... dangit Microsoft.
Also, I can't say I know enough about the OP's program and its purpose to argue whether or not the use of system() or CreateProcess() or exec() is justified here.
The only situation that I've found to justify the use of UNIX exec() or Windows CreateProcess() is to manage that process. For instance, daemoninizing, monitoring, etc.
To simply give give a result from a process that you started is rather unethical and should be avoided entirely if possible. If you have to do so, be sure it's in a controlled environment and hopefully compare MD5 hashes or something to make sure the executable is what you want it to be (which is a nightmare on Linux unless you give a frozen version of the executable).
Duoas, while that may be so, it's a poor alternative to exec(), CreateProcess(), or whatever other wrappers there are. In reality, those aren't *true* alternatives (as they do not do the same thing) but they're almost always more appropriate.
tejashs, you need to do the following:
1. Ascertain that C++ is the language that is fit for the job you are attempting to do. We don't know what you want to do so we cannot help you here.
2. You need to ascertain that you cannot do what you're wanting in native code which is both faster and less risky.
3. Don't use system(). Seriously. Use Boost.Process or something... While it looks complicated, it's actually very similar to what you'll find in higher-level languages such as Python.