Page 1 of 2
C++ port of Doom from C
Posted: April 9th, 2020, 5:29 pm
by albinopapa
Jason Turner - C++ Weekly - 9hr+ port of "Crispy Doom"
After watching this, I'm so glad C++ is what it is. If I had to write in C, I'd have to visit one of those places that ties you up and doesn't let you go until you mention the safe word just to keep sane.
I really thought C was a somewhat type safe language, but the amount of tricks pulled in Doom back then tells me otherwise. Void* used for polymorphism for both types and functions. Forward declarations differing from definitions and the compilers still working out what functions to call, it's maddening.
Anyway, I hope this becomes a full series, which is why I'm posting here, in case anyone is interested in seeing the absurdities of the C language and also the kinds of stuff developers had to go through 20-25 years ago.
Re: C++ port of Doom from C
Posted: April 11th, 2020, 3:15 pm
by chili
I've seen that in my subscription feed over the past weeks. I'm not a fan of 'pure C' as it tends to be practiced. I can see how some people might not be down for learning curve the C++ presents. Those people should probably look at Rust.
Re: C++ port of Doom from C
Posted: April 12th, 2020, 5:53 am
by albinopapa
I think it's Rust that I've heard good things about, but I've not looked into it.
The video is quite long and the funny thing is as the time drags on, you get to watch Jason go from "gung-ho" to "Just do whatever until it works".
I'll be following the series just to see what kind of tricks he pulls using C++ features. I've been messing with the Crispy Doom with my own port of it. I'm glad I watched it though, because I think dealing with some of the C hacks would have drove me mad.
Re: C++ port of Doom from C
Posted: April 14th, 2020, 9:01 am
by MyK_00L
You should really look into Rust, it took me a while to get used to it, but now I really like it.
Unfortunatelly it sucks for competitive programming so i still use C++ for that.
Still, I think C and C++ are better for educational purposes.
Re: C++ port of Doom from C
Posted: April 14th, 2020, 5:30 pm
by albinopapa
What are some things you like about Rust? Sell me on it LOL.
Re: C++ port of Doom from C
Posted: April 15th, 2020, 10:06 am
by chili
The package system seems great, and it has some first-class support for resource ownership semantics that C++ is lacking.
Re: C++ port of Doom from C
Posted: April 15th, 2020, 5:24 pm
by albinopapa
chili wrote: ↑April 15th, 2020, 10:06 am
The package system seems great, and it has some first-class support for resource ownership semantics that C++ is lacking.
I'm wondering if what you are referring to is after transferring ownership, the source object is invalid in Rust as opposed to C++, where the object is "empty" but valid?
Re: C++ port of Doom from C
Posted: April 16th, 2020, 8:06 am
by chili
I'm no expert on the subject, having not coded in Rust myself. But I take it there are advantages in the borrow system, improvements on stuff like lifetime of temporaries maybe?
https://doc.rust-lang.org/1.8.0/book/re ... owing.html
Re: C++ port of Doom from C
Posted: April 18th, 2020, 7:50 pm
by MyK_00L
The cool thing is that it does all this stuff compile time and guarantees that your code is not going to do bad stuff with memory, which means rust code without unsafes cannot be exploited.
Also I really like the functional side, with lazy functions on iterators, and matches.
The package system IS amazing.
I like pretty much all the design choices, the only downside is compilation time
Re: C++ port of Doom from C
Posted: April 18th, 2020, 11:26 pm
by albinopapa
A better package system is definitely needed for C++. I find it stupid that I have to learn a whole new language "CMake" if I want to use it. I for one rarely get it to work as expected even with the built in support through VS. I'm always getting errors of some kind. It would also be nice if dependent packages would be download as well. I normally just end up searching for and downloading all the required packages separately because CMake and vcpkg rarely work.
This is why I believe the standard library should contain abstractions for all parts of the computer from sound to graphics, networking to file system, memory to processor ( std::unique_ptr and std::thread ).
As far as the functional stuff, I'm not a big fan. Declarative programming is nice, but not at the cost of memory and performance.
Pattern matching for types would be better than the std::visit b.s. for std::variant right now. I mean how about:
Code: Select all
void func( std::variant<int, float, double> const& var )
{
switch<T>( var )
{
case<int>: const auto i = std::get<int>( var );
case<float>: const auto f = std::get<f>( var );
case<double>: const auto d = std::get<d>( var );
}
}