27 minutes ago, swiftcoder said:

In practice, if you make your entity class be a pure data container,

Really it perfect serve anywhere where parent component behavior independend from childs and childs behavior independed from siblings. For example for form and controls placed on it. But when dependencies exists it required at lest to make a weak references betwin depended siblings. In case of dependencies of parent behavior it also require usage of delegates and/or mixing container scheme with inheritance scheme to avoid huge access penalties. It makes manual serialization/deserialization  so big problem, so developers of desktop frameworks that use component based scheme has added a RTTI generation to C++ compilers that thay produce too at middle of 90-th. Developers that is no compiler producers uses additional preprocesors/transpillers for it purposes. Also i guess Microsoft has never make *.tlb files for his COM technology manually.

Ok, thanks all of you guys for your advices!  I just accidentally googled on "service-oriented architecture", that suggests not to add any behaviour to the Items, but markers what they can do, and, if somebody will use the item it will be passed to the Service class that will handle all behaviour and Item data changes. Is that may be a good choice to handle this kind of problem?

Something like this:

class InventoryItem
{
public:
	bool isEquipable;
	bool isUsable;
	string itemName;
	string dispName;
	string someData;
	//Some methods shared across all items
	//GetUsages();
};


class ItemProcessor
{
public:
	//Will pass parameters struct to usage if any such as caller, target or something else.
	//Probably should be replaced with a map<actionname, actionReference>.
	static void UseItem(InventoryItem* item,int useIndex,void* usageData)
	{
		switch (useIndex)
		{
		case 1:
			UsageOne(item,usageData);
			return;
		default: 
			return;
		}
	}
private:
	static void UsageOne(InventoryItem* item, void* usageData)
	{
		if(!item->isUsable) //and if item contains this usage marker
			return;
		//do something
		item->someData = "NewData";
	}
};

class PlayerClass
{
	InventoryItem* Inventory = new InventoryItem[5];

	void UseItem(int userInput1, int userInput2)
	{
		ItemProcessor::UseItem(&Inventory[userInput1],userInput2, nullptr);
	}
};

58 minutes ago, MarkNefedov said:

Ok, thanks all of you guys for your advices!  I just accidentally googled on "service-oriented architecture", that suggests not to add any behaviour to the Items, but markers what they can do, and, if somebody will use the item it will be passed to the Service class that will handle all behaviour and Item data changes. Is that may be a good choice to handle this kind of problem?

I've never heard it called that, but yes, that seems roughly equivalent to an Entity/Component system.

13 hours ago, MarkNefedov said:

Is that may be a good choice to handle this kind of problem?

Its looks like a data driven pseudo-polimorphysm. It what same i mean under "make it by 100% data driven way in case set of classes allow it." It able to serve well for tiny set of classes, and say more it has been a mainstream solution on pre-OOP age while sets of behavior varians has been tiny. But with growth of number of behavior variants it becomes to hard to maintain/enlarge  it, and also with growth of behaviors complexity handler of behaviors often became to Turing-full virtual machine.