Our goal in this book has been to develop components that connect a C++ codebase (albeit a simple, slightly artificial one) to client software written in other languages, specifically C#, R, and Python. The intention has been to make the functionality in a C++ library available and to allow access to this functionality from other client languages. This is what we have accomplished. In doing so, we have covered quite a lot of ground.
We started off by building a C++ library of statistical functions. This has formed the basis of what we want to expose to clients. The reasoning was that it was simple enough to understand but more complete than a toy example. It has enough features to illustrate real-world issues when developing wrapper components that connect to other languages. Throughout the book, we have let the source code drive what we want to expose, and while this has limited the coverage somewhat, it is also more manageable.
On top of this C++ codebase, we have built wrapper components that allow us to expose the C++ functionality to different languages. Firstly, we built a C++/CLI assembly. We saw just how easy it was to use in a number of different contexts. We exercised the functionality in a simple console client – testing both the functions we call and how the component interoperates with other C# libraries (in this case Accord.NET). We also connected our component to Excel via Excel-DNA with minimal effort.
After this, we built an R package that uses Rcpp to connect the C++ codebase to R. As before, we exercised the basic functionality, but also had a look at using the StatsR component with other R packages, in particular tidyverse, ggplot, and benchmark. Finally, we built a small Shiny App as a demonstration of how our component interacts with other R packages. We saw how the StatsR package can be used anywhere in the extensive R universe. In the process, we set up a development infrastructure that consists of an IDE (CodeBlocks) for building C++ code using the compiler required by R, and an IDE for writing Rcpp packages (RStudio), which we can use to develop and build the packages.
Lastly, we have also built Python extension modules: three to be exact. We saw the potential pitfalls of using the low-level CPython approach and then looked at using both Boost.Python and PyBind as frameworks to connect C++ to Python. We saw how both frameworks facilitate development of wrapper components. We also saw that potential performance gains (not guaranteed) were only one of a number of possible reasons for connecting C++ to Python. Bringing a new component into the Python universe to operate seamlessly alongside libraries like NumPy and Pandas is also significant.
Overall, we have looked at how to set up projects for the different language wrapper components. We have spent some time looking at the design of the wrappers: the separation of concerns into a functional layer, the part making the call, and the type conversion layer. We have looked at details of type conversions and also how they might be usefully generalized. Along the way, we touched upon a number of other software development topics: some code-related, like exception handling; others related to the development process like testing and debugging. Beyond simply building components, we have set up a tooling infrastructure that eases the (multi-language) development process.
On the other hand, in restricting ourselves to exposing the underlying functionality in a limited C++ library, there are a number of important areas we have ignored. We haven’t touched on threading and concurrency in a native C++ library and how this could be exposed to different client languages. From the perspective of the actual components, there are various areas that we have omitted. In C#, we haven’t covered delegates; in R, we haven’t covered extending the modules; and in Python, we have barely scratched the surface of using PyBind. All these could require a book to themselves. What we have offered here are a number of starting points for future development.
At a more general level, the intention has been to extend the architectural choices available when developing software. In Chapter 2, we saw some of the limitations of housing a component directly in a Windows application (linking to the component lib or dll). We have demonstrated that a viable alternative is to develop wrapper components (assemblies, packages, and modules) that can be used in multiple contexts (Windows applications, web applications) and from different languages, C#, R, and Python. This leads to a more loosely coupled software system. The components themselves can offer quite heterogeneous services, but they interoperate because they participate in the underlying framework, whether it is .NET via C++/CLI, R via Rcpp, or Python.