The C++ Standard Library Has Been Walking Itself Back for Fifteen Years • Hacker News Board

Re: The C++ Standard Library Has Been Walking Itself Back for Fifteen Years

#21

Post by tialaramex » Sun, May 24, 2026, 10:38 PM UTC

aapoalas wrote: post #15

Beyond just quite possibly being slop, this is also sloppy and confused: complaining that C++ cannot remove features because they live in the stdlib forever while listing out a bevy of features that got deprecated and then removed is just oof. Also, fun fact: Rust cannot remove anything from std once stabilised, presumably forever. Take this with a slight grain of salt, I haven't vetted this thought myself, but it's…

Rust promises not to remove things from the stdlib unless they're unsound. It does commonly deprecate things - the deprecation warnings won't bother people merely using your library or whatever but will still show for you if you're maintaining it.

Re: The C++ Standard Library Has Been Walking Itself Back for Fifteen Years

#22

Post by 1313ed01 » Mon, May 25, 2026, 5:53 AM UTC

fragmede wrote: post #19

1313ed01 wrote: post #10

Earlier quoted context omitted.

If I want to read a LLM's "opinion" on some subject I just prompt it myself. Inserting humans as intermediaries that pretend they wrote something is dishonest at best. Future generations will hopefully see through that and stop sign generated texts with fake human names.

Really? When someone's already warmed the Earth slightly and used the energy and spent the tokens to do it once, you're going to do it again, just to spite them, because you hate the environment? And because you're rich and have unlimited tokens to spend on anything?

Using a cache of outputs makes sense, but that is just an optimization. I don't mind if a site publishes generated texts, as long as they are clearly labelled as such and have no fake-writer human names attached.

Re: The C++ Standard Library Has Been Walking Itself Back for Fifteen Years

#23

Post by oezi » Thu, May 28, 2026, 7:01 AM UTC

kennu wrote: post #17

oezi wrote: post #16

Earlier quoted context omitted.

Sure, but auto_ptr is different in that copying transfers ownership, while unique_ptr prohibits copying.

But if I understand it right, auto_ptr assignment didn't actually copy the pointer, but instead moved it to a new variable and quietly made the original variable null? And unique_ptr made this operation require an explicit move() call, because the assignment-only style caused too many null pointer bugs. I'm just curious about this for historical interest.

Yes, it was a design decision of the auto_ptr to have this move semantics and it worked very nicely for us because we used for instance to pass progress monitors down the stack.