Skip to content

ydk cpp bindings

Jump to bottom
Abhi Keshav edited this page May 31, 2016 · 1 revision 
#include "ydk/entity.h"
#include "ydk/types.h"

namespace ydk {
namespace bgp {

class Bgp : public Entity {
    public:
        Bgp();

    class Global : public Entity {
        public:
            Global();

        class Config : public Entity {
            public:
                Config();

            public:
                int as_;
                std::string router_id;

        };

        class State {
            public:
                State();

            public:
                int as_;
                std::string router_id;
                int total_paths;
                int total_prefixes;

        };
. . .
}
}

Draft proposal

Below is a draft proposal containing ideas on how to model the YDK C++ bindings corresponding to the input Yang. All of the below is subject to change based on our continuing discussion.

Name

YDK-CPlusPlus/ydk-cplusplus or YDK-Cpp/ydk-cpp. Any other ideas ?

Modules

  • Each Yang module corresponds to a C++ header and has its own C++ namespace
  • Yang Sub-modules consumed by parent modules (similar to YDK-Py approach)

List and container

  • Lists and containers are modeled as classes (similar to YDK-Py)
  • Parent container of a list contains a C++ list of the list class objects (similar to YList in YDK-Py)

Groupings

  • One idea is to model groupings as C++ macros and use them as macro invocations wherever needed

Leaf and leaf-list

  • Leaf is modeled as a member variable of the classes
  • Leaf-list is modeled as a C++ list

Data-types

  • Defining data-types is crucial in C++ since it is statically typed
  • Each basic Yang type needs a corresponding type in YDK-CPlusPlus
    • integer --> int8, int16, int32, uint32 etc
    • string --> std::string
    • boolean --> bool
    • enumeration --> enum class
    • bits --> enum class
    • binary --> C++ array like uint8[SIZE]
    • leafref --> type of the leaf being referred to
    • identityref --> instance of the identity class. Identities modeled as C++ classes (similar to YDK-Py)
    • empty --> bool
    • union --> C++ union
    • instance-identifier --> ??

Nested vs non-nested classes

  • Nested C++ classes
    • Pros:
      • naming of the classes becomes easy and will be consistent with the naming in YDK-Py. To declare a nested class in an app would look something like: auto obj = Bgp::Global::AfiSafi::ApplyPolicy::Config{};
      • because it is important to maintain consistency, it appears better to go with nested classes
    • Cons:
      • cannot be forward declared
      • to use them in a header, need to include the header in which the class is declared - reduces speed and performance
  • Non-nested classes
    • Pros:
      • classes can be forward declared
      • the C++ bindings become easier to read
    • Cons:
      • naming becomes an issue. We would need to concatenate the names of all the parents of the class. So, we will have classes with names like: BgpGlobalAfiSafiApplyPolicyConfig and BgpGlobalAfiSafiApplyPolicyState

Memory ownership

  • App will own the memory of the entities it creates

Git repo

Clone this wiki locally