Those who worked enough with C or other procedure oriented languages know how much flexibility callbacks provide. The simplest example is the qsort function of the C standard library. It is also not unintentional that many libraries, windowing system APIs and operating system APIs also highly rely on callbacks to pass a particular task over to another program module and it is one of the fundamental tools needed to implement an event-driven application. At the same time, object oriented languages does not directly support the concept of callbacks as they don’t really fit into the paradigms used by these languages. Fortunately, even if not as a language feature, all object oriented languages support a similar facility like callbacks in the form of delegates.

Delegation as a design pattern is used to describe the situation when one object passes on the implementation of a particular task to another object. This clearly reflects the purpose of callbacks used in procedure oriented languages. Many languages does natively support some form of delegation, some of the well known ones are C# and Delphi.

Callbacks

As mentioned before, the facility present in procedure oriented languages that enables the delegation of functionalities to other modules is done with callbacks. These callbacks are specified by passing function pointers to some registration functions provided by the library. Here is a very simple C example:

/* server header */
void registerFooCallback(int (*fooCB)(int, float));
int doFoo(int a, float b);

/* client code */
int myFooCallback(int a, float b) {
    /* ... do something ... */
}

int main() {
    registerFooCallback(myFooCallback);
    cout << doFoo(5, 3.2f);
    return 0;
}

Here we can see how easily callbacks provide injection of user code for handling events happened in the server.

Delegation as a design pattern

The simplest way to create object oriented callbacks is by applying the design pattern of delegation. If we would like to construct the C++ equivalent of the example above using the mentioned pattern, we end up with something like the following:

/* server header */
class IFooCallback {
public:
    virtual int operator() (int a, float b) = 0;
};

class Foo {
private:
    IFooCallback* _fooCB;
public:
    void registerCallback(IFooCallback* fooCB);
    int doFoo(int a, float b);
};

/* client code */
class MyFooCallback: public IFooCallback {
    int operator() (int a, float b) {
        /* ... do something ... */
    }
};

int main() {
    Foo foo;
    MyFooCallback fooCB;
    foo.registerCallback(fooCB);
    cout << foo.doFoo(5, 3.2f);
    return 0;
}

As you can see, it is quite straightforward to provide an object oriented alternative to callbacks. However, there is a very significant drawback when using the technique above, namely the type intrusion inherently coming from this definition of a callback. The client code needs to explicitly inherit it’s own code from a type defined in the server. This results in tight coupling and is likely to carry other disadvantages inside regarding to maintainability and migration issues.

Delegate methods

In our previous attempt to provide an easy to use C++ alternative for callbacks with OOP in mind we tried to replace function pointers with a pure virtual base class that acts like an interface definition for our callback. However, it somewhat violates the original goals of delegates which by definition should be some form of run-time inheritance (this varies from definition to definition, still, this is the one that I’m referring to in this article). We soon figure out that the most convenient way would be to be able to assign member functions of any class as a callback. Obviously, the parameters and return type should still match as previously to provide type safety, but we would like to remove any additional dependencies between the client and the server.

While C++ does have the term of pointers to member functions there is no easy and standard way to implement callbacks using them. Or is there? First of all, there is no particular problem with class static member functions as they are much like C functions, however, limiting delegates to static methods heavily affects the freedom of the developer. The problem with object member functions and especially with virtual member functions is that they have the implicit parameter this that enables them to access the object they correspond to.

The popular Boost library provides mechanisms that enables the use of object member functions as separate entities by using the bind functor adaptor which became part of the language standard as part of Technical Report 1. This extension makes it possible to use member functions as delegates in a way that does not involve any type intrusion side effects.

Unfortunately, these facilities involve a noticeable performance hit when the callback is invoked compared to simple method invocations. Also, using functor adaptors for implementing delegates is not the most straightforward and makes the code quite ugly compared to an ideal situation when delegates are part of the language itself. Of course, this is only my opinion, others who used these libraries more often may have a different vision about the topic.

