When the need arises

A side note: since “shared libraries” was quite long to type each time, I abbreviated it to “SL”.

A plug-in is needed when you wish to alter the implementation of a specific part of an already compiled program. A script, as well as a SL, is simply a module which you can fit inside an already compiled program to work with that program, so they are excellent for use as a plug-in. Changing from one version of the plug-in to another would be like changing the tire of a bike: you don’t need to take the whole bike apart to replace a part of it. The same goes for programs: you don’t want to compile the whole program to alter a small part. Most IDE’s take care of this pretty nicely, take my C++ IDE Code::Blocks for instance. The IDE automatically generates a makefile and can recompile in such a way that whenever I change a implementation file, but not the header, the only steps it needs to do again are compiling that small source file and re-linking it to main. Here’s an example of the output Code::Blocks shows me when first compiling the main program with a header and an implementation for that header, and then changing the header.

Compiling: main.cpp
Compiling: foo.cpp
Linking console executable: bin\Release\TMP.exe

And after changing foo.cpp:

Compiling: foo.cpp
Linking console executable: bin\Release\TMP.exe

As you can see the most basic option is to simply get the source, compile it once (from scratch) and after that you can alter whatever you want at basically the same cost as scripts/SLs, even slightly less since the program does not have any glue-code for loading (and interpreting) SLs (and scripts). So why doesn’t everyone do this?

Well, most people don’t have a fast computer, compiling a big program can take a lot of time, but that’s a one-time investment so shouldn’t be a biggie.

What could be a biggie is not being able to compile the thing! Closed-source, yeah that won’t work. Some weird compiler costing a bunch and the program only compiles on that one? That neither.

To circumvent these problems, you can build your code that calls something from outside the program, such as a script or a SL!

Differences

So what’s the big difference between a script and a SL? Most differences come with a downside or a benefit (or both, as it depends on what you’re striving for).

Interpreted vs. Compiled

Scripts are interpreted at runtime, this gives them a bit of overhead at first, but this overhead should be negligible on the next passes due to the script being compiled once and thereafter being retrieved from the cache (most of the time). Further discussion about the speed and memory usage of interpreted code versus compiled code will be kept to a minimum.

Deployment time

SLs would take a bit longer to deploy. Change a script in any editor, save it and you’re done. To recompile a SL, I open up my project file, change the code, compile, and then I’m done. Compiling can take a few seconds and is largely dependent on the size and complexity of the code (for C(++) at least).

Code Access

A big advantage of SLs (in the same language, or closely related such as C and C++) is the ease of merging the module with the main program. Give the code the right headers, and you can do anything you could do in the main program. This is pretty hard to do in most scripting languages, often consisting of macros and other code that only exists to glue the script and the program together.

Languages

Scripts are obviously in a different language, but SLs don’t need to be. However, if SLs are in a different language, you need to learn how to compile it in such a way that the compiled code can be called from your main program’s compiled code, make sure it matches the calling convention, variable types, etc. When you want to change or add a scripting language (so that your program can use it) you need to add that functionality in your main program… It doesn’t really differ a lot in difficulty I think. However, most scripting languages are more oriented on ease-of-writing than on speed, as opposed to compiled languages. Therefore, it depends on what you want with this specific plug-in.

Portability

With more and more people “fighting the good fight” everyday, more people are going Linux. Therefore in general people give a bit more if their program runs on more platforms. When writing a script, most of the time you’re done for each platform: the APIs you used belong to the script, not to the platform, as is the case with compiled languages. Making compiled languages portable is a bit harder, since you are then dependent on another library such as Boost, or on some other kind of construct in your source. Preprocessor directive #ifdef works well for small algorithms in my opinion.

List-it

Lets whip up a quick list of benefits and downsides of the options

• Scripts
• Benefits
• Low deployment time
• Potentially faster due to JIT compiling can take advantage of variables known at runtime.
• More portable in general.
• Downsides
• Needs a library that ships along with your app (separate or statically linked, doesn’t matter), given that the library (in the right version) isn’t already available on the system.
• Needs some “glue”-code for exposing the program’s data to the script, so you can access the program’s variable from the script.
• Needs to be recompiled each time the program is launched, given that the interpreter doesn’t store a cache of course.
• Shared Libraries
• Benefits
• Can really act like a part of the program, or at least easier then mixing compiled code with interpreted code.
• Potentially faster due to compiler can make expensive optimizations. It’s okay for a compiler to take a bit longer to compile a SL than for a script interpreter.
• SLs can be closed source whereas scripts obviously cannot be as easily (need to be obfuscated/repacked in some way). Some people may not find this a benefit, but I do, the choice to go open or closed shouldn’t depend on whether the code is easy to hide or not.
• Downsides
• Longer deployment time, but shouldn’t be really different.
• User can’t really check what the library is doing, it could be “bad” code, such as a virus.

So there you have it! A neat list, if I say it myself, with benefits and downsides of the options. I tried to make it as complete as possible but feel free to leave a comment if you think you can add something. For large programs, I think I’ll go for SLs at first, then for scripts to end up with a hybrid solution. For example: if you want to use a lot of internal classes of your C++ program, it’s way easier to go for a SL. On the other hand, if you want to be able to quickly see what different code has for effect, go for a script. If you want both you’re fsked and still have to make a choice. A good and well known example of a hybrid program is Blender: compiled in C, C++ and Python, it uses quite a lot SLs and also has support for Python scripts.

I hope you enjoyed reading the article, I sure did writing it. Thanks go to Maurice Bos of BosByte and Michael of this great site for correcting and in general improving this article. Stay tuned for more articles, there’s a small abstraction tutorial coming up!