Hacker News Reader

Comment by nox100 | Hacker News Reader

[flagged]

I agree that modern c++ is messy, but I like this. It helps library writers, and empowers them to write better, safer code. I don't expect I'll ever need to write that function, but if it helps the standard library, QT, boost, gsl to write safer, more expressive code, im all for it.

(Context: https://learnmoderncpp.com/2022/12/07/applications-of-c23s-d...)

While the article describes why you'd want this abomination, honestly, I'd rather opt for the copy-pasted code

    T& at(size_t x, size_t y) { return data.at(y * X + x); }
    const T& at(size_t x, size_t y) const { return data.at(y * X + x); }

as something that's actually human-legible while also providing const-correctness. If the implementation is actually complicated enough, then sure, use the const_cast variation, but hide it away in a .cc file. This feels like a contrived example to show off new language features.

That said, I'd also rather use std::mdspan [0] if I had C++23 available, and not implement my own Matrix struct by hand.

[0] https://en.cppreference.com/w/cpp/container/mdspan

It isn't contrived, just incomplete. You'd need to copy-paste it four times -- there is &, &const, && and && const overloads (the fourth isn't making much sense, but still).

Make unique was something that you could sort of do in c++11 (with tiny header) and officially added in c++14.

All the other stuff you mentioned as far as I can tell is C++11 too, so it looks like you haven't used c++ for a long time.

That's not the point. The point is you shouldn't need that crap in the first place.

The use of ``this Self&& self`` in the ``at()`` method can appear to be an overkill. But this approach actually covers many scenarios and make the code much smaller. For details, you can read:

https://devblogs.microsoft.com/cppblog/cpp23-deducing-this/

I think you missed the point. The point isn't that these features don't have a purpose. The point is rather, at every line of code you have many choices that you arguably shouldn't need. Should I use a raw pointer or a unique_ptr or a smart_ptr. Do I need to call make_shared here or can I do something else? Should I call std::move here or not? Should pass by value or pointer or const pointer, or reference or const reference? And on and on, every line is a foot gun.

I get why it's that way, backward compatibility. The problem is, the original way, the path of least resistance, is now effectively deprecated, but it's the official syntax.

    char* s = malloc(size);

is considered bad code. I get why. But, in a "good language" the default would do the right thing and I'd only escape into bad code by extra work so that all the easiest code to write did the right thing by default.

C++ is trying to fix all that old bad code by coding standards and linters but I don't want to have to type a bunch of boilerplate I need to memorize to do the right thing. I want the right thing to be the most obvious, no brain cells required path.

Because a lot of things are not solved at the language level as the language is bloated enough as it is. Instead they are pushed into the library.

Of course if the language was designed again from scratch it might settle on a different local optimum.

From your example above, the only bit I really dislike is the handling of universal references (forward and &&), but that's the best that programmers better than me were able to retrofit onto the language, so eh.

std::forward<Self>(self)

ok that's pretty goofy

The C++ people can and will do whatever they feel like, I've come to accept that. Deep language models will bring clean, readable, literate code back eventually, but for now there's clearly no hope, and no point in complaining.

What bugs me is that if I ever need to update my resume again, I'll need to take C++ off of it. This time for sure. It's been there since the 1990s, but it has become increasingly fraudulent for me to leave C++ on my list of qualifications since then.

It kind of sucks to lose a hard-won skill... not because I got old and forgetful (which will happen, but not just yet), or because I stopped using it daily (I never stopped), but because they changed what it meant to "know C++." The code you posted might as well be Brainfuck or Perl or line noise or something.

C++ is simply not a C-derived language anymore, and we need to stop pretending otherwise. It was never about the brackets and semicolons, it was about the fact that you could read and understand it as a newbie with no more than a couple weeks' exposure. If all that crap is really necessary, then something went very wrong somewhere at some point, and went unaddressed afterward, and now it's too late.

Reply on news.ycombinator.com