With shared_ptr you completely lose track who actually owns an object or when it will get destructed. It encourages sloppy programming and makes code much harder to read and reason about.
Unlike most languages that have ref-counting build in, shared_ptr also doesn't provide anything to deal with cyclic dependencies, so you can end up with memory leaks.
The most important reason however is simply that you don't need it like 99% of the time, unique_ptr provides enough functionality to work just fine as a shared_ptr replacement in most situations. And in the rare cases where you really need a shared_ptr, you can just convert a unique_ptr into one.
Author here, parent comment describes it very well — shared_ptr are a last resort, not a first one.
They are quite heavily (and badly) used in some code bases (ROS). I'm planning a future article that covers shared_ptr in more details.
The surprising thing about shared pointer is that a `const shared_ptr<T>` means that you can modify the contents of T. This makes the problem, mentioned in the parent, of keeping track of who can modify the object where impossible. I've never encountered a `const shared_ptr<const T>` but that would be a better approach.
Use projection mapping, instead of lighting the photo uniformly, use a projector and project a copy of the image onto the photo, thus you get detailed control over how much light the parts of the image receive.
Alternatively, use transparent film and a bright backlight.
Why? And how would that even work? Just because an online account is tied to a verified real human doesn't guarantee that the content isn't coming from an AI-bot.
It's a blockchain, so you can keep permanent record of what a person is doing and when and where they got caught violating the rules. It won't stop the infractions from happening at first, but it will make it very easy to avoid them happening again. And if this gets widespread, people might think twice before risking their blockchain personhood certificate.
You're missing the point. How would they get caught violating the rules in the first place? You (and the HN admins) have no way of knowing whether I typed this comment in myself or an AI bot used my account to do it.
There is '-Wconversion' to catch things like this. It will however not trigger in this specific case since g++ assumes converting 1000.0 to 1000 is ok due to no loss in precision.
Quantity(100) is counterproductive here, as that doesn't narrow the type, it does the opposite, it casts whatever value is given to the type, so even Quantity(100.5) will still work, while just plain 100.5 would have given an error with '-Wconversion'.
My opinion is that if you need to run extra tools/linters in order to catch basic errors, the language & its compiler are not doing enough to protect me from correctness bugs.
I do run clippy on my Rust projects, but that's a matter of style and readability, not correctness (for the most part!).
To be clear, the only difference between Rust and C here is whether the conversion happens by default or not. Rust doesn't do the conversion by default but will let you do it if you want to, with `as`.
There are also more type-safe conversion methods that perform a more focused conversion. Eg a widening conversion from i8 -> i16 can be done with .into(), a narrowing conversion from i16 -> i8 can be done with .try_into() (which returns a Result and forces you to handle the overflow case), a signed to unsigned reinterpretation like i64 -> u64 can be done with .cast_unsigned(), and so on. Unlike `as` these have the advantage that they stop compiling if the original value changes type; eg if you refactor something and the i8 in the first example becomes an i32, the i32 -> i16 conversion is no longer a widening conversion so the `.into()` will fail to compile.
Yes that's correct, for exactly the reason that it is more likely to keep compiling and possibly not do what you intended if the original value's type changes due to refactoring. However there are still a few conversions that don't have alternatives to `as` - truncating conversions (eg i64 -> i32 that intentionally discards the upper half), int <-> float conversions (eg i64 -> f64, both truncating and checked conversions), unsized pointer casts (eg *const [MaybeUninit<u8>] -> *const [u8], `.cast()` only works for Sized target), and probably a few more.
Setting up clang-tidy for your IDE isn't really any more trouble than setting up a LSP. If you want the compiler/linter/whatever to reject valid code to protect you from yourself, there are tools you can use for that. Dismissing them just because they aren't part of the language (what, do you expect ISO C++ to enforce clang-tidy usage?) is silly.
The reason certain warnings are on or off by default in compilers in certain warnings modes depends on whether enough people find them useful enough or not. Rust caters to people who want strictness which makes it annoying to use for others, but if you want this you can also - to a large degree - have this in C and C++.
How much of what Rust the language checks is actually linter checks implemented in the compiler?
Conversions may be fine and even useful in many cases, in this case it isn’t. Converting to std::variant or std::optional are some of those cases that are really nice.
It is not worth the bother. I really wish I had a source for this because it stills feels important, and I value links more than most.
Links would be nice but it does not add enough value to be worth it, it actually costs too much and is easy to mess up. The ones who care will search for it, and the great majority can not be bothered. Source: internal statistic from a webbserver, with fact heavy articles.
There were some types of articles that needed source material. But these kinds not so much. I say this because I was involved in a project that worked on QA and maintaining links. We wasted money on that project.
a lot of sites don't add hyperlinks. that seems to be a new trend. don't think that is reason to criticize this particular article, for not doing what a lot of sites are also not doing.
That requires having an account on the other machine. What's missing is anonymous scp, where the other side just opens up a directory, and you can copy into it. One can build something like this with rsyncd, but it's not a pretty shell one-liner to get it going and it still requires both devices to be on the same network.
What I responded to was "wirelessly transferring files between a phone and a computer", assuming that I am the user at both ends of the transfer.
If I want to share something with someone else, there's a "File Sharing" section in phone's settings that enables anonymous WebDAV sharing, and it works fine too. There's Bluetooth OBEX too, but that one's fiddly.
Money alone wouldn't fix this, as a Web where every page has a paywall wouldn't be much better either. Which in turn would concentrate most of the Web in a few services just as it is today and enshittyfication would bring the ads back sooner or later, even if you pay for the service.
> bring the ads back sooner or later, even if you pay for the service.
This has already happened for subscription TV services. Your previously ad-free subscription now has ads, but you can get rid of them again by upgrading! It’s fucking gross. It’s also of course just going to work, and become the new normal.
Give every Internet user a domain name and routable IP for free with their Internet account.
That won't magically fix all the problems in an instant, but the core of everything wrong with the Internet starts with the Internet being separated into consumers and providers, instead of being a true peer2peer network.
Even in the olden days of the Internet when ISPs would give you free webspace with your Internet account, you still didn't get your own domain name, meaning all your Web presence would bust when you switched providers.
Alternatively, get Freenet, IPFS/IPNS or any of the other distributed alternatives working, but after 25 years of people trying, I kind of given up hope of it ever happening.
Not much. A horizontal split (C-x 2) can be quite useful to keep the top of a file in view while editing around at the bottom of a file. A vertical split (C-x 3) is useful when comparing files side by side. But that's about as far as I go, beyond that it just becomes annoying, as popups like from magit will show up in random subwindows, often rendering them unusable, due to that subwindow not being big enough.
As a counterpoint, I pretty much always split into 2+ windows. A 2-window setup is a code + terminal setup with shortcuts to run commands on the terminal(s). On more complex projects there are typically more than one terminal windows.
My org-mode emacs instance for note taking is split into quite a few windows: ongoing work task(s), generic "today's scratch pad", various topical notes files, etc.
On the posted topic: I don't know whether the transposition would be useful for me though - as the layout is set up by screen orientation then only a 180 degree turn would make sense.
Looks incredibly complicated, or maybe the article isn't written very clearly. It sounds like the packages are doing their own layout and you can override it from a central location .. Sometimes
Seems like this new feature might help with that, if magit takes over or creates a new window, you can rotate or flip your window arrangement until it's in a usable space (if it works like most tiling window managers, which isn't entirely clear from TFA).
Unlike most languages that have ref-counting build in, shared_ptr also doesn't provide anything to deal with cyclic dependencies, so you can end up with memory leaks.
The most important reason however is simply that you don't need it like 99% of the time, unique_ptr provides enough functionality to work just fine as a shared_ptr replacement in most situations. And in the rare cases where you really need a shared_ptr, you can just convert a unique_ptr into one.