dougbinks

The purpose of Runtime Compiled C++ is robust 'hot reloading'.

Yes it does, and recently they made Live++ free for Unreal users. I maintain a list of alternatives to RCC++ on the wiki: https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledC...

The issues you mention exist in C++ without runtime compilation, so don't pose a particular blocker to using runtime compilation when you want fast iteration in C++. This is all intended for development environments, so 'destroying the world' simply means closing the application and restarting, which without RCC++ is something you have to do every time.

So there may be benefits to using Rust, but the issues you've posed are not ones I've found were my primary concerns when working on code which needs fast development iteration.

Thanks for this insightful comment. I shall remove my head from my arse (I'm British) for just a moment so that I can see the monitor sufficiently well to type a response.

The article covers a number of areas where scripting languages fall down in practice as a solution for fast iteration in many area of game development. Please see section 15.2.1.

Runtime Compiled C++ (code avaialble on github https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledC...) allows you to change a C++ program whilst it's running.

It uses shared libraries (DLLs) to do so, but manages the creation of these for you so you don't have to set it up. Only the required changes are re-compiled and linked into the shared library, which improves turn around times over approachs such as UE4's Hot Reload which recompiles the entire game lib.

We included crash protection into RCC++: http://runtimecompiledcplusplus.blogspot.co.uk/2011/09/crash...

I use RCC++ daily as part of my development routine, and although you can introduce problems which mean you need to relaunch the program, the fact that you save having to do so most of the time is a big win for iteration.

No, it's just that the developer likes to recreate these scenes to show off the editor and renderer.

Format of the data is listed as Arc/Info ASCII Grid (AAIGrid) which is an ASCII Esri grid https://en.wikipedia.org/wiki/Esri_grid.

This is the second post detailing the open source task scheduler enkiTS, the first I linked to on HN here: https://news.ycombinator.com/item?id=10103757

Please do comment here, on the blog or via twitter to @dougbinks. I'm on European time so may not get around to replying until tomorrow, but I'll try to reply to any questions that come through asap.

For those interested in the implementation of atomic operations see Jeff Preshing's "How Ubisoft Develops Games for Multicore - Before and After C++11", especially after 15m55s in on the video, or slide 37 of the pdf on github.

Video: https://www.youtube.com/watch?v=X1T3IQ4N-3g&feature=youtu.be...

PDF: https://github.com/CppCon/CppCon2014/tree/master/Presentatio...

Cilkplus is a valid approach if you are interested in using a task and data parallel language extension available on Intel's compiler, newer variants of gcc and Intel's fork of clang. As mentioned in the article a more comparable library for standard C++ is Intel's Threaded Building Blocks.

I used to work at Intel and was a technical lead for games developer architecture feedback and ran the multicore gaming initiative for a while. The feedback on cilkplus was that it didn't allow sufficient control, and as a non-standard language feature posed issues for porting to some systems. Intel's TBB however has been used by some games developers, and its API has evolved features in response to game developer feedback. Most games developers however prefer to roll their own.

Note that I didn't downvote this, but if you wanted to implement a task scheduler (the subject of the post) using cilkplus wouldn't be an obvious starting point.

The task library enkiTS has a C interface, though this simply wraps the C++ implementation. Writing a C implementation from that interface would be pretty much the same, however the virtual function and inheritance would be replaced by a function pointer and plain struct.

volatile is a pre-requisite for implementing atomic types, as used in the post and enkiTS. It is not on its own sufficient however, and so I use both atomic intrinsics and memory barriers where appropriate. This is mentioned in the article, though obviously I need to emphasize the role of volatile more.

Thanks for responding here - this is correct. In the case of implementing atomic types (the use case for enkiTS) volatile is a prerequisite but not on its own sufficient - hence I use atomic intrinsics and memory barriers where appropriate. The repository on github notes that I've only implemented these for Windows, Linux and OSX on Intel x86 / x64, but a C++11 branch exists for those who want.

Putting a developer blog post out on a Saturday just before you head off for the night (I'm on European time) is about as irresponsible as lockless multithreaded programming without a code review. So please feel very free to comment here, on the blog or to @dougbinks on twitter and I'll get back to you asap!

Adding object file persistence for faster compiles on Linux and OS X may cause some issues with developers current configurations, so I'd be happy to here of any issues either here, or via the projects github issues https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledC...

A lot of the complexity of the RCC++ solution over others (I listed those I can find on the wiki https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledC...) is about compiling the minimum possible code quickly in a platform independent way. I'd love to see C++ get modules in the spec, along with introspection to make this easier.

Compiling C++ code at runtime is less about end-user code than about improving developer workflow for those who use C++ and want rapid iteration (game developers for example), so avoiding extra languages and VMs is one of the goals.

As for full dynamic dispatch, RCC++ does use virtual functions. I advocate using a 'data oriented approach' so the function table pointer lookup should be amortized by having expensive functions process multiple data items. In practice in my own code I see no detectable overhead.

Yes, I do need to add more docs - work is getting in the way a bit at the moment though I'm using RCC++ for that so am maintaining and improving it as I go.