I am aware of the singleton pattern in C++, but how do you get two instances of an object? Is there any such pattern where we could easily get two objects?
For the logic I could think of is that I can change the singleton pattern itself to have two objects created inside the class. This works, but if the requirement grows like if I need 3 or only 4 objects, what design pattern that would meet such a requirement?
I would be hard pressed if you could really come up with compelling use cases for this pattern. General consens is already shifting to singletons as an antipattern for exactly the reasons you already mentioned: It is hard to generalise it into more instances and isn't different from global variables (We already established this as an antipattern, right?)
Maybe you should think your design through or come up with an compelling example for this.
This seems more like a need for an Object Pool, try and move away from global objects.
The singleton design pattern creates - by definition in the GoF book - an object with only one instance. An example would a singleton representing the system clock; multiple objects in this case, each representing the clock wouldn't make sense.
Maybe it would be possible to implement some kind of factory method for creating Singleton objects, up to a fixed number. But I think that's well outside the specification of the original Design Pattern.
Maybe have a look at "Modern C++ Design" by Alexandrescu - it has an excellent chapter on Singletons.
There are specific advantages to there only ever being one of an object. Just for one example, even in a multi-threaded environment, if you can guarantee that there's only ever one object that has access to some data (i.e., that class' private data) then you can modify the data without using a mutex/critical section/whatever. As soon as you allow more than one object (no matter what other number you pick) you've lost the fundamental quality that makes a singleton interesting.
Almost any other number results in something like a fixed-size collection. If you need to support a multi-threaded environment, you can use a counted semaphore to control creation of objects. Otherwise, you might use something like an array of objects, with a mutex controlling access to each.
If you don't need to support multi-threading, a simple counter should be adequate.
In software design there is the principal that "there are only three numbers: 0, 1, and infinity", meaning that arbitrary limits are bad. There are sometimes good reasons for having only one of a resource (for instance a log file). As soon as you have more than one, any arbitrary limit will eventually be a problem. So if you need more than one of some resource or object, you will want a pool that can contain an arbitrary number. You also need some way to select which resource to hand out of the pool.
Why not use an array (if the size is going to be static) or a List (if the size is not going to be static)?
I do agree with the sentiment of 0, 1, or infinity; however, from a pure implementation standpoint, this is a perfect use case for arrays. You can even create a wrapper for your array so the consumers don't know you're using an array. I can see usages of this in a queueing or pooling scenario.
If you need multiple instances of the same object, you can use an Object Pool.
If you need a map of many Singleton objects, you can use the Multiton pattern.
class myclass {...};
myclass obj1;
myclass obj2;
Sometimes, the simple approaches really are the best. You don't need to enforce that only one, two, thirteen or seventy-eight instances can exist.
Just create two instances if you need two.