Anyway, as for me performance is always a concern, I started to look around for alternatives. It surprised me that I’ve found even two of them very soon:

• Fastest Possible C++ Delegates by Don Clugston – This is a library that provides delegates that are as fast as simple virtual method invocations. The implementation strongly relies on the behavior of different compilers, yet is very portable, at least as far as I can tell.
• The Impossibly Fast C++ Delegates by Sergey Ryazanov – This library was introduced as an alternative to the previous one that strictly relies only on standard features of the languages. Surprisingly, this later is less supported by different compiler implementations and it is also somewhat slower than the previous one.

Personally, I go with the first one as for me performance and portability is more important than conformance with the standard. And, of course, it is not that hard to change the back-end for the delegate support at some time if I change my mind. Finally, lets see how our foo callback looks like when using the fast delegates of Don Clugston:

/* server header */
class Foo {
private:
    FastDelegate2<int, float, int> _fooCB;
public:
    void registerCallback(FastDelegate2<int, float, int> fooCB);
    int doFoo(int a, float b);
};

/* client code */
class MyClass {
    virtual int handleFoo(int a, float b) {
        /* ... do something ... */
    }
};

int main() {
    Foo foo;
    MyClass myObj;
    foo.registerCallback( MakeDelegate(&myObj, &MyClass::handleFoo) );
    cout << foo.doFoo(5, 3.2f);
    return 0;
}

Multicast delegates

The delegates presented previously can only be bound to a single method, as usually delegates behave this way, although a single method can be bound by many delegates. The signals and slots model extends this to a many-to-many relationship. Thus a signal is actually just a delegate that can bind to multiple methods at once. Such a primitive is sometimes also referred to as a multicast delegate.

Multicast delegates come handy especially in case of user interface programming and other situations where the event based programming model is used. The basic foundation behind this programming model is the idea of “subscribe and notify”. That means there are publishers who will do some logic and sometimes publish events. When such an event is published, it is actually sent out to the subscribers who have subscribed to receive the specific event. At implementation level this is nothing more than having a multicast delegate in the publisher object and providing an interface that will be used by the subscriber objects to register one of their methods that has to be called in case a particular event occurs.

There are plenty of signals and slots libraries out there including but not limited to the Boost Signals library. However, again, if performance is a concern one must look around carefully to find the appropriate library suitable for a particular purpose. One such library that extends the fast delegates of Clugston with a signals and slots framework is that of Patrick Hogan’s.

Asynchronous delegates

If we do one more step forward, we arrive to asynchronous delegates that can provide us a flexible yet efficient messaging system for multi-threaded applications. The only additional thing we have to implement a message queue on the callee side and optionally some form of synchronization if we would like to also make it possible for the asynchronous delegates to return data to the caller.

As this topic deserves a thorough discussion on its own, I would recap on the subject in a future article and try to provide a sample implementation using OpenMP as usual.

Conclusion

We’ve just touched the surface of what possible use case scenarios of delegates one can met during software development, still, we’ve seen how many advantages such a programming primitive can give to C++ developers no matter if they are implementing a very simple library of sorting algorithms like the qsort C standard library function or a robust, fully event-driven multi-threaded application. We’ve also seen that there exist several efficient implementations of such a framework for those performance fanatics like me.

It is a perfect example how easily one can extend C++ with another facility that is usually available only in the most modern managed languages. By the way, I would be interested in your opinion what do you like the most in other languages like Java and C#, and you are disappointed that C++ does not directly provide the same thing. Maybe there exists a C++ alternative for those facilities as well, just we have to look around to find them…

As far as I can tell people still prefer using python for scripting in their Delphi projects. This is probably because python scripting in Delphi has a long history and it is a proven method with easy integration. What if I would tell you that there is a free solution which enables you to write also your scripts in pascal? A few years ago I discovered an alternative that makes this possible. This highly influenced my vision about the importance of scripting. Since that I accompanied all my hobby projects with full scripting support.

