reduce number of comparision operator overloads; c++17

[silver wing]

I have several operator overloads that can be simplified to

bool operator OP (const Rational& lhs, const Rational& rhs)
{
  if(lhs.denominator == rhs.denominator)
    return lhs.numerator OP rhs.numerator;

  const int n_l = lhs.numerator * rhs.denominator;
  const int n_r = rhs.numerator * lhs.denominator;
  return n_l OP n_r;
}

is it possible to generate all of them at once using something from c++ or do I have to use macros?

note that i have to stick with c++17 so i cannot use operator<=>

[waxen bone]

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question run !howto ask.

[desert nacelle]

all you need is < and ==
!= => !(x==y)
>= => !(x<y)
<= => (x<y)||(x==y)
> => !(x<=y)

[vernal rivet]

I don't entirely understand the question

what is OP and what does it mean to do int OP int

[desert nacelle]

OP is a comparison operator

[vernal rivet]

how do you know?

[desert nacelle]

per the title and reference to operator<=> in the question body

[vernal rivet]

oh yeah, titles are a thing, aren't they

usually they are shit so I don't read them 😆

[desert nacelle]

lol

[vernal rivet]

you can turn the first 4 lines into a separate function because they never change

tuple<int,int> unifyFractionDenominators(const Rational& lhs, const Rational& rhs) {
  if(lhs.denominator == rhs.denominator)
    return { lhs.numerator, rhs.numerator};

  const int n_l = lhs.numerator * rhs.denominator;
  const int n_r = rhs.numerator * lhs.denominator;
  return { n_l, n_r };
}

at least, if I have correctly assumed what you're trying to do

return lhs.numerator OP rhs.denominator; this bit is probably wrong

shouldn't those both be numerators?

[round plover]

The logic in your code scares me dude

[vernal rivet]

this is not helpful

also, if that scares you, wait until you get to the real world

[round plover]

I said in a sarcastic way

@vernal rivet humour bro ?

[silver wing]

yea but thats not really what i want in this case and this would require more operations than simply having function for each operator

[vernal rivet]

doesn't make it helpful

also you forgot your </sarcasm> tag

[round plover]

@silver wing would be better if you post actual code instead of pseudo code

[silver wing]

oh yea it is and i fixed it but i forgot to update code here mb

[round plover]

You, meet me outside

[silver wing]

the real code is exactly the same except instead of OP there is operator like < or >=

[silver wing]

hm this is pretty nice way to do it and i may need this function elsewhere

[round plover]

Do you mind updating your code in the first post or posting your fixed code ?

[silver wing]

edited the post

[silver wing]

although for other uses i would need to also return the denominator but thats not a problem

[vernal rivet]

with a tuple, then your comparison funcs all become basically two lines, something like this

bool operator>(const Rational& lhs, const Rational& rhs) {
  auto [ nl, nr ] = unifyFractionDenominators(lhs, hs);
  return nl > nr;
}

I guess a better name there might be unifyFractionNumerators because it's actually returning numerators, idk

somewhat subjective

the premise is all because the denominators are might be different

but you're returning numerators, so... 🤷

[desert nacelle]

i don't see why, if you're already doing all the logic in the helper function, you don't go all the way and do all the logic

bool do_op(const Rational& lhs, const Rational& rhs, std::function<bool(const int, const int)> OP) {
  if(lhs.denominator == rhs.denominator)
    return OP(lhs.numerator, rhs.numerator);

  const int n_l = lhs.numerator * rhs.denominator;
  const int n_r = rhs.numerator * lhs.denominator;
  return OP(n_l, n_r);
}

bool Rational::operator<(const Rational& other) const {
  return do_op(*this, other, std::less<int>{});
}
bool Rational::operator<=(const Rational& other) const {
  return !do_op(*this, other, std::greater<int>{});
}
bool Rational::operator>(const Rational& other) const {
  return do_op(*this, other, std::greater<int>{});
}
bool Rational::operator>=(const Rational& other) const {
  return !do_op(*this, other, std::less<int>{});
}
bool Rational::operator==(const Rational& other) const {
  return do_op(*this, other, std::equal_to<int>{});
}
bool Rational::operator!=(const Rational& other) const {
  return !do_op(*this, other, std::equal_to<int>{});
}

[round plover]

Impressive

[silver wing]

oh thats even nicer

[round plover]

Thats how I did it in my code

[silver wing]

does any approach here have overhead or is everything inlined and does not differ from plain function?

[vernal rivet]

check the resulting assembly and find out, you can do this on https://godbolt.org

or with some clevery jumpy through hoopy using compiler flags

generally it's likely that compilers are good at optimizing things away

sometimes too good in fact

[silver wing]

Alr

[vernal rivet]

godbol might be a good name for a russian black metal band 😉

[silver wing]

Too good?

[vernal rivet]

yes

[vernal rivet]

it might optimize something away when you didn't want it to

like doing a release build with extracted .pdb files, the compiler will probably optimize away vars you might have only had there for debugging purposes, making it more difficult to debug

or when doing performance benchmarking and profiling, the compiler is likely to optimize away all your code if that code doesn't "actually do something"

like

int main() {
  int x = 0;
  int y = x + 2;
}

[desert nacelle]

something something volatile
(never rely on volatile)

[vernal rivet]

this code will probably optimize down to nothing

because the variable y is unused

and if y is unused, then x is also unused

but if you wanted to benchmark the performance of +

[silver wing]

Oh in this sense

[vernal rivet]

then that's not very useful

[silver wing]

Yea had some problems with that

Alr thanks

[vernal rivet]

now this ofc, only applies if you have turned on optimizations like with -O2 and friends

but still

google benchmark has a DoNotOptimize() function specifically for this purpose

https://github.com/google/benchmark

[desert nacelle]

but if you're benchmarking, it really only makes sense to do so with compiler optimizations

[silver wing]

I don't think benchmarking makes that much sense without optimizing, unless turning off specific optimizations

[vernal rivet]

indeed

it makes no sense

like, literally none

[vernal rivet]

I guess my main reason to mention this is that godbolt does not have -O2 enabled by default

so it could be easy to miss this and make erroneous assumptions about the resulting assembly

[silver wing]

Oh that's not a problem I've used it before

!solved