Professional C__ - Marc Gregoire [438]
A script generally performs a single task, or a set of related tasks. You might have a script that automatically sorts your email, or backs up your important files. Scripts often run without user interaction, perhaps at a particular time each day or triggered by an event, such as the arrival of new mail. Scripts can be found at the OS level (such as a script that compresses files every night) or at the application level (such as a script that automates the process of shrinking and printing images). Automation is an important part of the definition of a script — scripts are usually written to codify a sequence of steps that a user would otherwise perform manually.
Now, consider the difference between a scripting language and a programming language. Not all scripts are necessarily written in scripting languages. You could write a script that sorts your email by using the C programming language, or you could write an equivalent script by using the Perl scripting language. Similarly, not all applications are written in programming languages. A suitably motivated coder could write a web browser in Perl if she really wanted to. The line is blurry.
In the end, what matters most is which language provides the functionality you need. If you are going to be interacting extensively with the operating system, you might consider a scripting language because scripting languages tend to have better support for OS interaction. If your project is going to be larger in scope and involve heavy user interaction, a programming language will probably be easier in the long run.
Using Scripts
The original Unix OS included a rather limited C library, which did not support certain common operations. Unix programmers therefore developed the habit of launching shell scripts from applications to accomplish tasks that should have had API or library support.
Today, many of these Unix programmers still insist on using scripts as a form of subroutine call. Usually, they execute the system() C library call with a string which is the script to execute. There are significant risks to this approach. For example, if there is an error in the script, the caller may or may not get a detailed error indication. The system() call is also exceptionally heavy-duty, since it has to create an entire new process to execute the script. This may ultimately be a serious performance bottleneck in your application.
In general, you should explore the features of the C++ library to see if there are better ways to do something. There are some platform-independent wrappers around a lot of platform-specific libraries; for example, the Boost A Practical Example — Encrypting Passwords Assume that you have a system that writes everything a user sees and types to a file for auditing purposes. The file can be read only by the system administrator so that she can figure out who to blame if something goes wrong. An excerpt of such a file might look like this: Login: bucky-bo Password: feldspar bucky-bo> mail bucky-bo has no mail bucky-bo> exit While the system administrator may want to keep a log of all user activity, she may wish to obscure everybody’s passwords in case the file is somehow obtained by a hacker. A script seems like the natural choice for this project because it should happen automatically, perhaps at the end of every day. There is, however, one piece of the project that might not be best suited for a scripting language. Encryption libraries tend to exist mainly for high-level languages such as C and C++. Therefore, one possible implementation is to write a script that calls out to a C++ program to perform the encryption. The following script uses the Perl language, though almost any scripting language could accomplish this task. If you don’t know Perl,