Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why C++ for Unreal 4

forums.unrealengine.com

Post reply on HN
Print view View original

111–120 of 178 posts

Re: Why C++ for Unreal 4

#111

Post by hyp0 »

k00pa wrote: post #98
hyp0 wrote: post #92

Earlier quoted context omitted.

It was an example of losing dominance, not to do with open. Re: vehicles. I'm going by what Carmack said in an interview.

That sounds really weird, do you have a source for that interview?

I agree it sounds weird!

He was talking aboout the time around Unreal Tournament 2004, and at that generation, it was a big thing (kinda like waving grass was at one time).

Sorry, I don't recall which interview (and it would be hard to google unless there's a transcript). It might have been one of his keynotes, perhaps the one with Rage on an iPhone. I'm pretty sure it was a long one (at least 1.5 hours). It was one of the big popular videos on HN/r/programming (not an esoteric one).

Re: Why C++ for Unreal 4

#112

Post by bjz_ »

mattgreenrocks wrote: post #107
bjz_ wrote: post #97

Earlier quoted context omitted.

- Fine grained control over allocation whilst maintaining memory safety (stack, heap, RC, GC, or roll your own) - No null pointers (with an Option type that compiles down to a nullable pointer) - Data race free concurrency - Zero cost abstractions - RAII and destructors - No exceptions - A modern, highly expressive type system - Generics that throw type errors at the call site, not deep in a template expansion - True…

I was being a bit flippant when I posted, but I'm really impressed with the list. I need to look into seeing where I can help on the compiler or runtime. No exceptions is my only objection, but I know they're dubious for a systems language.

No worries, it was a good question! I would highly recommend hopping on the IRC if you'd like some more information or have a chat. The community is very active and friendly. You can see the list of channels here: http://static.rust-lang.org/doc/master/index.html#external-r...

Regarding exceptions: whilst they can be be very useful, unfortunately a significant number of large, performance sensitive C++ projects outlaw them due to overhead and safety concerns (the semantics can become quite hairy when mixed with destructors). The Rust developers felt that it was easier to forgo them entirely.

Re: Why C++ for Unreal 4

#113

Post by [deleted] »

mattgreenrocks wrote: post #107
bjz_ wrote: post #97

Earlier quoted context omitted.

- Fine grained control over allocation whilst maintaining memory safety (stack, heap, RC, GC, or roll your own) - No null pointers (with an Option type that compiles down to a nullable pointer) - Data race free concurrency - Zero cost abstractions - RAII and destructors - No exceptions - A modern, highly expressive type system - Generics that throw type errors at the call site, not deep in a template expansion - True…

I was being a bit flippant when I posted, but I'm really impressed with the list. I need to look into seeing where I can help on the compiler or runtime. No exceptions is my only objection, but I know they're dubious for a systems language.

[deleted]

Re: Why C++ for Unreal 4

#114

Post by bch »

flohofwoe wrote: post #79

We've also been there done that (about 10 years ago though), we had a very powerful scripting approach integrated into our game engine which gave direct access to game play systems in order to let our level and game designers build scripted behaviour into the game. In the end we ended up with a terribly huge mess of script code (I think it was about a third of the actual C/C++ code) and the majority of the per-frame…

> The main problem with scripting layers is that you are basically handing programming tasks over to team members who's job is not to solve programming tasks, and thus getting a lot of beginner's code quality and performance problems which are almost impossible to debug and profile

I disagree that it has to follow that scripting -> bad code. I think of the C scripting integration that I do as a Judo secret weapon. I get to easily fling "high-performance" C around in a super-dynamic way (REPL, easy-to-use high-level abstractions)... I think the problem you're describing is real (possibility to abuse/mis-use scripting power), but dismissing the notion of scripting plus C/C++ because of possibility of abuse seems like throwing out the baby with the bathwater. Better addressed with training and culture.

Re: Why C++ for Unreal 4

#115

Post by pcwalton »

zanny wrote: post #87
pcwalton wrote: post #76

Earlier quoted context omitted.

> Furthermore, there's some great tools out there to help prevent things like memory leaks. Combine that with good company practice, like code reviews, and it becomes a non-issue. The security track record of applications written in C++ disagrees with you.

We are talking about new engines written in these languages, though, not multi-decade old codebases still using inline assembler, goto, and pointer arithmetic. Modern C++ is really safe if you use the subset that involves automatic storage duration, well bounded arrays, etc and use all the warning flags of your compiler, run static analysis, have a robust test framework, etc.

No, modern C++ is not even close to memory safe. This is my favorite meme to destroy over and over on HN. :)

