
Runtime Compiled C++ for Rapid AI Development [pdf] - ingve
http://www.gameaipro.com/GameAIPro/GameAIPro_Chapter15_Runtime_Compiled_C++_for_Rapid_AI_Development.pdf
======
ingve
Found via the Runtime-Compiled C++ blog [0], which also pointed out that all
the chapters from the first volume in the Game AI Pro book series (published
in September 2013) are available for free download from the bottom of the main
Game AI Pro website. [1]

[0]
[http://runtimecompiledcplusplus.blogspot.com/](http://runtimecompiledcplusplus.blogspot.com/)

[1] [http://www.gameaipro.com/](http://www.gameaipro.com/)

~~~
nickpsecurity
I've never seen GameAIPro before. Great resource. Thanks for the link as I
know just who to send it to.

------
awinter-py
whoa, cool alternative to JIT.

Let's hope the future of closures in all languages (C++ through to JS / lua)
is a rich one. The ability to synthesize code at runtime is powerful, but it
would be much more powerful if it were better-supported.

The hoops these guys have to go through to get past console data-protection
bits is insane.

------
dhruvbird
What's the tl;dr for this article? What's the key insight behind making
compile times faster?

~~~
vvanders
Dynamically unloading/reloading DLLs to re-update code.

Cool if you can pull it of, but seems very house-of-cards. All you need is one
bad reference floating around and boom.

I kinda wonder what this would look like in Rust. You could track all the
lifetimes appropriately and make sure nothing got a handle into code that
could be dynamically unloaded.

You'd keep all the native performance gains but without being nearly so
brittle.

~~~
CyberDildonics
Keep in mind that when you have a dll you are unloading instructions, not
data.

Also C++ has unique_ptr that also tracks lifetimes, I don't think Rust would
really give you anything you don't already have and I think you are
overestimating the fragility. I've done hot reloading of .dll and it isn't
really all that fragile. If you have the c runtime as a dynamic .dll the heap
won't be tied to the .dll either.

~~~
steveklabnik
uniqe_ptr does not "track lifetimes".

For example, this Rust program:

    
    
      fn main() {
           let r: &i32;
    
          {
              let b = Box::new(i32);
              r = &*b;
          }
    
          // r is dangling here, this would be bad:
          println!("{}", r);
      }
    

Is caught at compile time. Rust keeps track of the lifetime of both b and r,
and knows that r will be dangling.

The C++ version:

    
    
      #include<iostream>
      #include<memory>
    
      using namespace std:
    
      int main() {
          int *r;
    
          {
              uniq_ptr<int> b(new int(5));
     
              r = &*b;
          }
    
          // r is dangling here
          cout << r << endl
      }
    

This compiles with no warnings under -Wall -Wextra with no warnings, and
happily does whatever you ask with r, even though it's dangling.

Yes, this specific example is a bit contrived, but such is the way of
examples. My point is just that C++'s smart pointers are a great thing, but
that doesn't mean they do everything that Rust's do.

