HN Simulatornew | past | comments | lists | submit | MathMonkeyMan's commentslogin

Features are deprecated and removed. It's uncommon but it happens when a new feature makes all use of the old feature unnecessary. Usually it's deprecated for a few versions and then removed some years later. You can always compile old code against an old standard.

C++ does have many ways to do anything. Most of that is historical, or due to features and library facilities with overlapping capabilities, or inherent to multi-paradigm programming languages.

Every C++ project is written in its own language. Its own "house flavor." This is true of all languages, but is particularly stark for a language as old, complicated, and powerful as C++.


You returned a pointer to a temporary. It's nasty but easy to spot.

Would you return `input.c_str()`? You might think twice about that, but it's the same thing. My favorite fix is to take a `std::string_view` as the parameter.

    string_view remove_leading_spaces(string_view input) {
        auto new_start = find_if(input.begin(), input.end(), [](char ch) { return ch != ' '; });
        return string_view(new_start, input.end());
    }
The result of the undefined behavior in your program is surprising, though. As it usually is.

Passing allocator pointers around has the advantage of allowing you to customize the allocator when you want, and to ignore it when you want (which is most of the time), i.e. just use the allocator you were given and pass it around like some piece of syntax or ctx in Go.

The trouble comes when you have data structures that manage memory, and you want to associate the allocation strategy with the particular instance of the data structure. Or, worse, you don't store the allocator pointer with the data and you require that all functions operating on the data structure happen to use compatible allocators.

At its simplest, though, passing allocators around is just removing an implicit global variable that is sometimes helpful to customize locally, but nearly impossible to customize locally if left as a global.


Cars are different nowadays (hopefully even more reliable), but the '95 Toyota Camry that my parents bought new in 1995 or 1996 lasted until I was done using it in college in 2011. Then my dad sold it for a chunk of cash. The only thing wrong with it was that the roof paint was gone to shit from the Florida sun. You could probably paint it, redo the ceiling fabric, and run it for another 10 years. They sunk a fair amount into it over the years, but nothing catastrophic -- no powertrain issues, no "fixing this AC will cost more than the car" issues. In the six years I drove it I think it needed about $300 of work (something about the steering or suspension).


There are lots of Camry from 2008 to 2017 which has paint delamination issue. Ours is from 2012 but it only started getting noticeably worse near the end of the warranty period and I never heard about it because it was during the pandemic and our dealer went out of business. Toyota didn't publicize the issue till the end.


There's also the scene with the baby in Children of Men, and the synthesized long single shot in 1917.


If you enjoy good action movies, Extraction 2 has long single shot action scenes too.


I like the writing in this article. The author did warn us, but the punchline takes a while to get to:

> I’d like to be clear that there are legitimate uses of remote attestation. By using a website that requires attested passkeys you can be sure you stay safe from accidentally installing a scammer’s fake passkey application that steals your data – the website will reject such a passkey. You might want an attested Passkey even if the website doesn’t require it, since you can use attestation to verify that your software has not been tampered with by a hacker while you weren’t looking.

> As for reasons to not want attestation: you might want to be able to use software that Twitter (formally X) doesn’t specifically approve of, such as Linux. Or a phone with a refurbished operating system.

So the bad timeline is the one in which the industry gradually transitions to "you can't log on unless everything about your system is exactly as we want." Figures.


> such as Linux

Before anybody thinks "surely they can't ban all linux users", they don't need to. The systemd folks are also working on a startup that is building verifiable computing into Linux via systemd. So, we have no choice on the matter anyway. It could become of choice of approved distro vs non approved distro.

> So the bad timeline is the one in which the industry gradually transitions to

We have been on that timeline for every other tech transgression. There are no signs that this will be a different timeline.


They would have to start by banning Apple users. Apple does not support attestations from consumer devices. Apple has said multiple times they see it as a consumer privacy violation.


Oh great, another systemd conspiracy theory.



I was the Gentle Owl. Then I connected to a VPN, opened a private window in the same browser, and didn't maximize the window. Now I'm the Nosy Toucan.

The article's points still stand, but the trick didn't work this one time.


Private window is called out in the article as creating a second entity


But now, as a New Yorker, I can complain. And we love to complain.


Almost nobody that I've ever worked with knows how the shell works. I send them [the docs][1] but what kind of world would this be if people read the docs? Also, not exactly a page turner.

[1]: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V...


I learned this stuff from friends, O'Reilly books and endless nights of failure and trial and error. I'm certainly not a super wizard, but I feel like I'm not missing any shell skills to be able to do what I need to do.

[Insert mild rant on kids these days having no attention span any more]


> [Insert mild rant on kids these days having no attention span any more]

We used to try a command and then alter it slightly to see what it would do.


I recommend not doing that with rm.


also poorly organized and formatted.


> Also, not exactly a page turner.

Really? I can’t be the only one that will spend hours reading this kind of stuff. You guys don’t read man pages for fun?


I spent countless hours poring over the multiple man pages for zsh, along with books such as "From Bash to Zsh" and the book Peter Stephenson wrote. I wrote up decent completions for some software I wrote for personal use. My software is completely non-interactive and relied on complex trees of commands. My thinking was that completions would make it usable. But my completions were buggy and I didn't fix them for years (I'd use the completions, hit TAB, get some error messages, and say "oops, let me do this without the completions." For years.)

Years ago I thought this was fun. Now I've given up on learning zsh _arguments and the like. Instead I have made my software more interactive (an LLM helps here) and wrote it in Common Lisp (even without an LLM) so that I get decent completion behavior in SLIME for free.

I actually do like reading these things. But big shells like Bash and Zsh are brutal, especially with their random grab-bags of features that come from multiple shells of years long gone.


If your completions aren’t based on your parsing you are doing it wrong. See DEC VMS.


True, but recognize the spin. Pretend that in the last election you were skeptical of the reigning government medical establishment and you did buy into some of the conspiracies, or at least thought they had some element of truth. Assume you were wrong and that you have good enough presence of mind to now feel duped.

I was always team "RFK Jr clearly bad," but to be honest I didn't put much work into forming that opinion.


Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: