C++23: The Next C++ Standard

Re:C++23: The Next C++ Standard by mhh__ on Tuesday July 11, 2023 @02:13PM (#36684993)

C++ "bitshifts" (yes, but it's just a symbol in this context) make no real difference to me. It was type safe when it wasn't easy to be back in the day, everyone knows exactly how they work - it's never shot me in the foot (whereas the real meat of the design has, independently of how the composition is expressed syntactically).

The others are more sus but you can make a bad API out of anything.

Rewriting (say) a load of calculations as a tree of sum pow exp etc. is just a huge burden - a codebase I work on has a formula that takes up about 6 lines for example, outputted by mathematica: total pain to to translate to function calls.

[ Parent | on HN ]

Re:C++23: The Next C++ Standard by coldpie on Tuesday July 11, 2023 @02:26PM (#36685228)

> The others are more sus but you can make a bad API out of anything.

Yahhhh but there's something about operator overloading that is like catnip to clever programmers. Ah ha, file paths have slashes, and the divide operator is a slash! Clearly I should use the divide operator to append paths segments together! I'm so clever! Ah ha, << looks kinda like an arrow I guess, so we can use it to, uh, pass data between objects, I guess. I'm so clever...?

It's irresistible. We have abused it and we must give it up for the good of all.

[ Parent | on HN ]