Daniel Houck

@LifeArtStudios @VilimIII @Jonathan_Blow @linux_version @lefticus I’ve never used Unreal so don’t know how many breaking changes it has, but if it’s more than C to C++ it’s definitely a port. Python 2 to 3 is a port.

@VilimIII @daniel_houck @Jonathan_Blow @linux_version @lefticus Is it a port when you upgrade an unreal engine game from say 5.4->5.5, how about 5.6? At some point theres probably a line, but c to c++ likely has less breaking changes than unreal to unreal.

I just ran an experiment, and "fun fact"... Agentic AI did a more correct and more complete port of Doom to C++ than I was able to in 1/10 the time (1.5hrs), if you remember my epic live stream doing that...

@shelvacu @n00bmind @lefticus I don’t know the C object model as well as the C++ one, but you are allowed to start using the pointer right away in C. In C++ you need to begin the lifetime of the Foo objects as a separate step, which now often happens implicitly but a few years ago always had to be explicit.

@daniel_houck @n00bmind @lefticus "you still don’t have any Foo objects just uninitialized memory" isn't that true in C as well?

FYI for people who don't know the difference: C++ and C are not super/sub sets of each other. They have different: * reserved words * memory models * reserved words * notions of lifetime etc It's very easy to craft a C program that cannot compile in C++ mode.

@JonathanLigmas @lefticus The cast is defined but unless it’s an implicit-lifetime type, *using* the pointer isn’t. I think during the original livestream there was no such thing as an implicit-lifetime type. And I’m not sure something with unions qualifies?

@daniel_houck @lefticus Foo must be a plain data struct in the C version right? Adding the cast in that case is safe/defined

@n00bmind @lefticus Or, the part about it still not being valid if you add the cast is the object model. The first part is the type system, but I was mostly using that as illustration to get to the object model part.

@n00bmind @lefticus You’re right, it’s the object model. I got confused because I consider them pretty closely related, but they are different.

@Zen_Feet @AlphaLegion101 @lefticus Very easy to *appear* to fix, with a cast, but that’s technically UB until recently unless you add a placement new instead. And the placement new for arrays doesn’t work right. There were other issues, but that’s the first one encountered and enough to show that 99% don’t work.

@daniel_houck @AlphaLegion101 @lefticus Very easy fix

@Zen_Feet @Thomas_Hall888 @lefticus And there were other issues but I have not watched the whole 12 hour stream and don’t understand some of the more serious ones.

@Zen_Feet @Thomas_Hall888 @lefticus Until a few years ago using the result of the cast was UB in C++; it usually isn’t now (unless unions are involved I think?). That can usually be handled by a placement new after the malloc but that doesn’t work for arrays.

@noop_dev @lefticus Some could be solved with more casts, but apparently once everything compiled it still didn’t link because of something I haven’t yet looked into the details of involving function pointers and callbacks.

@noop_dev @lefticus I might be wrong about the timing; the first port might have been after that paper and implicit lifetimes. That still needs some porting because the Doom code used idiomatic C without those casts. There were other issues; I just use that example because it was the first.

@noop_dev @lefticus Yes, no initialization happens, but C++ still distinguishes between uninitialized memory with nothing in it and memory with an object where the bytes happen to be uninitialized. Yes, even an object of POD type.

@daniel_houck @lefticus BTW, if you don't init anything in your constructor, all memory allocated to a class instance remains uninitialized, for members without own constructors (or with empty constructors also), yet this is legal C++. C++ is not mandating you to init memory with or without constructors

@noop_dev @lefticus This is less true now after open-std.org/jtc1/sc22/wg21…, but it is still true for some types. I think everything you can do with arrays and structs in code that’s valid C makes an implicit-lifetime type, but I’m not sure about unions.

@noop_dev @lefticus I didn’t mean a C-style cast was a bug or UB. I meant using the result of `malloc` as a pointer to Foo is UB. There is no `Foo` object there; there is just uninitialized memory and you need to separately create the object with placement new.

@noop_dev @lefticus You can ignore the C programmers I know and say the cast should be there anyway. Maybe I only know bad C programmers. It is still UB in C++, especially six years ago when he did the original port. Do you consider “even UB that seems to work is bad” to be part of the BS?

@noop_dev @lefticus Okay, narrowing down to a starting point. There is a type Foo and a positive int n. In C, if I wrote Foo *foos = (Foo*)malloc(n * sizeof(Foo)); I think every C programmers I know would say the cast is a bug or at least a smell. Without the cast, it does not compile in C++.

@gwenzek @lefticus (for the manual port not the Claude one)

@gwenzek @lefticus github.com/fabiangreffrat…

@harshad1313 @lefticus They definitely do not. They disagree on when objects start to exist and when they stop existing. In C++ a malloc is not always enough to create an object, and especially wasn’t six years ago during his port.

@lefticus Memory model? They have the same memory model?