The first question of the reader might be that why I would need a script language in my program? It is, however, very easy to answer this question. The presence of some sort of scripting support in a software product has many benefits both from developer and customer point of view:

• Less wasted time on software building by customizing application without the need for recompilation.
• Unusually flexible reflection capabilities by creating script code on-the-fly with string manipulation.
• Very flexible debugging possibilities by modifying executed code during the debug session.
• Easy separation of often changing high level logic and rarely changing internal framework.
• Powerful tool for the user to customize application for own needs.

These are just a few examples what additions a scripting engine can give. Personally my favorite one is the second mentioned example in the list above. As a result that I’ve worked as a PHP developer for over a year I really got used to the ability to compose code on-the-fly by just putting some strings together. It is a built-in feature of PHP and most other interpreted languages, however it is fairly uncommon that such functionality exists in native programming languages. I knew that to emulate the presence of this facility I have to use some scripting language but I never thought it will be so easy to find one which suits my needs.

First, I was looking around to find out what other Delphi developers use in their projects. That’s how I first met with python. The language itself has a very powerful OOP tool-set but the syntax was too extraneous for me. After checking tons of other scripting languages out there which had mostly no easy integration possibilities with Delphi, finally I found RemObjects Pascal Script.

Pascal Script for Delphi

First, I just said “Wow! This is exactly what I was looking for”. It not just enables you to write your scripts using the language what you also use to develop the application itself but it also provides incredibly easy integration with Delphi. Just to mention a few features of Pascal Script:

• Calling Pascal Script code from Delphi code or vice versa.
• Using external DLLs from within the script without requiring any type of function header.
• Sharing any kind of data between the script and the Delphi code in both direction.

For a full list of features please refer to the official site of RemObjects Pascal Script.

One thing that most Delphi developers got used to is that most of the third-party components and tools available for Delphi are with a commercial licensing. Well, this is not the case with Pascal Script. It is not just freely available but also comes with full source code. This further increases the potentials of it as you can add new features to it if you wish. However, it is already powerful enough for most use cases.

How it works?

In a nutshell, using Pascal Script is piece of cake. You just have to put together your source code string, compile it and then execute. Yes, Pascal Script needs a compilation phase which produces a byte code as an intermediate format. By telling this, you’ve probably already figured out that Pascal Script is not just very flexible but also provides adequate performance by not having to interpret directly the source code. Let’s start with a very simple script:

{ some very simple pascal script }
begin
  PrintString('Hello World!');
end.

This will call the procedure PrintString with the string parameter “Hello World!” . But where this procedure comes from? Well, actually you have to bind it using the run-time library that comes with Pascal Script. To execute this script having an actual Delphi procedure bound to the procedure name used in the script you’ll need some code similar to the following:

program HelloWorldScript; { host application that executes the script }

uses
  uPSCompiler, uPSRuntime;

procedure PrintString(message: String);
begin
  writeln('Message from script: ', message);
end;

function LoadScript: String;
begin
  { load the script from some file and return it }
end;

var
  Compiler: TPSPascalCompiler;
  Exec: TPSExec;
  ByteCode: tbtString;
begin
  Compiler := TPSPascalCompiler.Create;  // create an instance of the compiler
  // register user procedure to compiler
  Compiler.AddDelphiFunction('procedure PrintString(message: String)');
  if Compiler.Compile(LoadScript) then  // compile the script to byte code
  begin
    Compiler.GetOutput(ByteCode);
    Exec := TPSExec.Create;  // create an instance of the executer
    // register user procedure to executer
    Exec.RegisterDelphiFunction(@PrintString, 'PRINTSTRING', cdRegister);
    if Exec.LoadData(ByteCode) then  // load byte code to executer
      Exec.RunScript;  // run the script
  end;
  Compiler.Free;
  Exec.Free;
end.

