{"id":30853,"date":"2022-08-15T15:00:41","date_gmt":"2022-08-15T15:00:41","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cppblog\/?p=30853"},"modified":"2022-08-17T09:19:58","modified_gmt":"2022-08-17T09:19:58","slug":"proxy-runtime-polymorphism-made-easier-than-ever","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/proxy-runtime-polymorphism-made-easier-than-ever\/","title":{"rendered":"proxy: Runtime Polymorphism Made Easier Than Ever"},"content":{"rendered":"

proxy<\/code> is an open-source, cross-platform, single-header C++ library, making runtime polymorphism easier to implement and faster, empowered by our breakthrough innovation of Object-oriented Programming (OOP) theory in recent years. Consider three questions:<\/p>\n

    \n
  1. Do you want to facilitate architecture design and matainance by writing non-intrusive polymorphic code in C++ as easily as in Rust or Golang?<\/li>\n
  2. Do you want to facilitate lifetime management of polymorphic objects as easily as in languages with runtime Garbage Collection (GC, like Java or C#), without<\/em> compromising performance?<\/li>\n
  3. Have you tried other polymorphic programming libraries in C++ but found them deficient?<\/li>\n<\/ol>\n

    If so, this library is for you. You can find the implementation at our GitHub repo<\/a>, integrate with your project using vcpkg<\/a> (search for proxy<\/code>), or learn more about the theory and technical specifications from P0957<\/a>.<\/p>\n

    Overview<\/h2>\n

    In C++ today, there are certain architecture and performance limitations in existing mechanisms of polymorphism, specifically, virtual functions (based on inheritance) and various polymorphic wrappers (with value semantics) in the standard. As a result, proxy<\/code> can largely replace the existing “virtual mechanism” to implement your vision in runtime polymorphism, while having no intrusion on existing code, with even better performance.<\/p>\n

    All the facilities of the library are defined in namespace pro<\/code>. The 3 major class templates are dispatch<\/code>, facade<\/code> and proxy<\/code>. Here is a demo showing how to use this library to implement runtime polymorphism in a different way from the traditional inheritance-based approach:<\/p>\n

    \/\/ Abstraction\r\nstruct Draw : pro::dispatch<void(std::ostream&)> {\r\n  template <class T>\r\n  void operator()(const T& self, std::ostream& out) { self.Draw(out); }\r\n};\r\nstruct Area : pro::dispatch<double()> {\r\n  template <class T>\r\n  double operator()(const T& self) { return self.Area(); }\r\n};\r\nstruct DrawableFacade : pro::facade<Draw, Area> {};\r\n\r\n\/\/ Implementation (No base class)\r\nclass Rectangle {\r\n public:\r\n  void Draw(std::ostream& out) const\r\n      { out << \"{Rectangle: width = \" << width_ << \", height = \" << height_ << \"}\"; }\r\n  void SetWidth(double width) { width_ = width; }\r\n  void SetHeight(double height) { height_ = height; }\r\n  double Area() const { return width_ * height_; }\r\n\r\n private:\r\n  double width_;\r\n  double height_;\r\n};\r\n\r\n\/\/ Client - Consumer\r\nstd::string PrintDrawableToString(pro::proxy<DrawableFacade> p) {\r\n  std::stringstream result;\r\n  result << \"shape = \";\r\n  p.invoke<Draw>(result);  \/\/ Polymorphic call\r\n  result << \", area = \" << p.invoke<Area>();  \/\/ Polymorphic call\r\n  return std::move(result).str();\r\n}\r\n\r\n\/\/ Client - Producer\r\npro::proxy<DrawableFacade> CreateRectangleAsDrawable(int width, int height) {\r\n  Rectangle rect;\r\n  rect.SetWidth(width);\r\n  rect.SetHeight(height);\r\n  return pro::make_proxy<DrawableFacade>(rect);  \/\/ No heap allocation is expected\r\n}<\/code><\/pre>\n
    Configure your project<\/h2>\n
    To get started, set the language level of your compiler to at least C++20 and get the header file (proxy.h<\/a>). You can also install the library via vcpkg<\/a>, which is a C++ library management software invented by Microsoft, by searching for “proxy”.<\/p>\n
    To integrate with CMake, 3 steps are required:<\/p>\n
      \n
    1. Set up the vcpkg manifest by adding “proxy” as a dependency in your vcpkg.json<\/code> file:\n
      {\r\n\"name\": \"<project_name>\",\r\n\"version\": \"0.1.0\",\r\n\"dependencies\": [\r\n{\r\n  \"name\": \"proxy\"\r\n}\r\n]\r\n}<\/code><\/pre>\n<\/li>\n
    2. Use find_package<\/code> and target_link_libraries<\/code> commands to reference to the library proxy<\/code> in your CMakeLists.txt<\/code> file:\n
      find_package(proxy CONFIG REQUIRED)\r\ntarget_link_libraries(<target_name> PRIVATE msft_proxy)<\/code><\/pre>\n<\/li>\n
    3. Run CMake with vcpkg toolchain file:\n
      cmake <source_dir> -B <build_dir> -DCMAKE_TOOLCHAIN_FILE=<vcpkg_dir>\/scripts\/buildsystems\/vcpkg.cmake<\/code><\/pre>\n<\/li>\n<\/ol>\n
      What makes the “proxy” so charming<\/h2>\n
      As a polymorphic programming library, proxy<\/code> has various highlights, including:<\/p>\n
        \n
      1. being non-intrusive<\/em><\/li>\n
      2. allowing lifetime management per object<\/em>, complementary with smart pointers<\/li>\n
      3. high-quality code generation<\/li>\n
      4. supporting flexible composition of abstractions<\/li>\n
      5. optimized syntax for Customization Point Objects (CPO) and modules<\/li>\n
      6. supporting general-purpose static reflection<\/li>\n
      7. supporting expert performance tuning<\/li>\n
      8. high-quality diagnostics.<\/li>\n<\/ol>\n
        In this section, we will briefly introduce each of the highlights listed above with concrete examples.<\/p>\n
        Highlight 1: Being non-intrusive<\/h3>\n
        Designing polymorphic types with inheritance usually requires careful architecting. If the design is not thought through enough early on, the components may become overly complex as more and more functionality is added, or extensibility may be insufficient if polymorphic types are coupled too closely. On the other hand, some libraries (including the standard library) may not have proper polymorphic semantics even if they, by definition, satisfy same specific constraints. In such scenarios, users have no alternative but to design and maintain extra middleware themselves to add polymorphism support to existing implementations.<\/p>\n
        For example, some programming languages provide base types for containers, which makes it easy for library authors to design APIs without binding to a specific data structure at runtime. However, this is not feasible in C++ because most of the standard containers are not required to have a common base type. I do not think this is a design defect of C++, on the contrary, I think it is reasonable not to overdesign for runtime abstraction before knowing the concrete requirements both for the simplicity of the semantics and for runtime performance. With proxy<\/code>, because it is non-intrusive, if we want to abstract a mapping data structure from indices to strings for localization, we may define the following facade:<\/p>\n
        struct at : pro::dispatch<std::string(int)> {\r\n  template <class T>\r\n  auto operator()(T& self, int key) { return self.at(key); }\r\n};\r\nstruct ResourceDictionaryFacade : pro::facade<at> {};<\/code><\/pre>\n
        It could proxy any potential mapping data structure, including but not limited to std::map<int, std::string><\/code>, std::unordered_map<int, std::string><\/code>, std::vector<std::string><\/code>, etc.<\/p>\n
        \/\/ Library\r\nvoid DoSomethingWithResourceDictionary(pro::proxy<ResourceDictionaryFacade> p) {\r\n  try {\r\n    std::cout << p.invoke(1) << std::endl;\r\n  } catch (const std::out_of_range& e) {\r\n    std::cout << \"No such element: \" << e.what() << std::endl;\r\n  }\r\n}\r\n\r\n\/\/ Client\r\nstd::map<int, std::string> var1{{1, \"Hello\"}};\r\nstd::vector<std::string> var2{\"I\", \"love\", \"Proxy\", \"!\"};\r\nDoSomethingWithResourceDictionary(&var1);  \/\/ Prints \"Hello\"\r\nDoSomethingWithResourceDictionary(&var2);  \/\/ Prints \"love\"\r\nDoSomethingWithResourceDictionary(std::make_shared<std::unordered_map<int, std::string>>());  \/\/ Prints \"No such element: {implementation-defined error message}\"<\/code><\/pre>\n
        Overall, inheritance-based polymorphism has certain limitations in usability. As Sean Parent commented on NDC 2017<\/a>: The requirements of a polymorphic type, by definition, comes from its use, and there are no polymorphic types, only polymorphic use of similar types. Inheritance is the base class of evil<\/em>.<\/p>\n
        Highlight 2: Evolutionary lifetime management<\/h3>\n
        It is such a pain to manage lifetime of objects in large systems written in C++. Because C++ does not have built-in GC support due to performance considerations, users need to beware of lifetime management of every single object. Although we have smart pointers since C++11 (i.e., std::unique_ptr<\/code> and std::shared_ptr<\/code>), and various 3rd-party fancy pointers like boost::interprocess::offset_ptr<\/code>, they are not always sufficient for polymorphic use with inheritance. By using the proxy<\/code> complementary with smart pointers, clients could care less about lifetime management as if there is runtime GC, but without compromising performance.<\/p>\n
        Before using any polymorphic object, the first step is always to create it. In other programming languages like Java or C#, we can new<\/code> an object at any time and runtime GC will take care of lifetime management when it becomes unreachable, at the cost of performance. But how should we implement it in C++? Consider the drawable<\/code> example in the “Overview” section: given there are 3 drawable<\/code> types in a system: Rectangle<\/code>, Circle<\/code>, and Point<\/code>. Specifically,<\/p>\n