Forwarding constructors

[Ch1156]

Well i dont know if i will or not but i want to be prepared just in case, i dont see why i wouldnt, video games usually have those kinds of heirarchies in them when it comes to classes. Ill take a look at those books too. Does my code look fine? Is there any issues in it?

[newbieg]

I really like the choice of a fall() function, an action/reaction that can happen not just to any animal, but just about any object in the world.

Now, looking at your code, there is one thing I would suggest, which is to move most of the member variables out of the "access specifier" private: and into protected: which would allow your inheriting classes to modify those values.
Doing so will allow the cat class to directly define it's mType = "Cat".

The reason I would place something under private access in an inheritance scheme is if there is something that only the base class should have access to. For instance, an object "ID" which confirms the order in which objects are created. If modifying the variable outside of the base class would break its functionality, then it should be private.

Edit:
Never mind, I forgot your initial goal was to forward the constructor. Using "protected:" is not necessary in that case, though I don't think it would be wrong to do so.

[seeplus]

The switch statement in operator<<() can be replaced with a simple std::unordered_map. Consider:

#include <iostream>
#include <unordered_map>

enum class EyeColor {
	White, Gray, Yellow, Blue, Brown
};

std::ostream& operator<<(std::ostream& os, EyeColor ec) {
	using enum EyeColor;
	const static std::unordered_map<EyeColor, std::string> eyes {{White, "White"}, { Gray, "Gray" }, { Blue, "Blue" }, { Brown, "Brown" }};

	if (const auto fnd { eyes.find(ec) }; fnd != eyes.end())
		return os << fnd->second;

	return os << "Error";
}

int main() {
	std::cout << EyeColor::Blue << '\n';
}

[Ch1156]

So ive made some more changes to the code, i havent yet implemented the unordered_map yet, but here is my code, i have it on github now, its simply too large to post here. Theres still some work to be done, I need to add more error handling for the hunger, thirst and fatigue functions and maybe add better information display, perhaps add the ability to feed the animals. Also the Increment hunger/thirst/fatigue are never used yet, i just added them for future use.

https://github.com/ChayHawk/Smart-Pointers-and-Polymorphism/blob/development/Smart%20Pointers/Smart%20Pointers.cpp

Is everything looking ok? Im still a bit unsure on what to make pre virtual vs just virtual. I know that pure virtual means theres no definition and you want to force the derived classes to implement a definition for the functions, so i did my best on that one.

[Peter87]

Ch1156 wrote:

Also the Increment hunger/thirst/fatigue are never used yet, i just added them for future use.

Something seems wrong with the implementation. It's not clear to me whether you want to limit amount that you're incrementing with, or if you're trying to limit the total value, but it's not doing either.

Cow cow("", "", "", "", 0, 0, 4, 0, {});

std::cout << cow.GetHunger() << "\n"; // "4"
cow.IncrementHunger(5);
std::cout << cow.GetHunger() << "\n"; // "9"
cow.IncrementHunger(5);
std::cout << cow.GetHunger() << "\n"; // "14" (total is now above 10)
cow.IncrementHunger(5);
std::cout << cow.GetHunger() << "\n"; // "19" (total is now above 10)
cow.IncrementHunger(50);
std::cout << cow.GetHunger() << "\n"; // "10" (incrementing by 10 or more sets the total to 10) 

Also note that the "Decrement" functions doesn't prevent the total from becoming negative in case that is what you intended.

[Ch1156]

yeah i didnt implement those correctly yet, i need to re work them, i plan on doing that today.

[Ch1156]

Ok so i did a lot of work on this code, let me know if theres anything wrong or anything else i should know.

https://github.com/ChayHawk/Smart-Pointers-and-Polymorphism/tree/master/Smart%20Pointers

Theres a few bugs i need to sort out witht he information displaying oddly sometimes, but i think overall its looking better.

I tried to make the code look nice as well. Im interested in some feedback on it.

[Peter87]

It's difficult to comment on the design because it seems like you're just testing things out without any real requirements about what the program is actually supposed to do.

In a real program the requirements would influence the design and if the requirements changed then you might also have to change the design.

For example, in a simple console game it might be enough to call a single function to handle the act of "eating" but in a graphical game "eating" might be a much more complicated process because it involves playing an animation and possibly sound. It doesn't just happen all at once but instead it happens over a period of time and it might happen at the same time as other things are going on. It might even be possible for some actions to interrupt the "eating" (e.g. if the player or some other animal attacks).

------------------------------

I notice you use std::cout quite a lot. In a real program I wouldn't expect it to be used quite so frequently.

Is the purpose of the function to return a value or do something other than printing? In that case I wouldn't normally expect it to print anything.

To me it seems a bit inconvenient to have the Increment and Decrement functions (sometimes) print something.

You have written the following line:

std::cout << GetName() << " ate some food and gained -" << DecrementHunger(1) << " hunger!\n";

Imagine if DecrementHunger(1) printed something (which it will if the hunger reach zero). Then it wouldn't print what you expected, would it?

You might see something like:

Bessie ate some food and gained -Bessie is not hungry.
0 hunger!

Another function I wouldn't expect to print anything is IsNull. I'm not even sure what the purpose of this function is when you can just compare the pointer directly.

if (IsNull(animal) == false)
if (animal != nullptr)

[Ch1156]

Yeah im mainly just testing things out, but im going to start on an actual console game now, then ill post that for review.

You might see something like:
Bessie ate some food and gained -Bessie is not hungry.
0 hunger!

Im aware of that issue, i saw that during a test, I should probably just rework that entire output system.

Another function I wouldn't expect to print anything is IsNull. I'm not even sure what the purpose of this function is when you can just compare the pointer directly.

another oversight of mine, i guess i just didnt think of that haha, but thats why im glad i got it reviewed, lots of things to work on.

[seeplus]

In general a function should do what its name implies - with preferably no side-effects (eg display a message when updating a value). What you need to be careful of is to have a function perform a side-effect if eg a particular bool arg is set to true. In general this is bad design! You can end up with a plethora of function args and unwieldy code.

See F1, f2 and F3 of C++ guidelines:
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-logical