It looks like you're trying to set positions every frame (when you draw/update?).
Only set the positions once, e.g. at start-up (or tied to a button press or similar).
You said you wanted to randomly generate x and y, but you never do anything related to random. Here's a reference talking about a simple way to implement random. It also contains links to further reading (<random>).
I'd start there, and try generating random coordinates.
Something you will run into very quickly is the same location being chosen multiple times (causing overlapping blocks), which you will have to deal with somehow.
This can be either by verifying after generating the coordinates that they aren't in use, or maybe having a separate list of coordinates and randomly flag them first before placing, or some other solution.
If you get stuck, post here -- but I would recommend trying to solve it on your own first.
I read it as an example of micro-optimization (which you don't need to care about for the vast vast majority of the time, if ever), not as a "do this for better performance".
Like I said -- there are times when knowledge of the domain area (i.e. the events and flow in your game) can allow you to make highly specialized code which outperforms the code which is fastest overall/in the generic case. For example knowing that objects only collide from the right, or that a unit can never go backwards, or that there can be only 15 dolphin soldiers in a given map.
A generic solution might be better in the case where we have 1000+ dolphin soldiers, but with out intimate knowledge of our game we can perform domain specific optimizations which would otherwise not be the most fruitful.
Again, don't worry about this stuff. At most, make a comment or note saying "this might be a hot-spot we can improve later!", and move on.
Profilers are infinitely better than you (and all of us) at gauging where our bottlenecks are, and trying to optimize everything from the start is a total shot in the dark, which might end up with a slower application in the end.
TL;DR: Don't worry until it's a problem. If it becomes a problem, use a profiler, make changes and verify improvements. Repeat until fast enough.
You mentioned something about what if the objects being tested always come from the right. What did you mean by always come from the right?
If you know specifics of your game, you can make assumptions that make your code perform better in your case than in a general case.
If 90% of the time, collision occurs from a specific side, testing the relevant sides first might end up with a better performance compared to testing the other sides first.
(If collisions are usually left/right, testing up/down first might be slower.)
This is something a profiler would help highlight and pinpoint, and is not likely to be an issue for most cases.
Worrying about this now sounds premature. I would suggest working on the actual game first. Once it's up and running, make changes if necessary, and let those changes be guided by profilers, to meet performance criteria.
Let's say you add an instance of class Soldier to your class MapManager:
In order to know how large MapManager is (how much memory has to be set aside every time an instance of MapManager is created), we need to know all the details of Soldier. Does it just have an int for HP? Does it have 50 floats with all kinds of stats?
In this case, MapManager would need to know both that Soldier exists, and the details of it.
In the case where you have a pointer to it, all you need to know is that it exists (so it understands that "Soldier" is the name of a class and not just random letters). We still need to know how much memory to set aside for the pointer, however, since all pointers are the same size, it doesn't need to know the details of the class. If the class is huge or tiny, the pointer to it will remain the same size.
The reason why you still need to include Soldier.h in the MapManager.cpp file, is because now you're wanting to access the Soldier details -- mySoldier->someFunction().
To access those details, you need to know they exists, hence the reason for the include here.
This also means you can't have 2 classes which have instances of each other inside each other.
In this case, you would need to split things up somehow, so that either 1 class contains a pointer to the other, or to create a new class which contains both of them.
Seems alright on its own. However, looking more closely at your error messages it seems like Soldier has a pointer to MapManager, and MapManager has a pointer to Soldier.
This is most likely causing a circular reference (to know what a MapManager is, you need to know what a Soldier is, which needs to know what a MapManager is, etc).
Since you're only using pointers (at least in MapManager), you can forward declare the Soldier class inside MapManager.h. This basically says "somewhere, there is a class called Soldier. You don't need to worry about the details here, because all we currently want is to have a pointer to it".
Before class MapManager, add
In MapManager.cpp you will need to include the Solider.h file to get the proper contents available to you.
Also of note, I would recommend not putting "using namespace std;" in a header. This can cause namespace pollution -- every file that includes MapManager will now suddenly also inherit the using declaration.
If you need to use using declarations, it's best to put them locally -- in the .cpp file.