[tialaramex]

C++ also pays a price for insisting not only that objects have addresses, but those addresses are distinct.

If you've got a 1.6 billion empty tuples in variable A, 1.4 billion in variable B and 1.8 billion in variable C, C++ can't see a way to do that on a 32-bit operating system. It needs to give each empty tuple an address, so it must think of 4.8 billion integers between 0 and 2^32 and it can't do that, so your program won't work.

Carbon is still far from finished, but if objects needn't have addresses it can do the same as Rust here, and cheerfully handle A, B and C as merely counters, counting 1.6 billion, 1.4 billion and 1.8 billion respectively is fine. Empty tuples are indistinguishable, so I needn't worry about giving you back the "wrong" empty tuple when you remove one, I can just give you a fresh one each time and decrement the counter.

[zeusk]

Maybe the right question to ask is, why you have 4.8 billion empty tuples? And why you're still on a 32-bit system?

[borschtplease]

> And why you're still on a 32-bit system

There is a lot of 32 bit microcontrollers, most notable stm32

[WJW]

Sure, but how many of those have to handle billions of empty tuples?

[saagarjha]

Carbon has no intention of working on those systems, it’s designed for 64-bit first and foremost.

[alar44]

Well if you need billions of tuples, you're using the wrong system.

[bsder]

Gamedev, presumably. It's not unusual to have a LOT of triangles and coordinates flying around and GameDev is basically locked to C++ (for many good reasons even if I find C++ distasteful).

Admittedly, those probably aren't running on 32-bit systems, nowadays ...

[phire]

Carbon is probably Gamedev's best chance of moving beyond c++

But you are going to need some minimal buy-in from Microsoft first, if not Sony and Nintendo too.

The great thing about carbon is that you can incrementally shift a codebase over from c++, and there are no problems interacting with existing c++ APIs, so the required amount of buy-in is pretty much just "yes, you can use a 3rd party compiler" and maybe some improvements to the debugger.

[cesaref]

What about rust?

[phire]

It's complicated to call a c++ library from rust.

You actually have to wrap all the c++ functions in c functions, and then call those c functions from rust. Which requires either making manual wrappers, or automated wrapping tools that handle the specific idiosyncrasies of the library you are calling.

Which is a massive barrier; Gamedev standardised on c++ and there are so many c++ libraries.

In comparison, Carbon is designed from the ground up to automatically have bi-directional inter-op with c++. It's what the language is designed to do.

[bsder]

As much as I love Rust, it really has a significant impedance mismatch at the low-level with GameDev.

Things must be initialized in Rust. Things must have a single identifiable owner. Things really want to be immutable.

Sure, you can duck these in Rust with lots of "unsafe". But, if you do that, are you really gaining anything from using Rust?

[tialaramex]