If a newbie looks at this code, probably thinks that it’s overcomplicated. Well, actually this is true. Pascal Script needs some basic setup stuff but if you take the time to learn it, you will figure out that it does not involve too much code to use it. One thing that may still need some clarification is the registration of the user procedure provided to the script…

Connecting the script to the Delphi code

Pascal Script needs that all the procedures, functions, variables, types and classes that we would like to provide to the executing script needs to be registered both to the compiler and the executer. The compiler needs this information for syntax validation and to produce the byte code, that’s why it’s enough to provide the signature of the particular language element to it. The registration to the executer is which actually binds the concrete object to the script.

All these manual registrations looks like a pain in the a** at first sight, however, they are unavoidable. Fortunately, Pascal Script provides a very handy tool for us to automate this process, namely the UnitImporter. This tool can create an import unit based on an actual production code unit that will provide one parameterless procedure that registers all the classes, methods, etc. to the script compiler and run-time.

Beside this, Pascal Script provides ready baked units for the registration of the standard units of Delphi and a component set that integrates into the IDE, although I haven’t used them so far. Anyway, even if the framework seems to be a bit too complex and needs too much auxiliary code, in practice it is very easy to use it and most of the support code for scripting can be generated with the UnitImporter. If you don’t believe me, try using it for a while and you will see.

Portability and usage limitations

Maybe Pascal Script is not the Holy Grail of Delphi programmers but it is a very powerful scripting engine. The first question in those who are not developing on/for Windows platform can be that “Is it portable?”. This is another advantage of Pascal Script as it is as portable as Delphi can be. This means that it will work fine also with the Free Pascal compiler and it comes with the same component set for the Lazarus IDE as well.

So if not the portability and the ease of use then has it any disadvantages by the way? Unfortunately, yes. We’ve already seen that it has both-way interworking capability with Delphi, it has tools for automating the integration process and it can be used also for cross-platform projects, but it has small problem: it supports only a subset of the Delphi language so you cannot define classes in the scripts. You can still use classes and objects inside the script, but only those which were defined in the host Delphi application.

Anyway, this does not necessarily mean that Pascal Script is not flexible enough. I used it in my project mainly for the following purposes:

• Using the services provided to the script (classes, objects, etc.) to manipulate application behavior at run-time.
• Handling Delphi events with procedures/functions implemented in scripts.
• Baking a console that makes debugging tasks much easier by correcting errors while the program is running.

Personally I don’t understand how Embarcadero Technologies (the current supplier of Delphi) haven’t integrated it into the core Delphi distribution as they did with many other popular frameworks like DUnit.

Conclusion

Pascal Script is probably not a script language that can have a future on it’s own but it is still a great addition to the feature set of Delphi as it provides a way to push the flexibility of the language above it’s limits with minimal effort. It is fast, robust and stable, and it offers most of the facilities that usual developers expect from a scripting language. Maybe I’m quite biased as I really enjoyed working with Pascal Script, but I think you Delphi programmers out there should definitely take a look at it and give it a try.

Those who know me know it well that I am not a big fan of languages which produce managed code. In this article I would like to cover the reasons behind my skepticism. Also I would like to dispel the myths around such languages and try to prove them with facts (we will see how well I manage to achieve this). If you disagree with me, you’ll most probably hate me because of making this post but please, respect my personal point of view.

As I’ll mostly talk in this post in general about managed code I would like to emphasize that I have worthwhile experience only with Java and have barely used C# and other managed languages so my primary arguments maybe apply directly only to Java but still would like to present my arguments in general as they still apply in some way to all such languages.

Without the intension to insult anybody, I would like to start with a citation from one of my friends, who often says that “Java is just a pseudo-language”. Mostly I agree with him and it’s not just because I have my not so delightful experiences with the language but also because it introduced a brand new way of coding style that is a complete nightmare for an old-school coder like me. As I don’t want to start another religious war, I’ll stop my preposterous arguments here as I would like to prove my concerns with facts that nobody can disclaim.

