C++ Succinctly: Introduction

Introduction

C++ Succinctly was written to help professional C# developers learn modern C++ programming. The aim of this book is to leverage your existing C# knowledge in order to expand your skills. Whether you need to use C++ in an upcoming project, or simply want to learn a new language (or reacquaint yourself with it), this book will help you learn all of the fundamental pieces of C++ so you can understand projects and samples written in C++ and begin writing your own C++ programs.

As with any large subject, there simply wasn't room to cover everything (an example being the new atomic features added in C++11), and others might have decided to order the topics differently. I'm thinking particularly of pointers, a topic I cover in depth only further into the book. They are important, so some might have chosen to cover them earlier, but I feel you do not need to understand pointers to understand the material that precedes their coverage; understanding the preceding topics will make it much easier for you to understand them.

I've done my best to be as accurate as possible without sounding like a language specification or documentation file. I hope I have succeeded. I consulted the C++11 language specification frequently while writing this, and I also read everything from StackOverflow posts, to MSDN docs, to GCC docs, and beyond. There are areas where I intentionally simplified things. As you continue to expand your knowledge of C++, you will undoubtedly reach issues where you need to have a more comprehensive understanding in order to accomplish your goal or eliminate a bug. If reading this book imparts enough knowledge-and a good-enough feel for the language that you are able to recognize, diagnose, and resolve those issues-then I will be content that I have succeeded in my goals. Welcome to C++!

Trademarks, Etc.

Being a retired lawyer, I feel compelled to include this brief section, which you probably don't care about unless you are a lawyer for one of these companies or organizations. The remainder of this preface is much more enjoyable reading for non-lawyers, so please don't let this put you off. Microsoft®, Visual Studio®, Visual C++®, Visual C#®, Windows®, Windows NT®, Win32®, MSDN®, Silverlight®, DirectX®, and IntelliSense® are registered trademarks of Microsoft Corporation. GNU® is a registered trademark of the Free Software Foundation. ISO® is a registered service mark of the International Organization for Standardization. IEC® is a registered service mark of International Engineering Consortium, Inc. Unicode® is a registered service mark of Unicode, Inc. (a.k.a. The Unicode Consortium). Intel® is a registered trademark of Intel Corporation. Other trademarks and service marks are the properties of their respective owners.

Program Entry Point

In C#, the entry point for a program is a static method named Main. Often you will not actually see it since various frameworks provide their own (e.g., Silverlight), but it is there, somewhere, since without it the operating system would not know where to begin executing your program.

The entry point of a C++ program is the main function. A simple version looks like this:

int main(int argc, char* argv[])
{
    // Your program starts here.

	// Returning 0 signifies success.
	return 0;
}

The parameters are the argument count followed by an array of the command-line arguments (as strings). In Windows programming, you will often see this as the entry point:

int wmain(int argc, wchar_t* argv[])
{
    // Your program starts here.

	// Returning 0 signifies success.
	return 0;
}

This wmain entry point is Microsoft-specific. It is used as the entry point for Windows Unicode programs (as opposed to older ASCII/code page programs). Microsoft operating systems that support Unicode (everything from Windows 2000 and Windows NT 4 on, and even Win 9X-based systems when you install a special add-on) use UTF-16 encoding. As such, you really should always use Unicode when writing your programs unless you absolutely need to support older systems that do not have Unicode support.

You will frequently also see this as the entry point for Windows programs:

#include <tchar.h>

int _tmain(int argc, _TCHAR* argv[])
{
    // Your program starts here.

	// Returning 0 signifies success.
	return 0;
}

The Windows SDK provides the tchar.h header file, which you can (and should) use when you need to build a project that will be used on both Unicode and non-Unicode versions of Windows. I do not use it in the samples because, to the extent possible, I wanted to make the samples portable and standards-compliant.

Instead, I have written a small header file, pchar.h, which simplifies the entry-point portability issue. This does not solve most portability issues that crop up when dealing with strings; unfortunately, string portability is one area which simply isn't easy in C++. Indeed, my header file here is not a good example of what to do when you actually need the command-line arguments. We will discuss strings in much more detail later in the book. For now, first, here's the header file:

Sample: pchar.h

#pragma once

#if !defined(_PCHAR_H)
#define _PCHAR_H 1

#if defined(WIN32) && defined(UNICODE)
#define _pmain wmain
#define _pchar wchar_t
#else
#define _pmain main
#define _pchar char
#endif

#endif

Second, here's what the entry point now looks like (I have omitted the inclusion of the header file here):

int _pmain(int /*argc*/, _pchar* /*argv*/[])
{
    // Your program starts here.

	// Returning 0 signifies success.
	return 0;
}

As you can see, the parameter names are commented out (using the C-style comment, i.e. /*...*/). This is perfectly legal in C++ and is something you should do whenever you have a function that is required to have certain parameters, although you may not intend to use those parameters. By commenting out the parameter names, you ensure that you will not accidentally use them.

The code in pchar.h gives us a reasonably portable entry point, while the int _pmain(int, _pchar*[]) entry point itself ensures that we will never use the passed-in command-line arguments. If you ever need the command-line arguments, then this solution will not work-you will need a more advanced, more complicated solution.

