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.
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.
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.