“… nowadays Java is almost as fast as native code…”

This used to be a common myth in the last few years. For those who are still arguing by shouting this loud on forums and blogs, I would like to draw their attention to the fact that Java is still an interpreted language no matter if the latest JVM versions do some on-the-fly compilation of the code and as such it is inherently slower than any language that generates native code.

As my hobby is computer graphics I have to talk a bit about the case of PC games. Have anybody seen a game fully written in Java or any other interpreter based language that produces state-of-the-art graphics which competes with the best professional games and it also provides the same performance? I think not, and this is not a coincidence.

GPUs are getting more horsepower in a much faster pace than CPUs. That is what resulted in the batch crisis lately. It’s already happening for several years that the CPU is simply not powerful enough to feed the GPU with enough data in complex real-time rendering situations. There have been already tons of different software and hardware technologies which already targeted this issue a long time ago but as a perfect example that is the reason which resulted in the appearance of the completely redesigned DirectX 10 API and which emerged the need for a cleaner architecture for OpenGL as well. That’s why there are no advanced games written in interpreted languages as they waste those very valuable CPU cycles which would have great benefits otherwise.

“… Java has a much greater expression power…”

I tend to agree with this one. As these languages are interpreted by a virtual machine they provide great room for such features that would be impossible or simply very inefficient in a native language. That’s why one of my favorite programming language is PHP as an example. It is even more flexible then Java, for example, but never forget that PHP never meant to try to replace native languages as instead it is used in a totally different domain.

There are many language features that are not available in native languages but they weren’t left out unintentionally. Their lack is primarily justified by the fact that most of these features are rather inefficient and they simply not fit in the philosophy of a performance oriented language like C++. However, the most important ones like reflection, delegates and most OOP related facilities are present for example in Delphi, which is one if not the best OOP language that doesn’t make too much trade of between flexibility and run-time performance. Also, even if most of these features are not present in C++, Objective-C and other popular native languages, they can be made available with a little programming knowledge in the particular language (maybe not just little).

“… you don’t have to care about resource deallocation as there is the garbage collector…”

This is one of the most annoying “features” of managed code based languages. I understand that the prevention of memory leaks can have a great impact on development effort, however the unpredictable behavior of garbage collectors is simply unacceptable in certain situations. The issue of lost references has been already addressed in almost all native languages with the use of reference counted objects so I simply don’t get it why is this still an important feature. For efficient resource management you need much finer control over the time and way how resources are released.

“… you just have to care about the basics and Java will make you the rest…”

While I strongly support the idea of COTS, the way how Java and friends interprets this concept is simply unacceptable for me. Sometimes you need to know what is going on under-the-hood. This is basically the same issue like that of the garbage collector. Beside that, according to my personal taste, I don’t like if the compiler tells me how to do a particular thing. I rather do it in my way and even if I tend to agree that the compile time static analysis what the Java compiler does can be very valuable in some situations, simply denying code generation even in the case of a very minor semantic problem is simply makes me angry.

“… Java eliminated almost all unsafe features inherited from C++…”

This is one of the things that hurts me most. While Java really managed to achieve this, it sacrificed flexibility, ease of use and the fun of programming to make this possible. One such removed feature is operator overloading. I love them! As an example a linear algebraic library, which is often used in graphics programming, or the string library is not just makes the coding more natural, it eases the reading of code which is written with these in mind and that greatly effects the maintenance cost of a particular software as the code is read ten times more than modified. Java in this domain seems too verbose for me and it is much harder to read the long method invocation chains, that is not just used to be used by the developers, but is the recommended way how to code in Java.

This post already ran wildly long so I will close the topic for now. As a conclusion, I have to point it out that this article presented the subject from a rather subjective perspective at the end. Sorry for that, I will recap on the topic in a later post where I will try to be more detached and I’ll present actual use case examples but for now, this is all that came from my heart so please, don’t be very harsh with me if I was very biased. I hope you enjoyed the article anyway.