Last updated: 2012-02-02
This is a big post – over 12200 words – and so I’ve decided to make it available as a PDF download, which you can get here:
http://www.bobtacoindustries.com/Content/Devs/CsToCpp-ASomewhatShortGuide.pdf
It has bookmarks for easier navigation along with a Table of Contents and page numbers.
I expect that I will revise this from time to time and welcome any suggestions, feedback, and (especially) corrections. If so I will update the Last updated field at the top and will create a revised PDF as well. I hope this proves useful.
For those interested, the sessions from the GoingNative 2012 conference will be streaming live today (Feb 2) and tomorrow on Channel 9: http://channel9.msdn.com/posts/Announcing-the-GoingNative-2012-Full-Schedule . Sessions will also be available for download shortly after the show ends (I’d guess within 24-48 hours, but that’s just a guess). It looks fascinating so definitely check it out! (I know I will be watching it.)
Introduction
This is a somewhat short guide to the important things to know if you are a C# programmer and find yourself needing or wanting to work in C++, for example to create Metro style games for Windows 8 using C++ and DirectX. In fact, this guide is written with that goal in mind so it's not necessarily a universal guide for all platforms and purposes.
This guide is also going to be fairly utilitarian and pithy, with code standing in place of elaborate commentary. I'm expecting that you know how to program already and have a good understanding of C# (or of some sort of imperative, object-oriented language at any rate).
I'm also assuming you are fairly handy with navigating the MSDN library. Its Bing search box is really awesome; if you haven't used it before, do give it a try. I like how the search is tailored to not just MSDN but also other great programmer sites like the Stack Exchange sites, CodeProject, CodePlex, etc.
I'm sprinkling a fair bit of code throughout as I said above. This is both to show you a (pseudo) real example of something and also to help illustrate words with code so that each will hopefully help to clarify the other.
I highly encourage you to create a simple scratch program that you can mess around with. I do this all the time with various languages and frameworks in Visual Studio. I normally append "Sandbox" to the name so that I know it's something I am just playing around in. I tend to comment code out when done with it rather than delete it since I may want to look at it again in the future (perhaps to see a specific syntax that I puzzled out but haven't used in a while or maybe for some technique I was trying that I now want to use in a real project). If the code in question might be a bit confusing later on, I try to add some comments that will help me understand it. It's helpful to use a descriptive naming scheme for variables, classes, and functions (though I admit that I'm not too good about this in my sandbox apps). If a project gets too full or busy then I might use regions to hide a section of code or I might create another project or even another solution that will serve as a clean slate.
While developing this guide I've mostly been working in a project called CppSandbox developed in VS 2010 Ultimate and checked in VC++ 2010 Express. It's just a C++ Win32 Console Application (without ATL or MFC but with a precompiled header). This has let me test things like thread local storage duration. The C++/CX stuff can only be tested on using the VS11 preview on Windows Developer Preview (and, presumably, the next preview release of Windows 8, which is due towards the end of this month (Feb 2012)). For everything else you can use either VS 2010 Professional or greater or VC++ 2010 Express (available free here: http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express ).
The major feature not present in VC++ 2010 is the ability to compile 64-bit applications. I'm not going to be touching on that here and I don't know whether that will be possible with the free versions of VS11 when they are released. I did do some tests with it in VS 2010 Ultimate just so I could examine the ASM it generates (out of curiosity). The main reason I developed in VS 2010 Ultimate is that it lets me work on multi-language projects at the same time such that I could write out a bit of test code in C# in a Console project and then duplicate it in C++. That wound up not being a big factor since I changed tactics but I already had the sandbox project so I just kept working with it.
That's enough chit-chat, I think. Let's get down to business!
The C++ standard only requires that the integral types and floating point types each be at least as large as their next smallest counterpart. So when is a long not a long? When one long is a C# long (8 bytes) and the other is a Visual C++ long (4 bytes – same as an int). A Visual C++ 'long long' is 8 bytes. Microsoft has a table of fundamental sizes here:
http://msdn.microsoft.com/en-us/library/cc953fe1.aspx
Note that there are Microsoft-specific integral types that specify sizes exactly, such as __int32 (a 32-bit integer, same as a C# int), __int64 (a 64-bit integer, same as a C# long), etc.
The float and double types are the same sizes as in C# (32-bit and 64-bit, respectively). There's a type called 'long double' but in Visual C++ it is the same as a double so I don't recommend using it to avoid confusion.
The difference between a class and a struct is simply that a struct's members default to public whereas a class's members default to private. That's it. They are otherwise the same.
That said, typically you will see programmers use classes for elaborate types (combinations of data and functions) and structs for simple data-only types. Normally this is a stylistic choice that represents the non-object-oriented origins of struct in C and that makes it easy to quickly differentiate between a simple data container versus a full-blown object by looking to see if it's a struct or a class. I recommend following this style.
In WinRT programming, a struct that is public can only have data members (no properties or functions) and those data members can only be made up of fundamental data types and other public structs (which, of course, have the same data-only, fundamental & public structs only restrictions).
As a terminology note, you'll commonly see structs that only have data members referred to as plain old data ("POD") structs.
You will sometimes see the friend keyword used within a class definition. It is followed by either a class name or a function declaration. What this does is give the class/function specified access to the non-public member data and functions of the class. It's probably not a great thing to use very often (if ever), but if you decide you need it for some reason and that refactoring your code would be impractical, it's there.
C++ classes can inherit from multiple base classes. This is called multiple inheritance. I strongly recommend that you only use multiple inheritance as a workaround for the fact that C++ has no separate "interface" type. Design classes in the same way that you would in C# (i.e. with either no (explicit) base class or else with just one base class). When you want an interface, create an abstract class and inherit from that as well. To avoid trouble, have your interface classes only define pure virtual member functions. The syntax for such is to follow its parameter list with '= 0'. For example:
class IToString
{
public:
// Require inheriting classes to define a ToString member function
virtual std::wstring ToString() = 0;
};
class SomeBaseClass
: virtual public IToString
{
public:
SomeBaseClass()
: m_count()
{
}
~SomeBaseClass() { }
std::wstring ToString() { return std::wstring(L"SomeBaseClass"); }
void AddToCount(int val) { m_count += val; };
int GetCount() { return m_count; }
protected:
int m_count;
};
class SomeClass
: public SomeBaseClass
, virtual public IToString
{
public:
SomeClass() { }
~SomeClass() { }
void SubtractFromCount(int val) { m_count -= val; }
std::wstring BaseToString() { return SomeBaseClass::ToString(); }
std::wstring ToString() override { return std::wstring(L"SomeClass"); }
};
You'll notice that we marked the inheritance from the "interface" class with the virtual keyword when inheriting from it. This prevents a bizarre, battle of the inheritances from playing out. It'll compile without it (maybe) and if so likely even work right without it. However if you had data members in the class that is inherited from twice, it would wind up creating two copies of those data members (thereby making the class take up more room in memory).
Also, without marking the inheritance virtual, you must implement ToString in SomeClass rather than just inheriting it from SomeBaseClass. Otherwise you would get a compile error complaining that SomeClass is an abstract class wherever you tried to instantiate it and errors about being unable to pick between SomeBaseClass::ToString and IToString::ToString whenever you tried to call SomeClass's ToString member function. So the compiler issues warnings to you if you don't have those virtual markers because it's not sure that you really wanted two implementations of IToString.
Note that if you left off the override keyword from the definition of ToString in SomeClass, you would get a compiler warning about how SomeBaseClass already provides you with an implementation of IToString::ToString. By telling it we want to override any other definitions we make it clear that we want to override it and didn't just accidentally add it.
SomeClass's BaseToString member function shows the syntax you use when you want to call a member function of a class you've inherited from. It's the same syntax you'd use if you were calling a static member function, but the compiler knows that it's not a static and makes sure to translate things correctly so that it'll call SomeBaseClass's ToString when you use that syntax inside a derived class like that.
A union is a data type that can't inherit from other classes or be a base class for other classes to inherit from. (In the last sentence, class refers to 'class', 'struct', and 'union' which are considered to be mandatory class-keys that specify the particular behavior of a class type). A union is made up of data members and (optionally) functions. Only one of its non-static data members can be active. This lets it fill several different roles at different times. It can also open the door to potential micro-optimizations.
There's a lot more that could be said about unions, but I have no intention of explaining them here. Unions are complicated to explain and I don't personally find them helpful. I see them as being part archaic and part advanced. You can get by just fine without them and if you really need to know more you can read up about them elsewhere. If there's sufficient desire, I'll reconsider my decision and perhaps either add more about them here or else write about them elsewhere or at least link to someone who has.
C++ has four types of constructors: default, parameterized, copy, and move.
A default constructor is a constructor that can be called without an argument. Note that this includes a constructor that has parameters, provided that all the parameters have been assigned default values. There can only be one of these.
A parameterized constructor is a constructor which has at least one parameter without a default value.
A copy constructor is a special type of constructor which creates a copy of an existing class instance. There are two potential types of these (one const, one non-const) but normally you only write a const version. The compiler will typically implicitly create one for you if you don't (there are specific rules governing this). I always find it better to be explicit rather than rely on rules I would have to look up and read carefully.
A move constructor is a special type of constructor which creates a new class instance that moves the data contents of another class into itself (thereby taking over the data). They have various uses, but an easy to understand example is where you have a std::vector<SomeClass> (the C# equivalent is List<SomeClass>). If you do an insert operation and there is no move constructor (think a List<T> where T is a value type) then every object that has to be moved must be copied. That churns a lot of memory and wastes a lot of time. If there is a move constructor then everything goes much faster since the data can just be moved without copying. There are some instances where the compiler will implicitly create a move constructor for you. You should be explicit about this since you could easily wind up accidentally triggering a circumstance that causes one to suddenly be created/not created whereas previously it was not created/created (i.e. it flips behavior). You could in theory have both a const and a non-const move constructor, but a const one makes no sense at all.
With both copy and move constructors, if you provide one you should also provide the equivalent assignment operator overload.
We'll examine a class with all types of constructors now.
The following is the header file of a class named SomeClass. It includes the definition as well, though normally you would put any non-inline member function definitions in a separate CPP file. The class doesn't do anything of value but it does demonstrate a variety of things, such as all constructor types, a destructor, the use of checked iterators to safely copy data, and the use of some helpful Standard Library functions such as swap, fill_n, and copy. It also demonstrates both a static member function and an instance member function (one that is marked const (see Const-Correctness below)).
#pragma once
#include <string>
#include <algorithm>
#include <iterator>
using namespace std;
using namespace stdext;
class SomeClass
{
public:
// Default constructor with default value parameter.
SomeClass(const wchar_t* someStr = L"Hello");
// Copy constructor.
SomeClass(const SomeClass&);
// Copy assignment operator.
SomeClass& operator=(const SomeClass&);
// Move constructor.
SomeClass(SomeClass&&);
// Move assignment operator.
SomeClass& operator=(SomeClass&&);
// Constructor with parameter.
SomeClass(int, const wchar_t* someStr = L"Hello");
// Destructor.
~SomeClass(void);
// Declaration of a static member function.
static void PrintInt(int);
// Declaration of an instance member function with const.
void PrintSomeStr(void) const;
// Declaration of a public member variable. Not per se a
// good idea.
std::wstring m_someStr;
private:
int m_count;
int m_place;
// This is going to be a dynamically allocated array
// so we stick it inside a unique_ptr to ensure that
// the memory allocated for it is freed.
std::unique_ptr< long long[] > m_data;
};
// Default constructor definition. Note that we do not
// restate the assignment of a default value to someStr here in the
// definition. It knows about it from the declaration above and will
// use it if no value is provided for someStr when calling this
// constructor.
inline SomeClass::SomeClass(const wchar_t* someStr)
: m_someStr(someStr)
, m_count(10)
, m_place(0)
, m_data(new long long[m_count])
{
std::wcout << L"Constructing..." << endl;
std::fill_n(checked_array_iterator<long long*>(this->m_data.get(), m_count), m_count, 0);
}
// Copy constructor definition.
inline SomeClass::SomeClass(const SomeClass& other)
: m_someStr(other.m_someStr)
, m_count(other.m_count)
, m_place(other.m_place)
, m_data(new long long[other.m_count])
{
std::wcout << L"Copy Constructing..." << endl;
std::copy(other.m_data.get(), other.m_data.get() + other.m_count, checked_array_iterator<long long*>(this->m_data.get(), this->m_count));
}
// Copy assignment operator definition.
inline SomeClass& SomeClass::operator=(const SomeClass& other)
{
std::wcout << L"Copy assignment..." << endl;
this->m_someStr = other.m_someStr;
this->m_count = other.m_count;
this->m_place = other.m_place;
if (this->m_data != nullptr)
{
this->m_data = nullptr;
}
this->m_data = std::unique_ptr<long long[]>(new long long[other.m_count]);
std::copy(other.m_data.get(), other.m_data.get() + other.m_count, checked_array_iterator<long long*>(this->m_data.get(), this->m_count));
return *this;
}
// Move constructor definition.
inline SomeClass::SomeClass(SomeClass&& other)
: m_someStr(other.m_someStr)
, m_count(other.m_count)
, m_place(other.m_place)
, m_data(other.m_data.release())
{
std::wcout << L"Move Constructing..." << endl;
}
// Move assignment operator definition.
inline SomeClass& SomeClass::operator=(SomeClass&& other)
{
std::wcout << L"Move assignment..." << endl;
std::swap(this->m_someStr, other.m_someStr);
std::swap(this->m_count, other.m_count);
std::swap(this->m_place, other.m_place);
std::swap(this->m_data, other.m_data);
return *this;
}
// Parameterized constructor definition. Note that we do not
// restate the assignment of a default value here in the definition.
// It knows about it from the declaration above and will use it if
// no value is provided for someStr when calling this constructor.
inline SomeClass::SomeClass(int count, const wchar_t* someStr)
: m_someStr(someStr)
, m_count(count)
, m_place()
, m_data(new long long[m_count])
{
std::wcout << L"Constructing with parameter..." << endl;
for (int i = 0; i < m_count; i++)
{
m_data[i] = (1 * i) + 5;
}
}
inline SomeClass::~SomeClass(void)
{
std::wcout << L"Destroying..." << endl;
//// This isn't necessary since when the object is destroyed
//// the unique_ptr will go out of scope and thus it will be
//// destroyed too, thereby freeing any dynamic memory that was
//// allocated to the array (if any).
//if (this->m_data != nullptr)
//{
// this->m_data = nullptr;
//}
}
// Note that we don't have the static qualifier here.
void SomeClass::PrintInt(int x)
{
std::wcout << L"Printing out the specified integer: " << x << endl;
}
// But we do need to specify const again here.
void SomeClass::PrintSomeStr(void) const
{
wcout << L"Printing out m_someStr: " << m_someStr << endl;
// If we tried to change any of the member data in this method
// we would get a compile-time error (and an IntelliSense
// warning) since this member function is marked const.
}
Hopefully the above was enlightening. Terms like move constructor and copy constructor are thrown around a lot in C++ so having an example to look at should prove helpful. My goal was not to produce a class that is useful, but one where you could see the declaration patterns of these constructor types and see some ways to implement them (along with the required assignment operator overloads) by using Standard Library functions.
There are four possible storage durations: static, thread, automatic, and dynamic.
Within a block (one or more lines of code within curly braces), a variable declared
a) either with no duration keyword or with the 'register' keyword; AND
b) without using the 'new' operator
has automatic scope. This means that the variable is created at the point at which it is declared is destroyed when the program exits the block. Note that each time the declaration statement is executed, the variable will be initialized. In the following:
for (int i = 0; i < 10; ++i)
{
SomeClass someClass;
someClass.DoSomething(L"With Some String");
}
you'll run the SomeClass constructor and destructor ten times (in the order constructor - destructor - constructor - destructor - ... since the current SomeClass instance will go out of scope each time before the condition (i < 10) is evaluated).
(Note that the 'auto' keyword used to be a way of explicitly selecting automatic storage duration. It's been repurposed to function the same as the 'var' keyword in C# as of C++11 (this new meaning of auto is the default in VS2010 and later). If you try to compile something using the old meaning of auto you'll get a compiler error since auto as a type specifier must be the only type specifier. If you've got a lot of legacy code you can disable the new behavior (look it up on MSDN); otherwise stick with the new meaning of auto.)
Dynamic duration is what you get when you use either the new operator or the new [ ] operator. While it is fine and even necessary to use dynamic duration objects, you should never allocate them outside of either a shared_ptr or a unique_ptr (depending on which suits your needs). By putting dynamic duration objects inside of one of these, you guarantee that when the unique_ptr or the last shared_ptr that contains the memory goes out of scope, the memory will be properly freed with the correct version of delete (delete or delete [ ]) such that it won't leak. If you go around playing with naked dynamic duration, you're just asking for a memory leak. For more about this see the next topic.
It is also possible to declare certain types of variables as having thread duration. This is similar to static duration except that instead of lasting the life of the program (as we'll see shortly), these variables are local to each thread and the thread's copy exists for the duration of the thread. Note that the thread's copy is initialized when the thread is started and does not inherit its value from the thread that started it.
C++11 has added a new keyword to declare this ('thread_local') however this keyword is not yet recognized such that you need to use the Microsoft __declspec(thread) syntax to obtain this behavior. For more information, see: http://msdn.microsoft.com/en-us/library/9w1sdazb.aspx . See below for a general overview of initialization.
Since this is a bit weird, I created a small sample to make sure I knew what was going on. It's a Win32 Console App tested in VC++ 2010 Express.
We finish up with static duration. Primarily because static duration is what you get when none of the other durations apply. You can ask for it explicitly with the static keyword.
The details of exactly what happens during initialization of static and thread duration objects are complicated. Everything will be initialized before you need it and will exist until the end of the program/thread. If you need to rely on something more complex than this, you’re probably doing something wrong. At any rate, you'll need to sit down and read the C++ standard along with the compiler's documentation to figure out what's going on when exactly. Some of the initialization behavior is mandatory, but a lot of it is "implementation defined", meaning you need to read the compiler's documentation (i.e. the relevant MSDN pages).
If you've worked in a .NET (or other garbage collected) language for a while, you're likely very used to using the 'new' keyword (or its equivalent in your language of choice). Well, in C++ the 'new' keyword is an easy way to create a memory leak. Thankfully, modern C++ makes it really easy to avoid this.
First, if you have a class with a default constructor, then when you declare it, it automatically constructs itself and when it goes out of scope it is automatically destroyed then and there. We discussed this earlier in automatic storage duration.
Next, the language provides two constructs that make it easy to allocate memory and ensure that it is properly freed: shared_ptr and unique_ptr. A shared_ptr is an automatically reference counted container that holds a pointer type (including dynamic arrays such as "new float[50]"). One or more shared_ptrs can exist for the same underlying pointer, hence the name.
Another object is the unique_ptr. You should use this in place of raw pointers except when you need multiple pointers to the same dynamic data (in which case use shared_ptr). Using a unique_ptr ensures that the memory owned by it will be freed when the unique_ptr itself is destroyed (e.g. by going out of scope, via a destructor, or via stack unwinding during an exception).
The last object to consider here is weak_ptr. The weak_ptr exists solely to solve the problem of circular references. If two objects hold shared_ptr references to each other (or if such a thing happens in the course of, say, a doubly-linked list) then shared_ptr's internal reference count can never drop to zero and so the objects will never be destroyed. For such a situation, make one of the references a weak_ptr instead. Weak_ptr is essentially a shared_ptr that doesn't increase the reference count. If you need to use the weak_ptr to access the resource, call its lock function to get a shared_ptr of the resource and then use that. If the object was destroyed before you could get it with lock, you will get back an empty shared_ptr.
The above types are all in the C++ Standard Library's memory header file, which you include as so:
#include <memory>
Notice that there is no ".h" at the end there. That's the way all of the standard library's headers are. If you're curious as to why, see: http://stackoverflow.com/questions/441568/when-can-you-omit-the-file-extension-in-an-include-directive/441683#441683 .
RAII is a design pattern that, when done properly, enables C++ code to successfully use exceptions without resource leaks. Since C++ doesn't have a GC the way C# does, you need to be careful to ensure that allocated resources are freed. You also need to be sure that critical sections (the equivalent of a lock statement in .NET) and other multi-threaded synchronization mechanisms are properly released after being acquired.
RAII works because of this: when an exception occurs, the stack is unwound and the destructors of any fully constructed objects on the stack are run. The key part is "fully constructed"; if you get an exception in the midst of a constructor (e.g. an allocation failure or a bad cast) then since the object isn't fully constructed, its destructor will not run. This is why you always put dynamic allocations inside of unique_ptr or shared_ptr. Those each become fully constructed objects (assuming the allocation succeeds) such that even if the constructor for the object you are creating fails further in, those resources will still be freed by the shared_ptr/unique_ptr destructor. Indeed that's exactly where the name comes from. Resource acquisition (e.g. a successful allocation of a new array of integers) is initialization (the allocation happens within the confines of a shared_ptr or unique_ptr constructor and is the only thing that could fail such that the object will be initialized assuming the allocation succeeds (and if it doesn't then the memory was never acquired and thus cannot be leaked)).
RAII isn't only about shared_ptr and unique_ptr, of course. It also applies to classes that represent, e.g., file I/O where the acquisition is the opening of the file and the destructor ensures that the file is properly closed. Indeed this is a particularly good example since you only need to worry about getting that code right just the once (when you write the class) rather than again and again (which is what you would need to do if you couldn't use this and instead had to write the close logic every place that you needed to do file I/O).
So remember RAII and use it whenever dealing with a resource that, when acquired, must be freed. (A critical section is another good candidate; successfully getting the enter into the critical section is the acquisition and the destructor would then make sure to issue the leave).
Const-correctness refers to using the const keyword to decorate both parameters and functions so that the presence or absence of the const keyword properly conveys any potential side effects. The const keyword has several uses in C++. For the first three uses, imagine we have the following variable:
int someInt = 0;
int someOtherInt = 0;
int* const someConstPointer = &someInt;
//someConstPointer = &someInt; // illegal
*someConstPointer = 1; // legal
A const pointer is a pointer that cannot be pointed at something else. You can change the value of the data at the location the const pointer points to. So above, attempting to change the target (even to the same target) is illegal and thus won’t compile but changing the value of someInt by dereferencing someConstPointer is perfectly legal and someInt will now have the value 1.
const int* somePointerToConst = &someInt;
somePointerToConst = &someOtherInt; // legal
//*somePointerToConst = 1; // illegal
A pointer to const is a pointer to a value that you cannot change via the pointer. You can make the pointer point to something else, though. So above, you can change the target of somePointerToConst. But you cannot change the value of whatever it is pointing to. At least, not via the pointer; you can still set someInt and someOtherInt to have other values either directly or via a pointer that is not a pointer to const. In other words, the const keyword only affects the pointer, not the underlying data.
const int* const someConstPointerToConst = &someInt;
//someConstPointerToConst = &someInt; // illegal
//*someConstPointerToConst = 1; // illegal
A const pointer to const is, as you might guess, a pointer to a value that you cannot change via the pointer and that cannot be pointed at something else. It’s an amalgamation of the previous two uses of const.
You can also use const to specify that a value in general is constant. It need not be a pointer. For instance you could have
const int someConstInt = 10;
which would create an int that was constant (i.e. unchangeable).
If someInt up above was made a const then the declaration of someConstPointer would be illegal since you would be trying to create a pointer to an int, not a pointer to a const int. You would, in effect, be trying to create a pointer that could modify the value of a const int, which by definition has a constant, un-modifiable value.
Sometimes you will see a function that is declared and defined with the const keyword after the parentheses in which its parameters (if any) go. For example:
void PrintCount(void) const
{
wcout << L"m_count = " << m_count << endl;
}
What this usage of const means is that the function itself will not modify any non-static data members of the class and that it will not call any member function of the class unless they are also marked const.
In certain instances you may wish to be able to change a particular data member even within constant member functions. If you mark the data member with the mutable keyword, e.g.
mutable int m_place;
then that data member can be changed even within member functions marked as const.
When you use const to appropriately decorate function parameters, mark class member functions const where appropriate, and mark member data that needs to be changed within member functions that are otherwise marked const, you make it easier to understand the side-effects of your code and make it easier for the compiler to tell you when you are doing something that you told yourself you would not do.
The point of const-correctness is to prevent bugs and to make it easier to diagnose a bug. If you have some instance data member that is getting a completely wrong value somehow, you can instantly eliminate any functions that are marked const from your search since they should never be changing the instance data (unless it’s marked mutable, in which case you know to look at those const functions too).
Unfortunately there’s this thing called const_cast<T> which can ruin the party. The const_cast operator can, in many circumstances, eliminate the "const"-ness of something. It also eliminates any volatile and __unaligned qualifiers. You should really, really try to avoid using const_cast if at all possible. But const_cast does have some legitimate uses (otherwise why include it). If you’re interfacing with old code and/or a C language library that doesn’t follow const-correctness and you know that the function you are calling does not modify a variable that it takes as a non-const parameter, then you can mark the parameter to your function that you want to pass as const and then use const_cast to strip the const-ness from it so you can pass it to that function.
If you did any C or C++ programming at some point in the past you might remember these char* things that were used for strings. DO NOT USE THEM. ASCII strings and characters (char* and char) have no place in a modern program. The 80s are over, and it's a new, Unicode world.
Generally you’ll work with std::wstring and/or wchar_t* strings. These are the two types that Windows uses for Unicode strings. If you're getting data from the internet, you may well be getting it as UTF-8. This is not the same as wchar_t* or std::wstring. If you need to deal with UTF-8 data for some reason, look around on the web for suggestions.
Sometimes in Windows you’ll see the _TCHAR macro used. If you’re ever writing code that needs to run on Win 9x, use the _TCHAR system. Since I’m presuming that you’re learning C++ to use current (D3D11) DirectX technologies, most (if not all) of which don’t even exist pre-Vista, I prefer to work directly with wchar_t and std::wstring since that way macros don’t obscure function parameters in IntelliSense.
C++ recognizes several prefixes for string literals. For wide character strings (the two types above), the prefix L is used. So
const wchar_t* g_helloString = L"Hello World!";
creates a new wide character string. The wchar_t type is used for Unicode strings (specifically UTF-16).
The standard library’s std::wstring is a container for a wchar_t* string. It provides functions for mutating the string and still lets you access it as a wchar_t* when needed. To create one you would do something like this:
std::wstring someHelloStr(L"Hello World!");
If you are using std::wstring (which you should for any mutable strings you create) when you need to get the pointer from it to pass to a function that requires a const wchar_t* then use std::wstring’s data function. (If it needs a non-const wchar_t* then ask yourself whether or not you can accomplish what it is proposing with wstring's functionality instead. If not then you need to create a copy of the data using something like the wcscpy_s function (in wchar.h). Beware of memory leaks.)
If you're coming from C#, you're likely used to seeing the postfix increment operator (i++) most everywhere.
In C++ you'll normally see the prefix increment operator (++i) everywhere.
In both languages the two operators mean the same thing. Postfix means "increment the variable and return the variable's original value (i.e. its value prior to incrementing it)". Prefix means "increment the variable and return the variable's resulting value (i.e. its value after incrementing it)".
To do a postfix increment, the compiler needs to allocate a local variable, store the original value in it, perform the increment, and then return the local variable. (Sometimes it can optimize the local variable away, but not always.)
To do a prefix increment, the compiler can simply increment the variable and return the result without creating an additional local variable.
In truth, the compiler is likely going to be able to optimize away your i++ extra temp allocation if you choose to use the postfix increment (VS 2010 SP1, for example, produces identical assembly code for both (no temp) with a typical ‘for (int i =0; i < 10; i++) { … }’ loop even in Debug configuration where it isn’t going hyperactive with optimizations). Cases where it likely can’t are primarily with custom types that actually implement the increment and decrement operators (see http://msdn.microsoft.com/en-us/library/f6s9k9ta.aspx ) and in cases outside of a ‘for’ loop where you are actually using the value returned by the increment (or decrement) calculation (in which case it definitely can’t since you clearly want either the one value or the other).
In general, using the prefix increment mostly seems to serve as notice that you have spent at least some time learning something about C++ programming.
When coming from C# and .NET, you're undoubtedly familiar with the generic containers in C#. C++ also has these sorts of things but the names and methods may not be familiar (they also work a bit differently). Here are some of the more common mappings for collection types typically used in C# game development.
The header file include is #include <vector>
A typical way to create one is like this:
std::vector<SomeType> vec;
To add an item to the end of the vector, use the push_back member function. To delete the element at the end use pop_back. For example:
vec.push_back(someItem); // someItem added to the end.
vec.pop_back(); // someItem has now been removed from the end.
To insert an item somewhere other than at the back, use the insert function, e.g.:
vec.insert(begin(vec) + 1, someItem); // someItem added to index 1
// To add to the beginning, you'd just use begin(vec) without the + 1
To remove an item use the erase function, e.g.:
vec.erase(begin(vec) + 2); // The item at index 2 will be removed.
Note that unless you are storing a shared_ptr, any external references to the object will become bad since the destructor will run upon erasing it.
To iterate a vector's items, use code that looks something like this:
for (auto item = begin(vec); item != end(vec); ++item)
{
// Do stuff with item.
}
If the class you are storing in a vector supports move semantics (i.e. move constructor and move assignment operator) then vector will take advantage of that if you ever need to do an insert or an erase. This can provide a vast speed increase over the copy semantics it would otherwise need to use.
The header file include is #include <unordered_map>
A typical way to create one is like this:
std::unordered_map<int, std::wstring> someMap;
The syntax for adding an item is a little funny (which is why I used real types above rather than made up ones; the key doesn't need to be an int and the value doesn't need to be a wstring). Here's an example of adding an item:
someMap.insert(std::unordered_map<int, std::wstring>::value_type(1, std::wstring(L"Hello")));
Yeah, you need to recapitulate std::unordered_map<TKey,TValue> in order to access its static member value_type (which is an alias for the appropriate constructor of the std::pair type for your map), which you use to insert the key and value. You may want to typedef it so you can shorten it, e.g.
typedef std::unordered_map<int, std::wstring> IntWstrMap;
...
someMap.insert(IntWstrMap::value_type(1, std::wstring(L"Hello");
If you try to use insert with a key that already exists, the insert fails. The insert function returns a std::pair with the iterator as the first item and a bool indicating success/failure as the second, so you can do something like:
if (!someMap.insert(
std::unordered_map<int, std::wstring>::value_type(
1, std::wstring(L"Hey"))).second)
{
wcout << L"Insert failed!" << endl;
}
You can also insert items by array notation syntax, e.g.:
someMap[0] = std::wstring(L" World");
If an item exists at that key it will be replaced (unlike with insert). If not, the key will be added and the item inserted there. Note that this is different than in .NET where you would get an exception if you tried to use a key that didn't exist.
To determine if a key exists, use something like this:
if (someMap.find(2) == end(someMap))
{
wcout << L"Key 2 not found. Expected." << endl;
}
where '2' is the key you are looking for. You could also store the result of the find, check it against end(someMap), and if it's not that, then you know that you have the item.
Indeed, if you want to retrieve an item only if it exists, this is the correct way to do it:
auto itemPair = someMap.find(1);
if (itemPair != end(someMap))
{
wcout << itemPair->second << endl;
}
If you tried using array notation, e.g.
auto item1Wstr = someMap[1];
you would wind up inserting an item at key '1' if no such item existed, with item1Wstr being the empty wstring that was inserted when you tried to get a key that didn't exist (but does now).
You can also use the at function to get an element at a specific key. If that key doesn't exist, it will throw an exception of type std::out_of_range. For example:
std::wstring result;
try
{
result = someMap.at(1);
}
catch (std::out_of_range e)
{
// Do some error handling
wcout << e.what() << endl;
}
To remove an item, the easiest way is to just call the erase member function with the key you wish to remove.
someMap.erase(1);
You can also use iterators to remove specific items or even a range of items, but in practice these may not be worth the bother. The same caution about references going bad applies here as well as it did in vector. Calling erase will trigger the destructor of any object, whether key or value.
This is a binary tree rather than a hash map, (which is what unordered_map is). It's used in pretty much the exact same way as unordered_map so read above for usage info.
There are too many collection types to go through them all in such detail. Here are several others you may be interested in:
· std::list – LinkedList<T>
· std::stack – Stack<T>
· std::queue – Queue<T>
You may here mention of lvalues and rvalues from time to time. C++ has divided up rvalues into two subtypes: xvalues and prvalues. Which also generated something called glvalues. But we'll get confused if we go any further without clarifying this lvalue and rvalue business. The L and R stand for left and right. An lvalue was a value that could be on the left side of an assignment operator (in other words to the left of an = sign) while an rvalue was a value that could appear to the right of an assignment operator. So given
int x = 5 + 4;
the x would be an lvalue, while 5, 4, and (5 + 4) would all be rvalues.
C++11 has added the concept of rvalue references (which we will discuss shortly). This has created the concept of an expiring value (an xvalue), and in turn the concept of pure rvalues (prvalues).
Prvalues are things like literals as well as the result of a function, provided that that result is not a reference.
An xvalue is an object that's nearing the end of its life; for the most part this means the result of a function that returns an rvalue reference.
An rvalue is either an xvalue or a prvalue.
An lvalue is an object or a function. This also includes the result of a function where the result is an lvalue reference.
A glvalue (a generalized lvalue) is either an lvalue or an xvalue.
If you want to know more (or if the above doesn't make any sense), see:
http://msdn.microsoft.com/en-us/library/f90831hc.aspx and
http://en.wikipedia.org/wiki/Value_(computer_science)
A pointer stores a memory address. You can have a pointer to a function, a pointer to a class instance, a pointer to a struct, to an int, a float, a double, … you get the idea. You can declare a pointer in either of the two following ways:
int* pSomePtr;
int *pSomeOtherPtr;
Which you use is purely a style thing; the compiler doesn't care. I use the int* syntax, personally.
Note the naming convention of beginning the name of a pointer with a lowercase p. This helps you instantly recognize that the variable you are working with is (or should be) a pointer. Using this naming style helps prevent bugs and helps make bugs easier to spot when they do crop up.
DO NOT DO THIS:
int* pSomePtr, pNotAPointer;
The pNotAPointer variable is not a pointer to an integer. It is just an integer. The same as if you had said:
int pNotAPointer;
The * must be applied to each variable in a comma separated declaration, which is what makes that declaration evil for pointers. When you use a declaration like the above, it's hard for you (and others who look at your code) to know if you meant for pNotAPointer to be a pointer or just an integer (this is one place where the p naming convention helps). It's also easy to repeatedly overlook the missing * and waste a lot of time trying to find the source of the bug.
Because bugs like that are hard to track down, you should never declare multiple pointers on the same line. Put them on separate lines like this:
int* pSomePtr; // Definitely a pointer.
int* pSomeOtherPtr; // Definitely a pointer.
int notAPointer; // Definitely NOT a pointer.
The compiler doesn't care and you will avoid a bad style.
I think the best way to describe using pointers is with documented code. So here's some documented code. Note that some of this code is bad style. I point this out in the comments.
int x; // Creates an integer named x. Its value is
// undefined (i.e. gibberish).
x = 0; // x is now equal to zero rather than gibberish.
int* pX; // Creates a pointer to an integer. Its value
// is undefined (i.e gibberish). If you tried to
// dereference it you would hopefully crash your
// program.
pX = &x; // pX now points to x. The & here means return
// the memory address of x. So pX now holds the
// memory address of x. This & is called the
// address-of operator. There's also an & that
// means an lvalue reference and one that means
// a bitwise AND. You'll learn which is which.
*pX = 1; // Sets x to one. The * here "dereferences" the
// pointer (i.e. lets you operate on the value it
// points to rather than on the pointer itself).
// This * is called the indirection operator.
pX = 1; // Bad – this makes the pointer point to memory
// address 0x01, which (if you are lucky) will
// cause your program to crash. If not you'll be
// randomly changing data the next time you use
// the pointer properly. Worse would be ptrToX++
// since that is more likely to give you a real
// memory address. More on that below.
SomeClass sc; // Create a SomeClass instance using
// its default constructor.
SomeClass* pSc; // Create a pointer to a SomeClass
// instance.
pSc = ≻ // Make pSc point to sc.
pSc->PrintSomeStr(); // This and the next statement are
// identical. The -> operator means
// dereference the pointer then get
// the member named PrintSomeStr. This
// syntax also works for data members.
(*pSc).PrintSomeStr(); // Here we are first dereferencing the
// pointer explicitly (*pSc) and then
// we're using the . operator to get the
// PrintSomeStr member. -> is just clearer
// looking.
pX = &x; // Set pX pointing to x again after the mishap above.
(*pX)++; // This increments the value of x by one. It is
// bad style because of what happens if you forget
// the parentheses.
*pX++; // This DOES NOT increment the value of x by one.
// Instead this increments pX by one. It is the
// exact same result as if you had just written
// pX++; without having the * in front of it. In
// other words this changes the memory address
// pointed to by the pointer, not the value that
// is stored at the memory address. The * is ignored.
*pX = *pX + 1; // This produces the exact same assembly code as
// (*pX)++; and doesn't have the same bug risk of
// accidentally forgetting the parentheses. So
// don't get cute with ++ and --. Just use this
// instead.
int ax[4]; // Declares an array of four integers. The
// values are all undefined. But this is
// not a dynamic array so you don't
// need to wrap it in a unique_ptr or
// anything.
int* pAx = &ax[0]; // Creates a pointer to the first
// element of ax.
*pAx = 0; // Sets the value of the first element of
// ax to 0.
pAx++; // Sets the pointer to point to the second
// element of ax. Arrays are linear in memory
// and the ++ increments the pointer by the
// size of one element (in this case the size
// of one integer).
*pAx = 20; // Sets the value of the second element of
// ax to 20. It effects the same result as
// writing ax[1] = 20; would.
The above code should give you everything you need to know about how to work with pointers. Whether it's a pointer to int or a pointer to SomeClass doesn't matter. When working with an array, incrementing a pointer to the array's first element with ++ can be a lightning fast way to initialize the array. But if you mess up and run past the end of the array then you'll be corrupting memory (and hopefully will crash your program).
One common pattern you'll see in WinRT for delegates and event handlers is this:
_someToken = SomeEvent += ref new SomeEventHandler(
this,
&SomeClass::MemberFunctionHandlerForSomeEvent
);
In C++, class member functions only exist once in memory no matter how many instances of the class you have. This makes sense since the function itself doesn't change for each instance; only the data that it operates on changes. So all the function needs to know is which data to operate one. As we'll see shortly, the C++ compiler takes care of that for us.
(The same is true in C# actually. Or usually true, anyway. The lone difference is that in C# if you've never run or referenced a method then the method probably won't be in memory since it likely hasn't been jitted yet. Once the program needs the method to be in memory it will be jitted and then it will exist once in memory, just like in C++.)
What the event handler constructor code is doing is constructing a delegate that says "hey you event, when you fire I want you to call me, this instance (ergo you pass the "this" pointer to specify that it should use this instance's data) with the class member function that is located at this memory address (which is what using the address-of operator with a class member function does gives you). It's the combination of instance data and the member function's address in memory that lets the event call the right member function with the right data whenever the event fires. (The bit about the token is just a peculiarity with how you unsubscribe from an event in WinRT when using C++.)
Note that we use the scope-resolution operator, "::", when taking the address of the member function. We use this (rather than . or ->) since what we are after is the address in memory of the member function itself, which as we already said is common to all instances of the class. It will make more sense if we briefly examine what happens when a C++ class member function is compiled.
Behind the scenes, when the C++ compiler compiles a member function it automatically adds a "this" pointer as a parameter to all of the instance member functions of our classes. The "this" pointer is a pointer to a particular instance of the class that the member function is a member of. When you call an instance member function the compiler takes that call and uses that instance's location in memory as the value of the "this" parameter that it added. The member function is wired up to use that "this" pointer to access and operate on the correct instance data.
Knowing all of this should help you understand what the purpose of that syntax for the event handler is. When the event is triggered, in order for the event to call the member function we specified it needs the address of the class instance to pass to the member function as the compiler-added "this" parameter. The only way it can know that is if we tell it what the address is. We do that by passing in "this" as a parameter to the delegate constructor. If you wanted some other class instance, then instead of passing in "this" you would pass in &theOtherInstance as the first parameter (using the address-of operator to get its memory address).
References are an attempt to prevent you from shooting your foot off with pointers without removing the ability to pass parameters by reference. They largely succeed but have some inherent limits and are different than .NET references (which really act more like pointers in some ways.
Lvalue references are a way to create a reference to a value. They are useful for passing a parameter by reference rather than copying by value. Like with pointers, some examples will help explain them.
int x = 0; // Create an int named x and set it equal to zero.
int& rX = x; // Creates an integer reference named rX and sets
// it to refer to x. From now on rX acts like x.
x++; // x is now equal to one.
rX++; // x is now equal to two. Note how we didn't need
// to dereference anything. Once rX is assigned a
// value it becomes that value for all intents and
// purposes. You cannot make rX refer to anything
// else.
int &rY; // This is illegal. A reference must be assigned a value
// when it is created. The only exception is in a
// function definition since the value is assigned when
// the function is called or in a class data member
// definition (though I don't see much utility in having
// a data member that is a reference, personally).
// For the following function, by using a reference, we won't
// invoke the copy constructor when calling this function
// since rSc is a reference to an instance of SomeClass,
// not a separate instance of SomeClass. And we'll only be
// passing the size of a reference (4 bytes in a 32-bit
// program) versus the size of the object (44 bytes using the
// definition of SomeClass from the C++ constructors section).
// So references are your friend. In this case, since we won't
// be changing anything in the SomeClass instance, we mark the
// rSc parameter const.
void DoSomething(const SomeClass& rSc)
{
rSc.PrintSomeStr(); // Notice that we use the . operator and
// not the -> operator.
}
Passing parameters by reference (as in the DoSomething function above) prevents memory churning, prevents a constructor from running, and gives us the same behavior as we would expect if we passed a class as a parameter in .NET (i.e. a reference to the same object, not a separate copy of the object).
If you want to pass a copy of the object to a function for some reason then you can. Just leave off the reference marker on the parameter declaration and it will make a copy of the object and pass that copy in when you call the function. If you want to pass a copy to a function that takes a parameter by reference then you need to construct a copy first and then pass the copy in as the parameter when you call the function (since the function definition will only take a reference such that it won't trigger the copy constructor on its own).
We've already seen rvalue references in the C++ constructors. The move constructor and move assignment operator both dealt in them. They use a syntax that looks like this:
SomeClass&& rValRef;
They are only particularly useful for move semantics and as we've already covered that in the constructors section, there's not much more to say about them here. They are new in C++11 but VC++ 2010 supports them.
Templates are sort of like .NET generics except that they aren't. They work to accomplish the same goal (generic programming) but do so in a different way. If you are curious to learn more about how .NET generics work, I recommend reading this interview with Anders Hejlsberg: http://www.artima.com/intv/generics.html . I'm going to focus strictly on C++ templates.
Templates are an integral part of the C++ Standard Library. Indeed, the Standard Library is an outgrowth of an earlier project called the Standard Template Library and it's common to see the Standard Library referred to as the STL.
C++ templates allow you to write classes and stand-alone functions which take in type parameters and perform operations on them. Here is an example:
#include <iostream>
#include <ostream>
template< class T >
void PrintTemplate(T& a)
{
std::wcout << a << endl;
}
What C++ does with this is interesting. The compiler will generate a version of PrintTemplate for each type that you call it with and will then use that version for all invocations of PrintTemplate with that data type. So, for example, if you wrote:
int x = 40;
PrintTemplate<int>(x);
the compiler would create a special int version of PrintTemplate, verify that this version of PrintTemplate can in fact work with an int (in this case making sure that int has a << operator defined for it), and if so create everything. Since everything is generated at compile-time it is very fast at execution time. A downside is that you can get some bizarre error stuff in the output window if you tried to pass in a type that doesn't have a << operator defined (e.g. our SomeClass type). And the build will fail, of course.
Indeed, overloaded operators tend to play a big part in template programming. If you take in two types and try to add them, you need to make sure that there's a + operator defined that adds those two types, otherwise it'll be carnage in your output window.
As far as the syntax goes, you just prefix the function or class with template< … > and you are set to go. You can pass as many or as few types as you want. The "class" keyword in there includes classes, structs, and built-in types like int (it likely includes unions too, though I have not tested that). The letter T is just a style convention, the same as in .NET; you can use anything as an identifier.
You can also use concrete types if you like, but then you need to pass a constant value in as the type parameter when invoking the template function/class.
Separate multiple types with a comma.
It's very easy to mess up template syntax and figuring out what you did wrong is a process of looking at the error message, looking up the compiler error number on MSDN, and trying to fix it based on what the error means. If you get stuck, try reading through the MSDN reference documentation on templates: http://msdn.microsoft.com/en-us/library/y097fkab.aspx .
Don't create macros. You'll shoot your eye out. See, e.g.: http://msdn.microsoft.com/en-us/library/dy3d35h8.aspx (halfway through the Remarks section). If you're thinking about something that you think might make a good macro, use an inline function instead.
(Mind you, don't intentionally avoid macros that exist within headers that come with the Windows SDK or other SDKs and toolkits you decide to use. Just be aware of the fact that there can be unintentional side effects with macros like in the MSDN example above so avoid code with the potentiality for side effects when using a macro (. Keep it simple.)
Do, however, use other preprocessor features. For example, you should always put
#pragma once
at the top of all header files you write to make sure they are only processed once no matter how many files #include them. That notation is a Microsoft-specific thing, btw. You could also use the ISO-compliant
#ifndef __SOMECLASS_H_
#define __SOMECLASS_H_
// Your header file code here.
#endif
style. It’s up to you; I use the #pragma syntax since I don’t need to worry about name collision that way. If you use the ISO-compliant syntax and somehow ended up with two files with the same name and forgot, you’ll need to patch up the resulting error from the one file not being included due to the symbol already being defined by the previously included other file. One way to avoid that problem would be to bake in any namespaces or directory paths into the symbol names, e.g. __SOMENAMESPACE_SOMECLASS_H_. You also need to make sure all the header file code is inside the region between the #define … and the #endif if you use ISO-compliant syntax.
Go watch Herb Sutter's excellent //build/ conference presentation, "Using the Windows Runtime from C++": http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-532T . It's a little over an hour long and will give you good insight not just into C++/CX but also into WinRT and Metro style app development in general.
C++ Component Extensions are a set of language extensions that make it possible to interface with the Windows Runtime and to write components that can be used from languages like C#, VB, and even JavaScript.
The two most common things you will see are the hat symbol '^' which is basically a WinRT pointer and the ref keyword (used in defining a WinRT class and instantiating a new instance of them). WinRT classes are automatically reference counted so you do not need to worry about putting them inside a unique_ptr. Instead you instantiate them like this:
auto someRTClass = ref new SomeRTClass();
The use of 'ref new' is necessary to create a WinRT class instance.
You only need to write a WinRT class if you are writing a WinRT component that's meant to be used as a library in some other application. You don't need to do this for classes that are directly in your game/application (though you can if you want; there's some overhead due to the automatic reference counting but it shouldn't be all that bad).
The following is an example of a WinRT class:
#pragma once
#include <unordered_map>
#include <collection.h>
using namespace Windows::Foundation;
using namespace Windows::Foundation::Collections;
namespace SomeComponent
{
public ref class SomeRTClass sealed
{
public:
SomeRTClass()
: someStr_(L"")
, someInts_(ref new Platform::Vector<int>())
{
// Do nothing
}
~SomeRTClass() { }
property Platform::String^ SomeStr
{
Platform::String^ get() { return someStr_;}
void set(Platform::String^ value) { someStr_ = value; }
}
int GetKeyedNamesCount(void) { return m_keyedNames.size(); }
Platform::String^ GetKeyedName(int key)
{
try
{
return ref new Platform::String(m_keyedNames.at(key).data());
}
catch(...)
{
throw ref new Platform::FailureException();
}
}
void SetKeyedName(int key, Platform::String^ value)
{
m_keyedNames[key] = std::wstring(value->Data());
}
property IVector<int>^ SomeInts
{
IVector<int>^ get() { return someInts_; }
}
private:
Platform::String^ someStr_;
Platform::Vector<int>^ someInts_;
std::unordered_map<int,std::wstring> m_keyedNames;
};
}
Anything in your component's public interface needs to deal in WinRT types (including fundamental types such as int; see: http://msdn.microsoft.com/en-us/library/windows/apps/br212455(v=vs.110).aspx ).
Public collection types must be WinRT interfaces to collection types (i.e. IVector<T> instead of Vector<T>).
Private code can use non-WinRT types such as std::unordered_map.
Also, the sealed keyword is only necessary to use the WinRT component in JavaScript.
If you ever did any managed C++ coding, you will likely notice that C++/CX syntax is pretty much the exact same syntax as managed C++. Microsoft elected to reuse the syntax since it had already been approved as a language extension by the ECMA standards organization. But C++/CX is entirely native; .NET is not involved and there is no GC running in the background (WinRT classes are automatically reference counted, remember).
For more on C++/CX and WinRT (including all of the rules governing WinRT components), I recommend checking out http://dev.windows.com/ (especially the Visual C++ reference for Windows Runtime page - http://msdn.microsoft.com/en-us/library/windows/apps/br229567.aspx ).
If you're using VC++ 2010 Express for the first time, there are a few settings changes I recommend making (especially if you are coming from C#).
First, in the "Tools" menu under "Settings" switch to "Expert Settings". I recommend this for all Express SKUs of Visual Studio.
Next, in "Tools"->"Options…" under "Environment"->"Keyboard" switch the drop down menu from "(Default)" to "Visual C# 2005". This will prevent you from going crazy when F6 doesn't compile. If you are more comfortable with a different key mapping, use that one instead. The point is to switch to keys that you are familiar with.
While in "Options…" change any other settings you like. One thing I like to do is under "Text Editor"->"C/C++", in "General" I like to turn line numbers on and in "Tabs" I've taken to setting "Insert spaces" rather than "Keep tabs".
If you’re using almost any of the Visual Studio keyboard mappings, typing Ctrl+J will bring up IntelliSense. In VS11 IntelliSense should appear automatically in C++. In VS 2010 and earlier, you need to manually invoke it.
I’ve never made too much use of code snippets, though I find myself using them more and more since I learned that the magic secret to accepting the parameters and starting to code is just to hit Enter.
Code snippets are a new feature for C++ in VS11; they don’t exist in earlier versions. If you’ve never used them (in any language), in a C# project start typing ‘for’ to begin a for loop but once IntelliSense has chosen the for snippet, press the Tab key twice and watch as a for loop appears complete with automatic fields that you can edit (use the Tab key to switch between fields). When you’re done editing the fields, press Enter and the cursor will be transported within the loop body with the field edits you made (if any) accepted and appearing now as normal text.
In C++, it's usually not enough to just include a header file. Normally you need to tell the linker to link against a library that implements the code that is declared in the header file. To do this, you need to edit the project's properties, accessible as "ProjectName Properties…" in the "Project" menu. In the properties, under "Configuration Properties" -> "Linker" -> "Input", one of the fields is "Additional Dependencies". This is a semi-colon separated list of the .LIB files you need to link against. It should end with
%(AdditionalDependencies)
so that any additional libraries that are linked via MSBuild are properly added. For a typical DirectX 11 Metro style game you might see the following:
d2d1.lib; d3d11.lib; dxgi.lib; ole32.lib; windowscodecs.lib; dwrite.lib; xaudio2.lib; xinput.lib; mfcore.lib; mfplat.lib; mfreadwrite.lib; mfuuid.lib; %(AdditionalDependencies)
A precompiled header (PCH) is a special type of header file. Like a normal header file, you can stick both include statements and code definitions in it. What it does differently is that it helps to speed up compile times. The PCH will be compiled the first time you build your program. From then on, as long as you don't make any changes to the PCH or to anything that is #included in the PCH, the compiler can reuse its pre-compiled version of the PCH. So don't stick anything in it that is likely to change a lot. But do add things that are unlikely to change. This way your compile times will speed up since a lot of code (e.g. Standard Library headers) will not need to be recompiled every build.
If you use a PCH, you need to #include it at as the first include statement at the top of every CPP file (but not at the top of header files). If you forget to include it or put some other include statement above it then the compiler will generate an error. This is just a result from the way the compiler needs to see PCHs in order to make it work.
If you want to view (a very close approximation of) the assembly code that your code is compiled down into, in your project’s properties, under "Configuration Properties"->"C/C++"->"Output Files" set the "Assembler Output" option to something other than "No Listing".
I’d recommend either "Assembly-Only Listing (/FA)" or "Assembly With Source Code (/FAs)". I normally use the former; it sprinkles enough line number comments that I can cross-reference to see what code I’m dealing with. The latter can be helpful if you want one place to see it all rather than flipping back and forth between whatever you’ve opened the .ASM file in (I use Notepad++) and Visual Studio.
Note that the assembly that is generated uses MASM macros (you can look them up on MSDN). If you don’t know what a particular assembly instruction means (e.g. LEA), you can search the internet for it or try downloading the appropriate programming manual from Intel’s site (assuming x86/Itanium) or AMD’s site (assuming x64) or ARM Holding’s site (assuming ARM). If you’ve never learned any assembly, I definitely recommend it (try just creating a simple Windows Console app). The course I enjoyed most out of all the Comp Sci classes I took in my undergrad minor in CS was where I learned MIPS asm.
Chances are if you come across a build error that looks completely horrible, it’s from the linker. You’ll see messages like this, for instance:
Error 2 error LNK2019: unresolved external symbol "public: __thiscall SomeClass::SomeClass(wchar_t const *)" (??0SomeClass@@QAE@PB_W@Z) referenced in function "void __cdecl DoSomething(void)" (?DoSomething@@YAXXZ) D:\VS2010Proj\CppSandbox\CppSandbox\CppSandbox.obj CppSandbox
All that’s saying is that it cannot find some function you said it should be able to find. In this case, I added the ‘inline’ keyword to a constructor function definition that was in the CPP file without remembering to relocate that definition to the header file. Any inline functions need to be in the header so that the linker won’t hate you.
All those ?? and @@and weird letters are just the way that C++ mangles names when it has compiled code into object files. Name mangling is internally consistent for the compiler in question but the ISO/IEC standard doesn’t mandate any particular schema for name mangling such that different compilers can (and often will) mangle things differently.
Anyway, normally if you see some sort of horrifying build error message, chances are good that it’s from the linker and that it’s an unresolved symbol error. If so, if it’s saying it can’t find something that you wrote (in the above case my SomeClass::SomeClass(wchar_t const *) constructor function (I always write ‘const type’ not ‘type const’ so even that bit is reconstructed)) then check to make sure that your declaration (in the header file) matches the definition (usually in the code file but maybe you put it in the header or maybe you forgot to write it or maybe you declared it inline but still have it in the code file). If it’s someone else’s function (or other symbol), then chances are that you didn’t tell the linker about the .lib file that contains it.
In .NET you just add a reference to an assembly and you get both the declaration bits and the actual definition stuff all in one. In C++, the declaration is the header file while the definition stuff (excluding inline stuff, which needs to be in the header file too) is in a separate library. See above about including libraries. Search the MSDN library for the symbol that it’s telling you it is missing and see if you can find the name of the library file you need to add.
C++ build errors can look pretty scary. Especially when you get a build error involving a template… those can make you want to quit. But don’t. Never let the horrible error messages win.
First figure out if it’s coming from the compiler (it’ll have a C#### error number format) or the linker (LNK#### error number format).
The compiler usually means some sort of syntax error. Check to see things like whether you forgot the #pragma once at the top of your header file. Another problem could be where you are using something from the standard library (e.g. ‘endl’) but forgot to have either a #using namespace std; or else to prefix it with std:: (i.e. ‘std::endl’). You can do either (or both) but must do at least one. And some things might be in a different namespace (in VS 2010, some functionality is in the stdext namespace, for example). The same goes for any namespaces you might be using in your own code.
If you aren’t having any luck on your own, try going on MSDN and typing in the first part of the error message. Chances are good that you’ll get some helpful links to discussions on the MSDN forums, on StackOverflow, perhaps an MSDN article or an MSDN blog post, … maybe even just the error code’s page itself will have the hint you need. If all else fails, post a question on a forums site (MSDN, the appropriate StackExchange site, the App Hub).
A linker error is typically an unresolved symbol, which usually means you either have a mismatch in declaration and definition, have an inline outside of its header, or else don’t have the right library added to the project’s extra dependencies in the project’s linker options. If it’s something else, try the strategies from the previous paragraph; they apply just as well to linker errors as to compiler errors.