5 ms·
When it comes to std::optional, the answer is no. In fact, std::optional<T&> is explicitly forbidden (see here: https://www.fluentcpp.com/2018/10/05/pros-cons-o
by lpapez 6y ago
When it comes to std::optional, the answer is no. In fact, std::optional<T&> is explicitly forbidden (see here: https://www.fluentcpp.com/2018/10/05/pros-cons-optional-references/ https://www.fluentcpp.com/2018/10/05/pros-cons-optional-refe...)
It is used in some other places though. For instance, std::string implementations typically employ small-string optimization (SSO) which means that there might be a limit on string::size() since some of the bits inside that value are used for different purposes (example: https://akrzemi1.wordpress.com/2014/04/14/common-optimizations/ https://akrzemi1.wordpress.com/2014/04/14/common-optimizatio...). The "niche" in this case is the realization that strings are unlikely to be exabytes in size, so there is no reason to always store zeros in high bits of _size.
- steveklabnik 6y agoFun trivia fact: Rust's stdlib String type cannot, and therefore does not, support SSO.
- drran 6y agoIf you need [no_std] version, use SmallString/SmallVec. Otherwise, use SmartString, SmolStr, etc.
- pdimitar 6y agoI recently wondered if a library like `smol_str` will be upstreamed one day. I feel people would rejoice if they can use stack-allocated strings (up to a certain size). Do you think that's possible?
- steveklabnik 6y agoAnything is possible, but it's not clear to me what advantage being in the standard library would actually bring. It is a pretty niche use-case (and I work in embedded these days), and it is pretty trivial to use a package. Only the libs team can really say, and I'm not on that team.
- pdimitar 6y agoI'm looking at it through the lens of "let Rust have the best possible newcomer experience", which of course isn't a sentiment that has to be shared by the creators. I suppose I appreciate SmallString's ability to alias itself to Rust's String. But I'd immediately agree that this adds hidden complexity and the potential for it to bite you in the worst possible moment.
- steveklabnik 6y agoEven with that perspective, you can disagree. Offering even more string types may be more confusing for users.
- pdimitar 6y agoYep. I was kind of thinking out loud but was curious about your perspective. Thank you.
- steveklabnik 6y agoTotally! That's how progress is made, thinking out loud :) Thank you too!
- pornel 6y agoI like that Rust's String is not trying to be smart. It makes it predictable and easy to reason about. Because Rust has &str as the lowest common denominator for all string types, "non-standard" strings aren't difficult to use.
- pdimitar 6y agoI agree that less smartness is a good thing, it's just that sometimes I get a bit frustrated even with basic usages of Rust's String and &str. It gets easier with time but the first few months were a big struggle.
- brundolf 6y ago
- colejohnson66 6y ago> The "niche" in this case is the realization that strings are unlikely to be exabytes in size,... That’s what we say now, but a few dozen years down the line? Old Mac OS versions (pre X) would store extra bits of information in the MSBs of a pointer. “32 bit clean” Mac OS had to be created to allow usage on computers with more than a few dozen megabytes. That was an all too common problem when multiple gigabytes of RAM became commonplace. Granted, I highly doubt we’ll see exabyte level string lengths, but you never know. Fun fact: x86-64 mandates pointers be in “canonical” form where all unused bits of the address are the same as the MSB. So on a processor that has 48 address lines, the upper 16 must match the 48th bit. If you try to access memory with a “non canonical” pointer, the processor will throw an exception. This is because they don’t want people using them for flag bits and having a repeat of the “unclean” software problem. TL;DR: I agree, but never say never
- KMag 6y agoAnd it's too bad that most kernels (including Linux and Windows) put userspace in the low half of the address space. In the upper half of a 48-bit address space (or even 51-bit), all valid pointers, if interpreted as IEEE-754 doubles, are NaN, so you get NaN boxing without performing any arithmetic. (Though, if you want NaN-boxed nullable pointers, you'll need to pick a special value for nullptr.)
- colejohnson66 6y agoWhy are you treating pointers as floating point numbers?
- KMag 6y agoPointers aren't being treated as doubles. There are 2**53-2 bit patterns for NaN values, and most FPUs (including x87 and the Aarch64 FPU) generate only 2 of those, leaving 2**25-4 values available as a variant on tagged pointers called NaN-boxing/nun-boxing. NaN-boxing / nun-boxing is a common optimization, as seen in Firefox's SpiderMonkey, Safari's JSC, LuaJIT, etc. If all of your valid pointers are at the top of the address space, you can use 0x0 as the constant you either add/subtract or xor with your values to box/un-box. In other words, Nan-boxing/unboxing becomes a no-op.