size_of and align_of [LWN.net]

size_of and align_of

Posted Jul 28, 2024 2:23 UTC (Sun) by NYKevin (subscriber, #129325)
In reply to: size_of and align_of by tialaramex
Parent article: Rust 1.80.0 released

Note that LazyCell and LazyLock are (for the most part) "just" a more user-friendly version of OnceCell and OnceLock, which have been stable since 1.70.0.

(The main difference is that OnceCell and OnceLock require you to pass the lambda at each callsite, whereas LazyCell and LazyLock let you pass it once at construction time. The other difference is that LazyCell and LazyLock are Deref, so the callsite doesn't look like a callsite, it just looks like a pointer dereference - but you can call the force() associated function if you really want to be explicit about it. The really pedantic difference that probably nobody cares about, is that OnceCell and OnceLock can give you a mutable reference to the underlying data if you have mutably borrowed the OnceCell/OnceLock, but the Lazy objects don't let you do that.)

to post comments

size_of and align_of

Posted Jul 28, 2024 20:10 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (2 responses)

I think for my purpose the need to repeat the lambda everywhere is a problem, or at least a gross inconvenience. So that's why I think Lazy is important and I had not found Once adequate.

Basically instead of 4, a single byte with the pattern 00000100 in it, my four is: Two num::BigUints (a numerator and denominator) to form a rational magnitude, then a sign flag, a sum type which says whether we're also multiplying this by a fixed irrational value, and the potentially complicated arithmetic (with cached state, potentially very large) for the said irrational value if we are.

I would like to be able for the type of this data structure to provide something similar to a constant like FOUR and ZERO rather than (as I do in the current prototype) making such values each time they're needed.

This data structure is of course horribly unwieldy as a replacement for i32 or f64 - but it's perfectly reasonable for a desktop calculator type application, where the performance loss is more than amply compensated by knowing when there's an exact answer or it's in terms of a well known irrational such as Pi or e.

size_of and align_of

Posted Jul 29, 2024 2:58 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (1 responses)

I don't see why. You can just write this:

fn make_small_bigint(value: i64) -> BigNum{
// Do whatever simple logic you need here.
}

// Can also have e.g. make_small_rational(numerator, denominator), etc.

// Global scope:
static OnceLock<BigNum> FOUR = OnceLock::new();

// Callsite:
let four = FOUR.get_or_init(|| make_small_bigint(4));

LazyLock just means you can write let four = *FOUR; instead of let four = FOUR.get_or_init(|| make_small_bigint(4));. You still have to write the function make_small_bigint() either way, because you will need to pass exactly the same lambda to the LazyLock at construction time.

size_of and align_of

Posted Aug 1, 2024 15:02 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

Yeah, exactly. You're correct that it's not *impossible* or even *actually difficult*, it's just messy and annoying and that's not enough improvement over my current situation, whereas Lazy is cleaner.

Don't worry, I was never under the impression it was *impossible* even when I started (long before 1.70) I was just expecting to need a third party crate to make this tidy and now probably I won't.

There's a lot more work to do to properly approach the vision from the Java API but in a nicer language, but I think I'm closing on the point where it's a useful alternative to tools like the Unix "basic calculator" bc or the typical GUI calculator on your desktop OS.