Guys, when is it a good idea to ban constructors and make arrays to pointers to objects instead?

brainlet question what language is this?

The extension is .cpp which means C++

My butchered rendition of C++11

This is irrelevant to your question but you should really indent your fucking code, it's giving my eyes cancer

Indentation is perfectly fine, you mongoloid.

What should I indent and how far?

>Guys, when is it a good idea to ban constructors and make arrays to pointers to objects instead?
For optimisation.

Constructors are helpful when you don't want your callers to have to understand how to create a valid WarFighter object. This is in line with OOP in which you try to encapsulating all behaviour into the object.

Choosing not to have a constructor is fine but *something* needs to understand how to instantiate a valid WarFighter object. Hint: look at creational patterns

>patterns
I'm out of line here.
My idea is to have a commander lead a unit of warfighters, and a general to lead a unit of commanders.
I was thinking of just creating an array of soldiers and using the other two classes as permission and functionality granters. Dunno what it's called.
Should I just make a dynamic container class Soldiers and pass that along instead?

You really want to invest some time to read this: gameprogrammingpatterns.com/

It's not the shit they cram down your throat in school and actually easy to follow.

>I was thinking of just creating an array of soldiers and using the other two classes as permission and functionality granters.
A lot of times when thinking about modelling and running into difficulty, it's because you're missing an abstraction/concept. Also thinking about data(collections of stuff) and behaviour and who should own the behaviour is helpful.

Can a collection of warfighters exist independently of commanders/generals? That's a pretty good case to abstract it out on its own.

Should warfighters receive commands from commanders/generals and then decide how to execute them? What does that imply for their design? It means that they would also need to know to whom they belong.

What's the difference between a commander and general? Are they really different things or just roles that can be assigned? With roles, the behaviour can be re-assigned instead of having a class hierarchy.

I think the command pattern will be helpful here.

Many thanks based user

To further the point and think in clean OOP, ask yourself "what does my object need to do" and "what does it need to know in order to do the thing it needs to do"?

If you don't find a very simple solution, you might be missing intermediate abstractions like "Action", "Command" or "Strategy".

Also try to favour composition over crazy inheritance hierarchies. Lots of shit don't actually map well to the "is-a" paradigm is usually a trap outside of enterprise-y java code.

>not deleting move csontructor
>not deleting copy constructor
>nonvirtual destructor
>using char * in c++
>not using an std container with unique_ptr in the container
kys

It's a garbage book with only theories

>>using char * in c++
Huh? Should I use vloated ass string instead?

Is there a book on actual game engines? I want to make some shitty console prompt roguelike.

You might want to figure shit out yourself if you're making something small.

Attached: 51mQl0y9NGL._SX382_BO1,204,203,200_.jpg (384x499, 54K)

How am I possibly going to figure out windows.h myself? I used to just slam cout 100 times and endl