Have Your Efficiency, and Flexibility Too

Metaprogramming Plus: The Flexibility Enhancements

If you recall from earlier, Flexibility was concerned that the metaprogramming approach seemed to prevent complex configurability. He didn't think he could use complex logic to decide what types of Gizmos needed to be made and how many. The problem is that Gizmo's settings are specified at compile-time, but the logic to determine the configuration may need to happen at runtime. Dr. Metaprogramming knew that could be worked around and promised to show various methods of handing this.

These methods will be demonstrated by making two basic changes to the existing metaprogramming example:

1. Currently, there are 1-port, 2-port and 5-port Gizmos. The 5-port ones will no longer be hardcoded as 5-port. The number of ports on these larger Gizmos will now be configurable via bigPorts.
2. Only 2,000 spinnable 2-port Gizmos will be made instead of 10,000. But 8,000 extra Gimos will be created. The type of these extra Gizmos will be configurable via extrasNumPorts and extrasIsSpinnable.

Naturally, if you want to compare the time and memory usage with all the previous versions, then these values should be set to bigPorts = 5, extrasNumPorts = 2 and extrasIsSpinnable = true.

Note that none of these require any changes to the Gizmo type itself. Only the code in UltraGiz and main() is affected. That is to say, the only changes are in setting up and using the same Gizmo types that we've already written.

Method #1: Compile-Time Function Execution

Frequently abbreviated as CTFE, this method can't be done in all languages. And in a language that does support it (like D) it can be the least powerful method. But it's the simplest and easiest, and is perfectly sufficient in many situations.

Method #2: Compiling at Runtime

On the downside, this method takes extra time (potentially very noticeable) whenever a setting needs to be changed. That may or may not be a problem depending on the nature of the program and the setting. Also, you'll need to distribute your configurable source code along with your program. Finally, this method requires either:

1. The user has the appropriate compiler set up.
2. You package the compiler along with your application.

Note that rules out using this method for most embedded targets.

So ok, maybe this doesn't sound very good so far. However, this method is extremely powerful, viable for a wide variety of languages, and only requires very simple changes to the code being configured. Additionally, the compiler requirement may not be as much of a problem as it may seem if you have permission to redistribute the compiler, or if you're targeting Linux (which generally has pretty good package management and dependency tools), or if your program is only intended for private use.

The trick here is to generate a small amount of source code at runtime, recompile your program, and then run the result.

For simplicity, this example will use a separate "frontend" program that will configure, compile and run the real example program. But you could also have it all in one program: After your program issues the command to recompile itself, it would then relaunch itself (possibly saving and restoring any important state in the process) much like auto-updating programs that download and launch newer versions of themselves would do. Or, you could keep the configurable routines in a DLL or .so, unload the DLL or .so, recompile it, and then reload it.

Method #3: Convert a Runtime Value to Compile-Time

Yes, you read that right. Though it may sound bizarre, like it would require time-travel, it is possible to convert a runtime value to compile-time. Although, it does have some restrictions:

1. The runtime value can't cause anything to happen differently at compile-time. Which is to be expected, since runtime occurs after compile-time. But the runtime value can "pass-through" the compile-time code paths and result in other runtime effects.
2. Every possible value that the variable might hold must be individually handled.

What essentially happens is you take all the compile-time code paths you may want to trigger at runtime, and you trigger all of them at compile-time. Each one of them will produce a result that can be accessed at runtime. Then, at runtime, you just "choose your effect".

If you don't understand that, don't worry. It's really a much simpler, more obvious concept than it sounds. Here's a simple example:

Method #4: Dynamic Fallback

Just like the town elder who made the handcrafted version, we can fallback on a dynamic version that uses runtime options instead of compile-time options.

This is easier and more flexible than the previous method. In fact, method #1, compile-time function execution, is probably the only method that's easier than this, but this one is more powerful and supported by more languages. So this is a pretty good option.

However, the downside is this would naturally be the least efficient of all the methods, since some of the Gizmos would forgo the metaprogramming benefits. But as long as you don't need runtime configurability for all your Gizmos, then you can still get a net savings over the original non-metaprogramming version.