Skip to content
Doug Binks edited this page Jan 13, 2020 · 14 revisions

Known Issues

The Runtime Compiled C++ project is currently in a prototype stage and so has a number of significant known issues.

  • The Windows file watcher API ReadDirectoryChanges is not compatible with FindFirstChangeNotification. If you are using FindFirstChangeNotification switch to the alternative API using the define WIN32_FW_USE_FINDFIRST_API
  • Incorrect serialization point for proper error recovery: we currently serialize out from the old objects into the new ones without considering corruption of the old objects from errors. This is something we'll fix by adding 'known good' save points.
  • Odd dependency bug in Visual Studio project can cause code which needs compiling not to be compiled when built inside the Visual Studio IDE: This doesn't appear to be a fundamental issue with the runtime compilation, but instead a potential bug in how Visual Studio handles the macro and/or templates used for the base object code. For example, sometimes changing an interface doesn't result in dependant code being compiled by Visual Studio during the normal build process. If you get odd crashes, this might be the source.
  • Can't add new source files at runtime: This is less an issue with the underlying framework than with the current example project, as this feature can be implemented fairly trivially. There are several options available, from monitoring directories for new files to including an 'Add Source Code" dialogue. Interoperating well with IDEs at runtime is one potential issue we will potetentially need to overcome.
  • Memory leaks: We currently have several potential leaks from the system, the largest being that we don't actively prune the dynamically loaded libraries which are no longer referenced. These do not effect a shipping app which does not use RCC++ in the final build.
  • GDB does not work well with the error handling system. The error signal is received by GDB and it breaks the application as expected, but when continuing it does not pass the signal on to the application unless the user sets up an ignore list. LLDB handles this nicely, allowing the RCC++ error mechanism to catch the signal. This does not prevent the error handling mechanism from working if no debugger is attached.