undefined

points

[-]

I understand the issue about the ever-moving target etc., but almost fifteen years later do you really believe C++98 is better than C++11 without move semantics and decent smart pointers? I remember working with Qt5 and C++98 and yes, it was productive, but it was also a mess of intricate object ownership.

I'm critical about some choices made with C++20 and after, like the mess that modules are, and the too-little-too-late ranges library. C++26 is also a joke imho. But on the other hand, working with std::optional and (in C++23) std::expected is so much better than without. The thing is nobody forces you to use every single feature of a new standard, but I would not recommend ignoring very good tools just for the sake of it.

by Rochus3 hours ago|

parent|

[-]

For all of my projects it is good enough. C++11 onwards has a few advantages, but I don't need them. Moving ownership between containers to avoid allocations was possible with the standard library even before C++11, and Qt offered "implicit sharing" which has a similar effect without syntax changes and incompatibilities. Even with my C++11 projects (e.g. https://github.com/rochus-keller/eigen/) I had to take care still in 2024 which feature not to use on MSVC because it didn't work or behaved differently. I never have any ownership issues and I implement large compiler projects with different AST and IR layers. All my projects still compile with https://github.com/rochus-keller/leanqt/ on all platforms. I would never trade a tiny language advantage with a whole world of dependability issues. One day I will revive and refactor GCC 4.7 to get a cross-platform C++98 with parts of 11 compiler just written in C, then latest all of my software is buildable "from first principles".

PS: it's funny I wrote my comment three days (and not an hour) ago.

by maleldil1 hours ago|

parent|

[-]

> Moving ownership between containers to avoid allocations was possible

That's not the biggest upside of move semantics. You can't safely express smart pointers without move semantics. They tried with std::auto_ptr, and it didn't work.

by Rochus1 hours ago|

parent|

[-]

Have a look at Qt implicit sharing. There is/was also a Boost library which could do most of it long before c++11.

by usrnm3 hours ago|

parent|

prev|

[-]

> it was also a mess of intricate object ownership

Not much has changed, though, it still is. Just with a lot more bells and whistles around it

by bluGill1 hours ago|

parent|

[-]

Much has changed for me since I used smart pointers where possible - which is the vast majority of the time. I am currently telling somebody you can't change a QString to a C string even though the C string probably won't overflow in that use. I have changed.

by usrnm19 minutes ago|

parent|

[-]

Smart pointers existed long before C++11. std::auto_ptr was a mistake, but it wasn't the only option

by logicchains2 hours ago|

parent|

prev|

[-]

>C++26 is also a joke imho.

C++26 will allow billions of lines of pointless serialization boilerplate to finally be deleted, adding the basic reflection functionality that most other languages have had for decades.

by jstimpfle2 hours ago|

parent|

[-]

Reflection is a joke. De/serializing arbitrary C++ structs is ill-defined. When you need serialization, even lots of it (e.g. silly JSON), I think you're better off writing your own framework where you can be clear about data formats and transformation rules.

by bluGill1 hours ago|

parent|

[-]

Reflection is likely useful for a lot of things, but I agree serialization need a better framework.

by gignico2 hours ago|

parent|

prev|

[-]

Yes, C++26 reflection is nice, but also extremely complex to understand and use well. The rest of C++26 is the usual series of too-little-too-late additions. Meanwhile I’m still waiting for pattern matching to become a thing (a proposal has been discussed for ages)

by tonyedgecombe1 hours ago|

parent|

prev|

[-]

I can't think of a time where using reflection for serialisation hasn't come back to bite me.