Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
BezierCurveDemo1997
Utah Teapot and Mystify Screensaver, 16-Bit DOS, Personal Project 1997 https://files.scene.org/view/mirrors/hornet/code/tutors/math/azr_bcrv.zip
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
iostreams are horrible to use, especially if you want to format your output and they blow up compilation to a mythical degree. People go to great lengths to avoid them and I agree with them.
print/println are based on the fmt library (https://github.com/fmtlib/fmt), which had it's first release in 2015, so it's roughly as old as Rust afaik. It's mainly inspired by Python formatting.
Having per-type formatters is just a logical conclusion of having type-safe formatting.
iostreams are for all kinds of io (which includes stdin/stdout), while fmt is entirely dedicated to formatting strings. Those things are related, but not the same. cout and cerr and such will probably be entirely superseeded by print/println (I hope), but it doesn't make iostreams generally redundant.
println adds a newline and you want to be able to choose, so there is print and println.
As someone who has written math libraries over and over again for the last 25 years (no joke - wrote this in 1997: https://github.com/bhouston/BezierCurveDemo1997/blob/master/... and just recently wrote the Threeify math library: https://github.com/bhouston/threeify/tree/master/packages/ma...), I find that operator overloading works only for the simple cases but that for performance and clarify, function names work best.
Function names let you clarify that it is an outside product or inside product (e.g. there are often different types of adds, multiplies, divides), and I can not stand when someone maps cross product onto ^ or dot product onto something else. Also operator overloading often doesn't make clear memory management, rather it replies on making new objects constantly, where as with function names, you can pass in a parameter that will take the result. Lastly, function names allow you to pass in how to handle various conditions, like non-invertible, NANs, etc.
I find word based function more verbose but significant less error prone and also they are more performant. Operator overloading is only good for very simple code and even then people always push it too far so that I can not understand it.
As someone who has written math libraries over and over again for the last 25 years (no joke - wrote this in 1997: https://github.com/bhouston/BezierCurveDemo1997/blob/master/... and just recently wrote the Threeify math library: https://github.com/bhouston/threeify/tree/master/packages/ma...), I find that operator overloading works only for the simple cases but that for performance and clarify, function names work best.
Function names let you clarify that it is an outside product or inside product (e.g. there are often different types of adds, multiplies, divides), and I can not stand when someone maps cross product onto ^ or dot product onto something else. Also operator overloading often doesn't make clear memory management, rather it replies on making new objects constantly, where as with function names, you can pass in a parameter that will take the result. Lastly, function names allow you to pass in how to handle various conditions, like non-invertible, NANs, etc.
I find word based function more verbose but significant less error prone and also they are more performant. Operator overloading is only good for very simple code and even then people always push it too far so that I can not understand it.
I should have said the "latest standard", not "spec", if we're being technical. But EVERY bit of official material is very clear about asserting that C++23 is still a preview/in-progress, not a standard. Saying otherwise is, strictly speaking, incorrect.
https://isocpp.org/std/the-standard
https://www.iso.org/standard/79358.html
https://github.com/cplusplus/draft/blob/main/papers/n4951.md
I'm a little 10 years out from writing C++ professionally and I found this cheat sheet[0] useful. Basically if you have an inkling of the concept you're looking for, just search on that cheat sheet to find the relevant new C++ thing. Specifically for me, we used Boost for smart pointers which are now part of the stdlib, and threads are now part of the stdlib as well.
[0] https://github.com/AnthonyCalandra/modern-cpp-features
TIL Box2D must not be serious code because it doesn't use copious amounts of explicit temporaries[0].
And just for the record, I'm very glad Erin Catto decided to use operator overloading in his code. It made it much easier for me to read and understand what the code was doing as opposed to it being overly verbose and noisy.
[0]: https://github.com/erincatto/box2d/blob/main/src/collision/b...