One big thing I've learnt is to design classes from the outside in. Design the interface before you even start thinking about the implementation. This will make the class much, much more intuitive for your users (those using the class) than writing the underlying algorithms and building up the class, and writing new public member functions as they are needed.
1. Singleton
You restrict the number of instances because the constructor will be private meaning only static methods can create instances of that class (there are other dirty tricks actually to accomplish that but let's not get carried away).
Creating a class that will have only 2 or 3 instances is perfectly feasible. You should be using singleton whenever you feel the necessity to have only one instance of that class in the entire system. That usually happens to classes that have a 'manager' behavior.
If you want to learn more about Singletons you can start in Wikipedia and particularly for C++ in this post.
There is definitely some good and bad things about this pattern but this discussion belongs somewhere else.
2. Abstract Classes
Yes, that's right. Only a single virtual method will mark the class as abstract.
You'll be using those kind of classes when you have a bigger class hierarchy in which the top classes should not really be instantiated.
Let's supposed you're defining a Mammal class and then inheriting it to Dog and Cat. If you think about it, there's no much sense to have a pure instance of a Mammal since you first need to know what kind of Mammal it really is.
Potentially there's a method called MakeSound() that will only make sense in the inherited classes but there's no common sound that all mammals can make (It's just an example not trying to make a case for mammal's sounds here).
So that means Mammal should be an abstract class since it will have some common behavior implemented to all mammals but it's not really supposed to be instantiated. That's the basic concept behind abstract classes but there's definitely more to it that you should learn.
3. Interfaces
There are no pure interfaces in C++ in the same sense that you have in Java or C#. The only way to create one is by having a pure abstract class which mimics most of the behavior you want from an interface.
Basically the behavior you're looking for is to define a contract where other objects can interact with without caring about the underlying implementation. When you make a class purely abstract it mean all implementation belongs somewhere else so the purpose of that class is only about the contract it defines. This is a very powerful concept in OO and you should definitely look more into it.
You can read about the interface specification for C# in MSDN to have a better idea:
http://msdn.microsoft.com/en-us/library/ms173156.aspx
C++ will provide the same kind of behavior by having a pure abstract class.
Best Answer
Delegation can be achieved in C++ by using functors (made even more simple to declare in C++11 with lambdas). Any type can define a call operator member function, so you could say that C++ does have Delegation, just not in an easy syntax, but fixed with lambdas.
To be more precise (see comments), lambda don't act as delegate, functors - that are simply objects you can call like function and therefore move around until you need to call them - act as delegates. Lambdas expressions are just syntactic sugar allowing to define "in place" a functor directly in the code that will use it. Look in the wikipedia page for lambda for an introduction, it's the same as in C# or Python but a bit more powerful because you can put more than one-liners in.
MetaClass is harder but not impossible : look for reflection libraries for similar features. However, it's very rare that such features are really useful in C++ as you can read there the reasons. Most of the time, RTTI is enough.