I am currently reading information from an input file. Of that information, there is a name. All the information is read into a struct. There is an array of these structs.
I need to alphabetize the structs by the last name, using a Binary Search Tree.
Do I need to write an operator overload function for ==, <, and >. If so can someone help me get started on that?
Yes, you will want to write operator overloads for == and <. (> is not needed; just use the else case after checking e.g. if (a < b); else if (a == b).)
In our case, since we are alphabetizing by last name, one struct is "less than" another if and only if its last name comes before the other's last name alphabetically.
So what exactly is the problem? Do you know how to write operator overloads? Do you know how to compare strings and determine which comes first alphabetically?
You need a way to compare any two instances of the struct. Writing a comparison operator, say, operator<(), might be a convenient way to go about it.
class Record {
friend bool operator<(const Record&, const Record&);
std::string name;
// ...
};
bool operator<(const Record& a, const Record& b)
{
// return true if the name of a is less than the name of b
}
Because a node inserts either on the left subtree or the right subtree you only need to know if a node is "less than" another node. If it isn't, then it doesn't matter whether it's greater or equal to the other node; it goes on the other subtree either way.
Of course, you might need the equality comparison for some other task. If you do then it's a good idea to go all the way and provide the inequality operator as well.
Also of interest is the rel_ops namespace.
Operator overloads work just like functions or methods. They get a return type and arguments in just the same way. For instance, a binary operator (like <) would be a member function with one argument or a free function with two, one each for each side of the operator. the only thing that's different is instead of having an identifier function name, they use a special syntax, the keyword operator followed by the operator being overloaded. So if we wanted to have a comparable type, we could do it this way:
class MyUserType
{
private:
std::string sort_significant;
std::string sort_insignificant;
public:
bool operator<(const MyUserType &) const;
};
bool MyUserType::operator<(const MyUserType & other) const
{
return sort_significant < other.sort_significant;
}
You would normally need to overload <, but if there are other elements in the struct that you might sometime want to sort by, it doesn't really make sense to do that. You should write a separate function that accepts two parameters of your struct, and compares them by last name, returning true if the first should come before the second, false otherwise. Then pass that function to a std::sort. Something like this:
bool compare_by_last_name(const MyStruct & lhs, const MyStruct & rhs)
{
return lhs.last_name < rhs.last_name;
}
// later
vector<MyStruct> v;
// put some elements in v
std::sort(v.begin(), v.end(), compare_by_last_name);
You will notice I have ignored your statement "Using a binary search tree", because I don't quite know what you mean, but it's probably irrelevant. Did you make your own container class or something?
Related
I'm having some difficulty with this. I've determined I need to overload this operator for my personal project. It is necessitated by the use of the following line:
if(playerVec[i] == 0)
The player class has several data members for calculating one particular data member, mInitiative. This is the one I want to check in my if condition. Here is my attempt at overloading it:
bool operator==(const Player& lhs) const {
return mInitiative == lhs.mInitiative;
}
It seems fine enough, but the error persists. If I want to compare that particular player datum to an integer (in this case, 0), how do I go about it? What's the mistake in my approach?
EDIT: I have tried:
bool operator==(const Player& lhs, int rhs) const {
//...
}
But the compiler says there are too many parameters for the function. Why is this? Shouldn't == be able to take two?
Thanks!
There are two ways to overload an equality operator: declare it as a member, taking one argument (rhs); or declare it as a global, taking two arguments (lhs and rhs). Since your lhs is a Player, and your rhs is an integer, here are the two ways to define it:
// declared inside Player class as a member
bool operator == (int rhs) const
{
return mInitiative == rhs;
}
// can also be declared inside Player class, but is not a member due to friend keyword
friend bool operator == (Player const& lhs, int rhs)
{
return lhs.mInitiative == rhs;
}
That is leaving aside the style considerations of overloading operators in such a way.
When trying to overload equality operator (i.e. ==), you always need to think about whether the target instances are really the same.
In your case, I think people might be confused when reading the following code if you provide the Player to integer comparison. Since it looks like checking whether a pointer is null or not:
if(playerVec[i] == 0)
Rather than overloading == operator of Player to compare with integer, I would suggest providing a get() function, which allows you to compare Player with integer more clearly. For example:
if (playerVec[i].getPlayerID() == 0)
If you will use some stl function to manage your Player vector (eg. sorting), then you can overload == or > operator for two Player instances.
I have an object of custom type A (a class that has many members which are std::string, vectors etc but no raw pointers).
Now, I have a list of A objects.
A tmpobj;
std::list<A> temp;
If I want to invoke std::list::remove function to remove a specific object from the list
I am trying
temp.remove(tmpobj)
Now, here are my questions
I am assuming i need to overload == operator. Please let me know
if I dont need to and if the default == will work. I am not sure
about that. I know it would work if I did not have any STL based
members
I already have the < operator overloaded. Yet, I think
"==" operator needs to be provided. Is this right. One argument can
be, we can determine "==" as two calls to '<' operator like
if(a < b || b < a)
return false
else
return true;
Or is this not done because its inefficient to do 2 calls or is there any other reason for that.
n3337 23.3.5.5
void remove(const T& value);
template <class Predicate> void remove_if(Predicate pred);
Effects: Erases all the elements in the list referred by a list iterator i for which the following conditions
hold: *i == value, pred(*i) != false. Invalidates only the iterators and references to the erased
elements.
So, you need overloaded operator == or predicate.
There is no default operator==, so don't worry about that. When the compiler complains that your class has no operator==, implement it ;-)
If all the possible values of your class together represent a set with the mathematical property of being "totally ordered", then you could implement operator== in terms of operator<. It's not necessarily the most efficient way, but the main reason that C++ doesn't assume it is that in general it doesn't assume anything about how different overloaded operators should relate to one another. Not all types necessarily represent totally-ordered sets. For better or worse, C++ lets you use operator< to represent a partial order.
I have created a class "firefly" similar to this:
class firefly{
private:
float time_flash;
public:
firefly(int, int, float, float);//parametric constr.
firefly();
firefly(const firefly& a);//copy constructor
void receive_flash(std :: vector<firefly>&, float, float, int);
friend bool operator <(const firefly&) const;
};
Focus on the last two functions; I have two question about them.
In the main program I wanted to initialize a vector of fireflies as follows:
vector <firefly> fire_vec(10, firefly(5, 5,(float) 1., (float)1.) );
using the parametric constructor. Can I do this?
The secondo question.
This vector should be ordered by the algorithm sort,
sort(fire_vec.begin(), fire_vec.end());
having overloaded operator< as follows:
bool operator <(const firefly &rhs) const {return time_flash < rhs.time_flash;}
Is there anything wrong in doing this? (i think there is something wrong, because I can't)
I'm not sure what you're having trouble with, but if you'd tried to compile this code, you'd have found that
friend bool operator <(const firefly&) const;
is illegal: you can't have a const qualifier on a freestanding function. Also, operator< is a binary operator, so it should take two arguments, both of type const firefly &.
You can also implement operator< as a member function, as you suggest yourself, but then drop the friend declaration.
Apart from that, there's nothing wrong with your code, except maybe that sorting a vector of entirely equal elements is a waste of time.
Excuse me but why you choose vector+customized sorting rather than set/map with a customized comparator?
Normally, we use vector mostly due to a requirement on random access its elements via index. If that's not the case and especially in your case, you need a sorted vector, I'd suggest the set/map.
For the second question you will have to pass the overloaded function to sort as an argument
sort (myvector.begin()+4, myvector.end(), myfunction);
Comparing two instances of the following struct, I receive an error:
struct MyStruct1 {
MyStruct1(const MyStruct2 &_my_struct_2, const int _an_int = -1) :
my_struct_2(_my_struct_2),
an_int(_an_int)
{}
std::string toString() const;
MyStruct2 my_struct_2;
int an_int;
};
The error is:
error C2678: binary '==' : no operator
found which takes a left-hand operand
of type 'myproj::MyStruct1' (or there
is no acceptable conversion)
Why?
In C++, structs do not have a comparison operator generated by default. You need to write your own:
bool operator==(const MyStruct1& lhs, const MyStruct1& rhs)
{
return /* your comparison code goes here */
}
C++20 introduced default comparisons, aka the "spaceship" operator<=>, which allows you to request compiler-generated </<=/==/!=/>=/ and/or > operators with the obvious/naive(?) implementation...
auto operator<=>(const MyClass&) const = default;
...but you can customise that for more complicated situations (discussed below). See here for the language proposal, which contains justifications and discussion. This answer remains relevant for C++17 and earlier, and for insight in to when you should customise the implementation of operator<=>....
It may seem a bit unhelpful of C++ not to have already Standardised this earlier, but often structs/classes have some data members to exclude from comparison (e.g. counters, cached results, container capacity, last operation success/error code, cursors), as well as decisions to make about myriad things including but not limited to:
which fields to compare first, e.g. comparing a particular int member might eliminate 99% of unequal objects very quickly, while a map<string,string> member might often have identical entries and be relatively expensive to compare - if the values are loaded at runtime, the programmer may have insights the compiler can't possibly
in comparing strings: case sensitivity, equivalence of whitespace and separators, escaping conventions...
precision when comparing floats/doubles
whether NaN floating point values should be considered equal
comparing pointers or pointed-to-data (and if the latter, how to know how whether the pointers are to arrays and of how many objects/bytes needing comparison)
whether order matters when comparing unsorted containers (e.g. vector, list), and if so whether it's ok to sort them in-place before comparing vs. using extra memory to sort temporaries each time a comparison is done
how many array elements currently hold valid values that should be compared (is there a size somewhere or a sentinel?)
which member of a union to compare
normalisation: for example, date types may allow out-of-range day-of-month or month-of-year, or a rational/fraction object may have 6/8ths while another has 3/4ers, which for performance reasons they correct lazily with a separate normalisation step; you may have to decide whether to trigger a normalisation before comparison
what to do when weak pointers aren't valid
how to handle members and bases that don't implement operator== themselves (but might have compare() or operator< or str() or getters...)
what locks must be taken while reading/comparing data that other threads may want to update
So, it's kind of nice to have an error until you've explicitly thought about what comparison should mean for your specific structure, rather than letting it compile but not give you a meaningful result at run-time.
All that said, it'd be good if C++ let you say bool operator==() const = default; when you'd decided a "naive" member-by-member == test was ok. Same for !=. Given multiple members/bases, "default" <, <=, >, and >= implementations seem hopeless though - cascading on the basis of order of declaration's possible but very unlikely to be what's wanted, given conflicting imperatives for member ordering (bases being necessarily before members, grouping by accessibility, construction/destruction before dependent use). To be more widely useful, C++ would need a new data member/base annotation system to guide choices - that would be a great thing to have in the Standard though, ideally coupled with AST-based user-defined code generation... I expect it'll happen one day.
Typical implementation of equality operators
A plausible implementation
It's likely that a reasonable and efficient implementation would be:
inline bool operator==(const MyStruct1& lhs, const MyStruct1& rhs)
{
return lhs.my_struct2 == rhs.my_struct2 &&
lhs.an_int == rhs.an_int;
}
Note that this needs an operator== for MyStruct2 too.
Implications of this implementation, and alternatives, are discussed under the heading Discussion of specifics of your MyStruct1 below.
A consistent approach to ==, <, > <= etc
It's easy to leverage std::tuple's comparison operators to compare your own class instances - just use std::tie to create tuples of references to fields in the desired order of comparison. Generalising my example from here:
inline bool operator==(const MyStruct1& lhs, const MyStruct1& rhs)
{
return std::tie(lhs.my_struct2, lhs.an_int) ==
std::tie(rhs.my_struct2, rhs.an_int);
}
inline bool operator<(const MyStruct1& lhs, const MyStruct1& rhs)
{
return std::tie(lhs.my_struct2, lhs.an_int) <
std::tie(rhs.my_struct2, rhs.an_int);
}
// ...etc...
When you "own" (i.e. can edit, a factor with corporate and 3rd party libs) the class you want to compare, and especially with C++14's preparedness to deduce function return type from the return statement, it's often nicer to add a "tie" member function to the class you want to be able to compare:
auto tie() const { return std::tie(my_struct1, an_int); }
Then the comparisons above simplify to:
inline bool operator==(const MyStruct1& lhs, const MyStruct1& rhs)
{
return lhs.tie() == rhs.tie();
}
If you want a fuller set of comparison operators, I suggest boost operators (search for less_than_comparable). If it's unsuitable for some reason, you may or may not like the idea of support macros (online):
#define TIED_OP(STRUCT, OP, GET_FIELDS) \
inline bool operator OP(const STRUCT& lhs, const STRUCT& rhs) \
{ \
return std::tie(GET_FIELDS(lhs)) OP std::tie(GET_FIELDS(rhs)); \
}
#define TIED_COMPARISONS(STRUCT, GET_FIELDS) \
TIED_OP(STRUCT, ==, GET_FIELDS) \
TIED_OP(STRUCT, !=, GET_FIELDS) \
TIED_OP(STRUCT, <, GET_FIELDS) \
TIED_OP(STRUCT, <=, GET_FIELDS) \
TIED_OP(STRUCT, >=, GET_FIELDS) \
TIED_OP(STRUCT, >, GET_FIELDS)
...that can then be used a la...
#define MY_STRUCT_FIELDS(X) X.my_struct2, X.an_int
TIED_COMPARISONS(MyStruct1, MY_STRUCT_FIELDS)
(C++14 member-tie version here)
Discussion of specifics of your MyStruct1
There are implications to the choice to provide a free-standing versus member operator==()...
Freestanding implementation
You have an interesting decision to make. As your class can be implicitly constructed from a MyStruct2, a free-standing / non-member bool operator==(const MyStruct2& lhs, const MyStruct2& rhs) function would support...
my_MyStruct2 == my_MyStruct1
...by first creating a temporary MyStruct1 from my_myStruct2, then doing the comparison. This would definitely leave MyStruct1::an_int set to the constructor's default parameter value of -1. Depending on whether you include an_int comparison in the implementation of your operator==, a MyStruct1 might or might not compare equal to a MyStruct2 that itself compares equal to the MyStruct1's my_struct_2 member! Further, creating a temporary MyStruct1 can be a very inefficient operation, as it involves copying the existing my_struct2 member to a temporary, only to throw it away after the comparison. (Of course, you could prevent this implicit construction of MyStruct1s for comparison by making that constructor explicit or removing the default value for an_int.)
Member implementation
If you want to avoid implicit construction of a MyStruct1 from a MyStruct2, make the comparison operator a member function:
struct MyStruct1
{
...
bool operator==(const MyStruct1& rhs) const
{
return tie() == rhs.tie(); // or another approach as above
}
};
Note the const keyword - only needed for the member implementation - advises the compiler that comparing objects doesn't modify them, so can be allowed on const objects.
Comparing the visible representations
Sometimes the easiest way to get the kind of comparison you want can be...
return lhs.to_string() == rhs.to_string();
...which is often very expensive too - those strings painfully created just to be thrown away! For types with floating point values, comparing visible representations means the number of displayed digits determines the tolerance within which nearly-equal values are treated as equal during comparison.
You need to explicitly define operator == for MyStruct1.
struct MyStruct1 {
bool operator == (const MyStruct1 &rhs) const
{ /* your logic for comparision between "*this" and "rhs" */ }
};
Now the == comparison is legal for 2 such objects.
Starting in C++20, it should be possible to add a full set of default comparison operators (==, <=, etc.) to a class by declaring a default three-way comparison operator ("spaceship" operator), like this:
struct Point {
int x;
int y;
auto operator<=>(const Point&) const = default;
};
With a compliant C++20 compiler, adding that line to MyStruct1 and MyStruct2 may be enough to allow equality comparisons, assuming the definition of MyStruct2 is compatible.
By default structs do not have a == operator. You'll have to write your own implementation:
bool MyStruct1::operator==(const MyStruct1 &other) const {
... // Compare the values, and return a bool result.
}
Comparison doesn't work on structs in C or C++. Compare by fields instead.
Out of the box, the == operator only works for primitives. To get your code to work, you need to overload the == operator for your struct.
Because you did not write a comparison operator for your struct. The compiler does not generate it for you, so if you want comparison, you have to write it yourself.
Sometimes I have structs such as this --
struct aggregate1 {
std::string name;
std::vector<ValueT> options;
size_t foobar;
// ...
};
-- where (in)equality is simply defined as (in)equality of all members: lhs_name == rhs_name && lhs_options == rhs_options && lhs_foobar == rhs_foobar.
What's the "best" way to implement this? (Best as in: (Runtime-)Efficiency, Maintainability, Readability)
operator== in terms of operator!=
operator!= in terms of operator==
Separate implementations for == and !=
As member or as free functions?
Note that this question is only about the (in)equality ops, as comparison (<, <=, ...) doesn't make too much sense for such aggregates.
I would do this but maybe move operator== definition to cpp file. Leave operator!= to be inline
Remember to compare member variables that are most likely to differ first so the rest are short-circuited and performance is better.
struct aggregate1 {
bool operator==(const aggregate1& rhs) const
{
return (name == rhs.name)
&& (options == rhs.options)
&& (foobar == rhs.foobar);
}
bool operator!=(const aggregate1& rhs) const
{
return !operator==(rhs);
}
std::string name;
std::vector<ValueT> options;
size_t foobar;
// ...
};
Member or free function is a matter of taste, and writing separate implementations of == and != seems to me boring, error-prone (you may forget a member in just one of the two operators, and it will take time to notice) without adding anything in terms of efficiency (calling the other operator and applying ! has a negligible cost).
The decision is restricted to "is it better to implement operator== in terms of operator!= or the contrary?
In my opinion, in terms of maintainability/readability/efficiency it's the same; I'd only recommend to do it in the same way everywhere for the sake of consistency. The only case where you'd want to prefer to use one or the other as the "base operator" is when you know that, in the types contained in your structure, that operator is faster than its negation, but I don't know when this could happen.
In C++20, implementing equality and inequality operators can be as simple as declaring operator== as default:
struct S {
int x;
// ...
// As member function
bool operator==(S const &) const = default;
// As non-member function (hidden friend)
// friend bool operator==(S const &, S const &) = default;
};
If only operator== is provided, a!=b is interpreted as !(a==b) according to overload resolution, so there is no need for providing an explicit overload for operator!=.
I would argue that defaulting operator== as a hidden friend is preferable because it works with reference-wrapped objects:
S s;
auto rs{std::ref(s)};
rs==rs; // OK for hidden friend; ill-formed if declared as member function
In this example, operator== is not defined for std::reference_wrapper<S>, but argument-dependent lookup (ADL) can select the hidden friend with operands implicitly-converted to S const &. Notice, however, that ::operator==(rs,rs) will only work if operator== is defined as a free function because ADL is not triggered for qualified names.
IMHO, implement as friends and implement the operator== (some STL algorithms will rely on this for example) and the operator!= should be implemented as the negation of the equals operator.
(-: Self answer :-)
I would like to highlight one aspect of aggregates WRT efficiency:
The order of evaluation of op== and op!= is irrelevant for (average) performance.
Assuming separate implementations for now and given the two extremes (a-eq) all subelements equal and (b-neq) all subelements inequal, we have these cases:
(a-eq) + operator== : Needs to compare all sub elements to return true
(a-eq) + operator!= : Needs to compare all sub elements to return false
(b-neq) + operator== : Returns false after 1st sub element is determined inequal
(b-neq) + operator!= : Returns true after 1st sub element is determined inequal
Since performance on average is the same either way it seems -- at least to me -- more natural to implement op!= in terms of op==, as it feels more natural to me to implement the equality op.