I agree with you that Rust isn't a perfect match for video game development. Jonathan Blow's Jai is targeting that sort of program, it's not offering Rust's safety promises (Jon is confident this doesn't matter) but it can hardly be less safe than C++.

However, the purpose of unsafe is to mark code that does something which a human needs to check for correctness. We're not saying "This isn't OK" but "The compiler can't check this is OK, so a person needs to do so". If you write C++ today, all of your code is like that. I'd be astonished if more than a tiny proportion of the actual game code in a modern video game needed that treatment in Rust.

For example, Rust's approach to late initialization is std::mem::MaybeUninit<T>, a wrapper type which says to the compiler hey, I am not initialized yet, it's OK to write a T value into me, but you can't read my value until somebody says they're done initializing me. The "say you're done initializing" part is indeed unsafe, but that's a small part of the program. That intern writing a zone preview gadget? They don't need to be writing unsafe initialization code, when they try to access preview_zone.orb_color the compiler tells them this is MaybeUninit and so they can't read it. "Huh, apparently orb_color is MaybeUninit ?" "Oh, just show all the orbs in preview as orange, it'll be fine". You just avoided Undefined Behaviour and possibly a trip to the land of "But it works in debug builds".

[erichocean]

And yet…Bevy exists and has a nice API.

> But, if you do that, are you really gaining anything from using Rust?

In each new release of Bevy, they've found soundness bugs with the borrow checker—seems like they're gaining something.

[zeusk]

I work in graphics/directx; I know.

Triangle meshes can be stored quite efficiently and a lot of the modern geometry is tessellated, procedural or replicated.

There are far better optimizations for gamedev like using SOA instead of AOS.

[TillE]

There are a zillion ways to handle sparse arrays or redundant values that don't depend on esoteric language features. You're not even losing any efficiency, you're probably gaining some because you know your domain.

[moonchild]

Presumably, your triangles have 3 sides, and your coordinates exist in at least one dimension?

[Someone]

I may be overlooking something, but I don’t see a realistic use case for having multiple empty tuples without an address.

If you have those, I don’t see any way to discriminate between them. If so, why would you ever want to have more than one of a given type? Is there some template code that might accidentally try to create them?

[_nhynes]

Rust `Set<T>` is implemented as `Map<T, ()>`. Go is similar, but you have to do it manually. Zero-sized types mainly have use in generics (so yes-ish by templates, but not accidental).

[Someone]

Still, why would you ever have multiple, if there’s no way to discriminate between them because you can’t mutate them or obtain their address?

[shakow]

Is that really a problem now that the overwhelming majority of C++ programs run on 64bits platforms?

[comex]

A better example of address uniqueness being a problem is with code like:

    struct Marker {};
    struct Foo {
        Marker marker;
        int64_t number;
    };

If you write the equivalent in C with GCC extensions, or Rust, sizeof(Foo) would be 8, the same as sizeof(int64_t); `marker` doesn't take up any extra space. In C++, however, sizeof(Foo) is 16, because `marker` must take up at least 1 byte to have a unique address, which gets expanded to 8 bytes due to alignment.

Now, as of C++20, you can reduce sizeof(Foo) to 8 by tagging `marker` as [[no_unique_address]]. However, this has drawbacks. First of all, it's easy to get situations like this in highly generic code, so it's hard to predict where [[no_unique_address]] needs to be applied (and applying it everywhere would be verbose).

Second of all, [[no_unique_address]] is dangerous, because it doesn't just allow empty fields to be omitted, it also allows nonempty fields to have trailing padding bytes reused for other fields. Normally that's okay, but if you have any code that performs memcpy or memset or similar based on the size of a type, such as:

    struct Foo {
        Foo(const Foo &other) {
            memcpy(this, &other, sizeof(Foo));
        }
        // …some fields here…
    };

…then if that code writes to a [[no_unique_address]] field, it can overwrite adjacent fields, since sizeof(Foo) includes any trailing padding bytes!

[saagarjha]

I don’t really get the concern here. [[no_unique_address]] seems to be designed for use with empty types. As such, what does it mean to write to such a field? These are really meant to be tags, no?

[CodeHz]

it could come from a template function which don't have a sfinae branch (or `if constexpr (std::is_empty<T>::value)`) for empty type

[gumby]

> C++ also pays a price for insisting not only that objects have addresses, but those addresses are distinct.

With only three exceptions I can't think of a case where by default one would not want that. In the case you describe you would want all those objects to have unique addresses. If you wanted to have them overlap you should go to the effort to happen the way you want it to -- how could the compiler guess on its own?

The exceptions BTW are union elements, the first class/struct element, and base object addresses (in `class foo : bar ...` the when you make a foo, the address of its bar is the same as the address of the foo itself).

[tialaramex]

> In the case you describe you would want all those objects to have unique addresses.

I certainly don't, if you want unique addresses for indistiguishable objects I guess C++ is the perfect language for you but, what are you expecting to do with these addresses?

[gumby]

You made an object rather than using an existing one. How is the compiler supposed to know that you wanted an existing object?

[tialaramex]

I don't want an existing object? You seem to be having a lot of trouble with this very basic idea. Objects do not necessarily need distinct addresses. "But that's how C++ works" is just a fact about how C++ works, it has no larger significance, and where it conflicts with the sensible way to do things it's actually a defect.

[tsimionescu]

How would you define object identity if different objects can have the same value and the same address?

To my mind, an object is a value with a unique identity. How else would you define it?

And if you want a billion empty values, then yes, those could all be implemented by the same object - it's pretty easy to implement, even though it would be ncie for a compiler to do it automatically (like how Java normally gives you the same Integer object if you box the same int value in two different places, even though it will give you a different Integer of the same value if you explicitly ask for it with new).

[ordu]

> How would you define object identity

    fn main() {
         let vs = [(), (), (), (), ()];
         for v in vs {
             println!("{:?}", v);
         }
    }

This loop will five times print "()", because `v` will iterate through all five elements of `vs`. Are this values are identical or they aren't? I don't know, it doesn't matter, isn't it? But I think of them as of different values: they are different members of `vs`.

[edflsafoiewq]

What are you expecting to do with 4 billion empty tuples?

[mgaunard]

In C++, the way around this is to use inheritance rather than members, since base and derived classes may obviously have the same address.

[TylerGlaiel]

since C++20 you can get around this

https://en.cppreference.com/w/cpp/language/attributes/no_uni...

[tialaramex]

comex mentions this above. It's a nice hack, but it doesn't actually fix the problem I was talking about, you can give this attribute to a data member, which allows you to do the ZST marker type trick that is available in other languages, but you can't apply the attribute (at least, not as documented) to a type itself, those empty tuples are obliged to take up one byte each.

[tsimionescu]

But why not use an empty base class instead? That seems both more idiomatic and simpler. And since C++ supports multiple inheritance, there's no limit to how many empty base classes you could have.

[tialaramex]

Using an empty base class is idiomatic C++ for solving the problem comex is talking about (marker types) although it has some pretty annoying consequences. Whether it's "simpler" probably depends on whether to you "simpler" means, "how I'm used to in C++".

But it doesn't have any bearing on the problem I was talking about, if you were to instantiate your empty class it has non-zero size. C++ just doesn't have ZSTs.

[tsimionescu]

Ok, I misunderstood the thread a bit and was only commenting on the marker issue. I do thing that a type-level marker is "simpler" in a more general sense than checking whether a struct has a particular field, even if that field takes up no space in the struct.

Now, related to ZSTs, I think the main reason why C++ doesn't have this is that C++ really doesn't have any good support for constant values. Sure, you can mark something `const` but that rarely means too much - specifically, it can never add any new semantics to a type, it only removes some options.

One consequence of this is your example - a `const vector<T>` can't be a simple counter of how many T are in the vector even if the T type has a single possible value: the language can't really use the fact that the array is `const` to change its layout.

An even worse consequence is that a `const vector<int> * const` (a const pointer to a const vector of T) is not covariant (it can't be initialized with a const pointer to a const vector of a subtype of T), even though it should be: the language just won't use the fact that it is `const` in this way.