why do we use long long instead of size_t

I don't see much difference?

• unsigned long long is the largest unsigned range we could have in C++ natively
• we won't have negative value here

ofc they are the same: size_t is just typedef of unsigned long long on 64bit system. However it has a clearer semantics: it represents a size, which is what all these "number of bytes" about.

No strong preference, updated.

OK, I found size_t doesn't compile

./src/ray/util/size_literals.h:22:18: error: 'constexpr size_t operator""_B(size_t)' has invalid argument list
   22 | constexpr size_t operator""_B(size_t sz) { return sz; }
      |                  ^~~~~~~~

Working version:

constexpr unsigned long long operator""_B(unsigned long long sz) { return sz; }

Non-workable version:

constexpr size_t operator""_B(size_t sz) { return sz; }

wrap everything in namespace ray::literals so users must opt-in with using

I don't think putting these function into a namespace is a good idea.
For example, gflag requires all flag values to placed in outmost namespace.
A typical use case is:

DEFINE_int64(some_flag_name, 15_MiB, "some flag description");

[nit] I'd prefer ordering as B, KB, MB,...., KiB, MiB, ....

[nit] why not:

constexpr size_t operator""_PiB(long double sz) {
const long double res = sz * 1_PiB;
return static_cast<size_t>(res);
}

and these double-to-size_t code are so duplicated, I wonder if we can make it a macro.

// Macro to generate (long double -> size_t) literal from (size_t -> size_t)
#define CREATE_FLOAT_SIZE_LITERAL(suffix) \
  constexpr size_t operator""_##suffix(long double sz) { \
    return static_cast<size_t>(sz * 1_##suffix); \
  }

// Using the macro to define long double -> size_t literals
CREATE_FLOAT_SIZE_LITERAL(KiB)
CREATE_FLOAT_SIZE_LITERAL(MiB)
CREATE_FLOAT_SIZE_LITERAL(GiB)
CREATE_FLOAT_SIZE_LITERAL(TiB)
CREATE_FLOAT_SIZE_LITERAL(PiB)

[nit] why not:
constexpr size_t operator""_PiB(long double sz) {
const long double res = sz * 1_PiB;
return static_cast<size_t>(res);
}

Updated.

I'm not a fan of macros.

Using macro is generally not recommended (effective C++ item-1 has a few good arguments):

• Hard to debug, easier to get wrong;
• Purely textual replacement, no compiler check (i.e. what if repeated macro definition);
• Affective, especially in header file.

I almost only use macros at error propagation (i.e. ray/util/logging.h) to save some boilerplate code for unhappy path.
For here, both implementations are just one-liner, don't see much benefit.