2) I can see how AI automation can cause an injustice to the student and impede learning. At the same time one might be temporarily grateful for it during time of essence scenarios, and especially with multiple courses and/or work. I would always prefer the long and hard way to learn, but options during crunch time.
1) Peter, interesting stuff here. Let me take one small step back before I micro-analyze all of your content.
For when comparing a "list" vs "set":
A) inline:
I should not need to inline the binary predicate for a "list", but the compiler will inline it for me if it deems it optimizing, right? I provided the set of elements and so it has everything it needs to optimize and inline it. If so, then both set & list have the same outcomes with inline by the compiler. If the elements require inputs from the user, then both the set and list might not inline and optimize. So as far as I can tell both set and list have the same outcome.
1 2 3 4 5
|
template<typename T>
inline bool SortDescendList(const T& lhs, const T& rhs) //NO need to add inline, as compiler can do it
{
return (lhs > rhs);
}
|
But yes, if I want to brute force an inline and make sure in case compiler decides otherwise.
B) The addition of the Descending Binary sort predicate weighing down the "set" or "list".
The "set" uses the elements as the actual key to automatically sort in ascending order for a binary tree, and thus needs and requires the std::less binary predicate. I did not look it up and it is probably a struct or class with operator(). Since it NEEDS to sort, then the std::less is used regardless if you want it to or not, so it is weighed down already.
The "list" has its own sort() in ascending default and is weighed down already too.
So, lets focus on the descending addition then.
1 2
|
set<int, SortDescend<int>> s2{ 2,5,1,3,2,1,4 }; //For set
l1.sort(SortDescendList<int>); //For list
|
So they both get weighed down when I use the SortDescend. So in that respect, they are both the same to me. The only difference is the "set" is a binary predicate operator() within a struct/class. I also understand though that since they used std::less in a way that uses a struct/class with operator(), then they want you to follow a similar protocol and expect you to use the same and they did not want to overload any other options for us.
So then if my assumptions about A & B above are correct, and there is something that I am just not seeing now properly about efficiency, then if it is so efficient and better why didn't they force upon us the usage of operator() in a struct/class for a "list"?
I think I may skip the map chapter for now and focus on the function object chapter. A function object is a functor, does that mean it is a function pointer automatically or only when you send a function as a template type "template<typename F>" that it becomes a function pointer? Still not sure what that really means, but your code sample is amazing and I did not know that was even possible!
seeplus, thanks! I actually knew that and left it in because I tested it with a class as well. I also had another section commented out, where I did not include public:.
class: default private, with default private inheritance
struct: default public, with default public inheritance
union: default public, no inheritance
Funny thing is that I was almost going to comment that line "//for class" since you guys are so good and catch/help with everything. That is why I threw in the "auto element" in there too, rather than writing it out, since I knew this group would spot it.