Implementation of a Peer-to-Peer Multiplayer Game with ... - DVS

4.6.2 Implementation ConcernsUnlike C++, Standard ML is not object oriented and thus does not have the concept of classes. Butthe CUSP API with its signatures and implementing structures for endpoints, hosts, streams, etc. can bemapped directly to an object oriented API providing a corresponding class for each signature. The mainchallenge when creating C++ bindings for Standard ML is how to cleanly map between the garbagecollected Standard ML environment and C++. The solution developed for this purpose is generallyapplicable for mapping Standard ML structures to C++ objects.The C interface exported by the Standard ML glue code makes the structures accessible via handles.Whenever a structure is to be passed to the C part, it is internally stored in an IdBucket which returnsthe index of the newly inserted element. That index is passed to C as a handle. Accordingly, anyfunction that takes a structure as a parameter is exported to C expecting a handle. When called, thestructure is retrieved from the corresponding IdBucket and the wrapped function is invoked. By keepingthe structures in the IdBucket, they remain referenced within Standard ML and thus are preventedfrom being garbage collected while still being needed by the C part. Consequently, it is the C part’sresponsibility to free all structures when they are not used anymore. All three operations of IdBucket,storing, retrieving, and removing structures, have O(1) complexity. Structure retrieval is based on anarray lookup by index, while storage and removal of structures profits from keeping a linked list of freecells.The object oriented C++ interface in turn wraps the exported C functions. Although the C functionscan be used directly by applications, that is not recommended. Especially because of the need for explicitlyfreeing any handle ever obtained, using the C interface is both inconvenient and error-prone. TheC++ API disburdens the programmer from most of those tasks. Each C++ API class basically just keepsa handle to the corresponding structure in Standard ML. Creating, copying and deleting classes can bedone in the usual C++ way and the whole handle management is safely wrapped. The resulting C++API classes match the Standard ML signatures (for an overview see 2.5.2) with only a few exceptions.But still there is one important difference significantly affecting the usage of the C++ API, which isthe lack of closures and/or lambda calculus in C++. As the CUSP API is completely asynchronous, thereis often the need for passing callbacks. Standard ML provides closures, allowing to pass functions thatkeep their surrounding scope, greatly simplifying the programming and improving code readability. InC/C++ it is in most cases necessary to explicitly define and create an object that keeps the context thethe calling function and that is passed with the callback function. This limitation of C/C++ cannoteffectively be overcome. The solution chosen here is to provide interfaces (i.e., purely virtual classes)as callback types, which is the typical way of implementing callbacks in Java 9 . For instance, EndPointdefines a handler interface for the contactPeer() method:class EndPoint{(...)class ContactHandler {public:virtual void onContact(Host& host) = 0;virtual void onContactFail() = 0;};void contactPeer(const Address& addr , ContactHandler* handler);}(...)9 http://www.javaworld.com/javaworld/javatips/jw-javatip10.html68 4.6 CUSP Bindings