Spyke
lemmy.world

yes, but in this particular case I wouldn't want to second guess my decrement operation just happens to also be calling the white house or whatnot. Just make a method.

20

That's just life of a C++ programmer: you second guess everything, and there are still optimization you haven't tried, and pitfalls you haven't got into

2

Until the next person with a slightly different mental way of defining things comes along. Or just a future version of you.

14
mkwtreply
lemmy.world

But when you do shoot yourself in the foot, it blows your whole leg off.

5
marcosreply
lemmy.world

Yeah, just to say it more clearly: that kind of thing is why lots of people out there insist that operator overloading is a bad idea.

And yeah, it's a C++ thing that mostly doesn't happen in other languages.

16

Sincerely agree. Explicit is better then implicit, that’s a general engineering axiom.

Instead of overloading and making the next maintainer hunt for overloads, a clearly named function that does the critical steps would make the code immensely more maintainable. C++ is C gone wild.

3

Yes. Sometimes you're limited by the hardware you're controlling. This code is a bit hard to justify with that excuse though. Normally your code would do a read from hardware to see if the value decremented and then repeat the write. (Possibly a sleep/yield in there if required.)

8
piefed.blahaj.zone

If those are normal integers, the compiler optimizes that to a simple compare and branch/cmov.

7

You reached the end

// Implement | Spyke