Arguments and Parameters

I use the terms argument and parameter at various points in this book. To me, an argument is a value that is passed in to a function when called in a program, whereas a parameter is part of the specification of a function that tells the programmer the function is expecting to receive a value of a certain type. It also tells the programmer how it might treat that value. A parameter typically provides a name by which that value can be referenced, though C++ allows us to provide just a type if we are required to have a particular parameter (e.g., to match an interface specification) but do not intend to actually use its value.

As an example of a parameter versus an argument, in C# you might have a class method such as void AddTwoNumbers(int a, int b, ref int result) { result = a + b; }. In this case, a, b, and result are parameters; we know that AddTwoNumbers might change the value of the argument passed in for the result parameter (as, indeed, it does). If you called this method as so, int one = 1, two = 2, answer = 0; someClass.AddTwoNumbers(one, two, ref answer); then one, two, and answer would all be arguments passed in to AddTwoNumbers.

Syntax Highlighting

The code examples in this book use the syntax-highlighting colors from Visual Studio 2012 Ultimate RC. This will help you understand the code, but you will also be fine reading this on a monochrome e-book reader.

Samples

The samples in this book are available at https://bitbucket.org/syncfusion/cpp_succinctly.

The samples for this book were designed and developed using Visual Studio 2012 Ultimate RC. The C++ compiler that comes with VS 2012 includes new features of the C++11 language standard that were not included in Visual Studio 2010. In the fall of 2012, Microsoft will release a free "Express" version of Visual Studio 2012, which will allow developers to use C++ targeted desktop applications (such as the console application, which the samples use). Until then, to make full use of the samples, you will need a non-Express version of Visual Studio 2012.

I tested many of the samples along the way using Minimalist GNU for Windows (MinGW), so there should be a lot of cross-compiler portability. The one sample I know for sure that does not work as written with the GCC compiler that MinGW provides is StorageDurationSample. It makes use of the Microsoft-specific language extension _declspec(thread) in order to simulate thread_local storage. GCC has its own very similar extension, and other compiler vendors undoubtedly do too, so if you replace that with the appropriate code for the compiler you decide to use, it should then compile and run.

Lastly, the samples are all console samples. I chose console samples so we could avoid all the extraneous code that comes with creating and displaying windows within a windowing environment. To see the output of any particular sample, you can either set a breakpoint on the return statement at the end of the _pmain function and then run it using the Visual Studio debugger, or you can run it using the Start Without Debugging command in the Debug menu in Visual Studio (typically this uses the Ctrl+F5 keyboard shortcut). You also need to make sure that the project you wish to run is set as the start-up project. You can accomplish this by right-clicking on the project's name in Solution Explorer and then left-clicking on Set as Startup Project in the context menu that appears.

C++11

In 2011, a new major version of the C++ language standard was adopted by the ISO/IEC working group responsible for the design and development of C++ as a language. When compared with C++98 and C++03, C++11 feels like a different language. Because C++11 is so new, there are no compilers that support every single feature, and there are some that support less than others. I have targeted Visual C++ and the features it implements in its most current release (Visual Studio 2012 RC at the time of this writing), though I have mentioned a few features that Visual C++ does not currently support and have pointed this out when appropriate.

It is unlikely that Visual C++ will change much between Visual Studio 2012 RC and Visual Studio 2012 RTM. There are plans to do an out-of-band update, which will add additional C++11 language support, sometime after the RTM is released. Since I cannot predict which features will be added and do not have any inside knowledge about it, I mostly did not cover things which are not supported in the RC.

If you have previous experience with C++ from five years ago, or perhaps longer, you are likely to be very pleasantly surprised-which is not to say that it has everything C# has.

There are features of C# and .NET that I miss when working in C++. But there are also features of C++ that I miss when working in C#. I miss the simplicity of casting in C# that the CLR's type system provides when I'm working in C++. I also miss .NET's fuller set of exceptions and the frequently better IntelliSense that .NET provides. In C++, I find myself referring to documentation a lot more than in C# to figure out things like what argument values I can and should pass to a particular function, and what values to expect back from it.

When I'm working in C#, I find myself missing the breadth that C++'s different storage durations provide. In C#, most things just wind up on the GC-managed heap, which greatly simplifies memory management. But sometimes I don't necessarily want a class instance to be on the heap. In C#, I have no choice but to rewrite the class as a structure; while in C++, I can easily choose between the two without needing to change the class definition itself. I also miss stand-alone functions (even though they can be mostly emulated with static methods in static classes in C#). I also like that my C++ programs end up as heavily optimized (and thus difficult to understand) machine code when I compile them, so I don't really need to worry about trying to obfuscate my programs if I want my code to stay secret (like I do with .NET, though there are some very good obfuscation tools out there).

Conclusion

Each language targets its own set of problems and has its own history and quirks associated with it. Hopefully you will find C++ an interesting and useful language to add to your programming repertoire.

This lesson represents a chapter from C++ Succinctly, a free eBook from the team at Syncfusion.

HIGHLIGHTS OF THE DAY