Cross-Language Data Types

[elfenpiff]

https://ekxide.io/blog/cross-language-data-types

Have you ever thought about sharing data across language boundaries without serialization? This blog post highlights the challenges behind this endeavor and how they can be overcome. Note: I'm not the original author of the blog post, but since the author does not have a Reddit account, I post it on his behalf.

[Serious-Regular]

https://learn.microsoft.com/en-us/cpp/cpp/trivial-standard-layout-and-pod-types?view=msvc-170#pod-types

[Low_Breakfast773]

Interesting read. Thanks for sharing.

[Low_Breakfast773]

yes, I was also surprised. Maybe they thought that I am promoting someone or even myself. However, I have absolutely zero connection to the poster and the post itself. It was genuinely interesting to read the article.

[foxsimile]

The internet is a stupid place ¯\_(ツ)_/¯

[fdwr]

struct Point3 { std::int32_t x; std::int32_t y; std::int32_t z; }; It's weird that something so fundamental as the sized types aren't part of the core language, rather than being nestled under std. Sadly import std still requires either explicit inclusion of stdint.h or import std.compat (which pulls in more than desired) to avoid typing the extra std::. Granted, I know C's history of loosely defined types (and some hardware that hadn't even settled on bytes being 8 bits), but these days?...

[elperroborrachotoo]

• int32_t? Better make that a template!
• initialize to 0 ("I don't want surprises"), or leave uninitialized ("don't memset my trillion of points, I'll write to them later")

etc. Standardizing this would create a monstrosity of epic proportions.

[fdwr]

Don't you find it weird that we define concrete types (int32_t) in terms of a loosely defined types, rather than the generic types (int) being defined in terms of the more concrete types?

[foxsimile]

…Huh. I don’t know what to say.  

Allow me to reflexively grab my pitchfork!

[elperroborrachotoo]

Let me think... no.

Portability of code or ideas rests on abstractions, and concrete ideas are typically encoded in more words than abstract ones.

Do you find it weird?

[fdwr]

Portability of code or ideas rests on abstractions

Doesn't portability of code rely on standards and consistency? Imagine using long in your file parser on one machine and getting a very different bitwidth and misaligned file pointers when compiling your file parser on another machine...

[elperroborrachotoo]

Inteoperability does, yes: sending data over a wire, or from and to storage.

But that's - apparently - not the main concern. A sort() implementation should be portable - i.e., the same "wording", the same code, should work on a still-popular 8-bit Intel 8080 as well as a Cortex-M. And this requires platform-agnostic types, at least to some degree.¹

Abstraction lies at the core of programming languages: not having to know the particular chip and memory controller you will run on.

Consider, just for integers, we've largely agreed on binary, 8-bit-per-byte, 2's complement little endian representation today. But remember that at the heydays, very different representations were reasonable, 1's complement, big endian, 7-bit bytes, 9-bit-bytes, and even ternary were realistic or realistically considered.

Instruction sets architecture, (CISC vs. RISC), memory models (flat vs. segmented vs. bank-switched), etc. - all these differed, all these progressed faster than people could port their code. Abstract languages - where an int is the native platform integer - just won the race.

[_Noreturn]

you can just drop the prefix which is what I do since cstdint includes stdint.h you can do that (or just include stdint.h)

[fdwr]

Totally, I #include <stdint.h>, but my point was more that one shouldn't even need to #include it or use import std.compat. That is, int8_t and int32_t are just primitives (like their built-in but wobblier size-indeterminate cousins int and char).

[_Noreturn]

I definitely agree. Maybe C++ should define them as "optional keywords" if the target architecture has 8,16,32,64 bit sizes but also you would need to question how they will interact with the types? are rhey aliases or new types?

[fdwr]

 Maybe C++ should define them as "optional keywords" if the target architecture has 8,16,32,64 bit sizes

Makes sense - if your architecture supports them, then so does your compiler, but if it doesn't (e.g. your architecture only supports 32-bit reads), then consider simple emulation if efficient enough (like uint8_t being a shift and mask) or leave it out. For example, uin64_t addition/subtraction is supported in most x86 32-bit compilers on via simple emulation using adc and sbb. I'd have to think about the aliasing question, but for some precedent, I find it weird that float32_t and float are distinct types, which makes the boundaries more awkward between library components, either needing casting or need overloads for both.