While you’re learning C++, you’ll be able to concentrate on the language features without worrying about
the environment in which you’re operating. With the console applications that you’ll write, you have only
a text interface, but this will be quite sufficient for understanding all of C++ because there’s no graphical
capability within the definition of the language. Naturally, I will provide extensive coverage of graphical
user interface programming when you come to write programs specifically for Windows using Microsoft
Foundation Classes (MFC) in native C++ applications and Windows Forms with the CLR.
There are two distinct kinds of console applications and you’ll be using both. Win32 console applications
compile to native code, and you’ll be using these to try out the capabilities of ISO/ANSI C++. CLR console
applications target the CLR so you’ll be using these when you are working with the features of C++/CLI.
Windows Programming Concepts
Our approach to Windows programming is to use all the tools that Visual C++ 2008 provides. The project
creation facilities that are provided with Visual C++ 2008 can generate skeleton code for a wide variety of
native C++ application programs automatically, including basic Windows programs. For Windows applica-
tions that you develop for the CLR you get even more automatic code generation. You can create complete
applications using Windows Forms that only require a small amount of customizing code to be written by
you and sometimes no additional code at all. Creating a project is the starting point for all applications and
components that you develop with Visual C++ 2008, and to get a flavor of how this works, you’ll look at
the mechanics of creating some examples, including an outline Windows program, later in this chapter.
A Windows program, whether a native C++ program or a program written for the CLR, has a different
structure from that of the typical console program you execute from the command line, and it’s more
complicated. In a console program, you can get input from the keyboard and write output back to the
command line directly, whereas a Windows program can access the input and output facilities of the
computer only by way of functions supplied by the host environment; no direct access to the hardware
resources is permitted. Because several programs can be active at one time under Windows, Windows
has to determine which application a given raw input such as a mouse click or the pressing of a key on
the keyboard is destined for and signal the program concerned accordingly. Thus the Windows operat-
ing system has primary control of all communications with the user.
Also, the nature of the interface between a user and a Windows application is such that a wide range of
different inputs is usually possible at any given time. A user may select any of a number of menu options,
click a toolbar button, or click the mouse somewhere in the application window. A well-designed Windows
application has to be prepared to deal with any of the possible types of input at any time because there
is no way of knowing in advance which type of input is going to occur. These user actions are received
by the operating system in the first instance and are all regarded by Windows as events. An event that
originates with the user interface for your application will typically result in a particular piece of your
program code being executed. How program execution proceeds is therefore determined by the sequence
of user actions. Programs that operate in this way are referred to as event-driven programs and are differ-
ent from traditional procedural programs that have a single order of execution. Input to a procedural
program is controlled by the program code and can occur only when the program permits it; therefore, a
Windows program consists primarily of pieces of code that respond to events caused by the action of the
user, or by Windows itself. This sort of program structure is illustrated in Figure 1-2.
7
Chapter 1: Programming with Visual C++ 2008