Consider iterator invalidation, null pointer dereference (which is undefined behavior, not a segfault -- and you can't get away from pointers because of "this" and move semantics), dangling references, destruction of the unique owner of the "this" pointer, use after move, etc. etc.

Re: Why C++ for Unreal 4

#116

Post by bjz_ »

forrestthewoods wrote: post #106
steveklabnik wrote: post #103

Earlier quoted context omitted.

iOS, PS4, and XB1 are missing. I know it's not your point, just providing some answers in case someone is wondering.

I was making a point and asking a real question because I didn't know. I checked wikipedia and couldn't get a clear answer. So thanks! Sticking with C/C++ also means you'll be able to more easily port your game to any platform of the future. It's just a safe bet that any future platform (either hardware or software) will support C/C++. Especially for games. Anything else is a dice roll. Sometimes a roll worth taking,…

I think it will most likely be smaller devs and indies who use Rust for game dev initially. Once demand grows, hopefully there will be better cross platform support in the future. Thankfully Rust emits LLVM IR, so that will make expanding to more platforms like iOS, PS4 and Enscripten much easier. XB1 would still be an issue though... not much you can do about that though.

For me, Mac/Win/Linux/Android/iOS support is more than enough, and I think it will be enough to bootstrap the language into some level of industry acceptance. It depends on the project really, and how much the developer values console support over the benefits that a modern systems language like Rust provides.

Re: Why C++ for Unreal 4

#117

Post by steveklabnik »

pcwalton wrote: post #115
zanny wrote: post #87

Earlier quoted context omitted.

We are talking about new engines written in these languages, though, not multi-decade old codebases still using inline assembler, goto, and pointer arithmetic. Modern C++ is really safe if you use the subset that involves automatic storage duration, well bounded arrays, etc and use all the warning flags of your compiler, run static analysis, have a robust test framework, etc.

No, modern C++ is not even close to memory safe. This is my favorite meme to destroy over and over on HN. :) Consider iterator invalidation, null pointer dereference (which is undefined behavior, not a segfault -- and you can't get away from pointers because of "this" and move semantics), dangling references, destruction of the unique owner of the "this" pointer, use after move, etc. etc.

You should write something up with actual code samples. I would also love to actually demonstrate this to people.

Re: Why C++ for Unreal 4

#118

Post by JoeAltmaier »

pcwalton wrote: post #115
zanny wrote: post #87

Earlier quoted context omitted.

We are talking about new engines written in these languages, though, not multi-decade old codebases still using inline assembler, goto, and pointer arithmetic. Modern C++ is really safe if you use the subset that involves automatic storage duration, well bounded arrays, etc and use all the warning flags of your compiler, run static analysis, have a robust test framework, etc.

No, modern C++ is not even close to memory safe. This is my favorite meme to destroy over and over on HN. :) Consider iterator invalidation, null pointer dereference (which is undefined behavior, not a segfault -- and you can't get away from pointers because of "this" and move semantics), dangling references, destruction of the unique owner of the "this" pointer, use after move, etc. etc.

Extraordinary claim- please elaborate. I'm working on 100's of thousands of lines of C++ code with a medium-sized team; memory issues are almost non-existent because of disciplines described above.

Re: Why C++ for Unreal 4

#119

Post by bjz_ »

pcwalton wrote: post #115
zanny wrote: post #87

Earlier quoted context omitted.

We are talking about new engines written in these languages, though, not multi-decade old codebases still using inline assembler, goto, and pointer arithmetic. Modern C++ is really safe if you use the subset that involves automatic storage duration, well bounded arrays, etc and use all the warning flags of your compiler, run static analysis, have a robust test framework, etc.

No, modern C++ is not even close to memory safe. This is my favorite meme to destroy over and over on HN. :) Consider iterator invalidation, null pointer dereference (which is undefined behavior, not a segfault -- and you can't get away from pointers because of "this" and move semantics), dangling references, destruction of the unique owner of the "this" pointer, use after move, etc. etc.

I agree with Steve here - in this instance a catalogue of code examples would be much a great deal compelling than natural language explanations.

Re: Why C++ for Unreal 4

#120

Post by VikingCoder »

greggman wrote: post #95
flohofwoe wrote: post #79

We've also been there done that (about 10 years ago though), we had a very powerful scripting approach integrated into our game engine which gave direct access to game play systems in order to let our level and game designers build scripted behaviour into the game. In the end we ended up with a terribly huge mess of script code (I think it was about a third of the actual C/C++ code) and the majority of the per-frame…

The biggest advantage of scripting for me has been 1. Co-routines Co-routines (co-operative multi-tasking?) mean you can do stuff like while (isWalking()) { advance(); yield(); } This is effectively 'yield' from Python, C#, etc.. You can implement this in C++ by swapping stacks and calling setjmp but there's usually issues. 2. Iteration time You can usually swap script code live. This project aims to fix that for C++…

I've been using threads to do co-operative multi-tasking, for a while now.

Every place that I'm tempted to write an event-driven finite state machine, or something similar, I spawn a thread instead. I get to write synchronous code, which feels much more natural to me.

For instance my actor, running in a thread, calls a function like advance(). That drops data into an object, and wakes up the main thread, and blocks.

The next time the main thread wants to give processing time to the actor, it describes the world into the same shared object, waked up the actor's thread, and blocks.

Doing a switch like this dozens or even hundreds of times per second seems to work pretty well, especially if the main thread only gives execution to the actor thread when it needs to - inputs have changed, etc.

For my use cases, it radically simplifies my code, and I have a small number of different inputs to handle, so it has been scaling well.

Post reply on HN