Cleaner way to handle double pointer in C++ BST?












7












$begingroup$


I have an implementation for my first binary search tree in C++. I was wondering if there was some cleaner way to avoid using the double pointer in the way I have my code setup? Such as on one line I have:



(*node)->left = insert(&((*node)->left),value);


Which seems a bit "messy", but it almost seems necessary for the way I have implemented the BST. Maybe I am possibly missing a way I can change the syntax slightly to achieve the same result? I understand that I can have a double pointer as a parameter for my functions, but I have been told that it is not the standard in C++. I have my code posted below, along with how I am testing it.I am trying to prepare for technical interviews so any feedback is welcome.



#include<stdio.h> 
#include<stdlib.h>
#include<iostream>
struct Node
{
int data;
Node *left, *right;
};

// A utility function to create a new BST node
Node* newNode(int data)
{
Node *temp = new Node();
temp->data = data;
temp->left = NULL;
temp->right = NULL;
return temp;
}

// A utility function to do inorder traversal of BST
void inorder(Node **root)
{
if (*root != NULL)
{
inorder(&((*root)->left));
printf("%d n", (*root)->data);
inorder(&((*root)->right));
}
}

/* A utility function to insert a new node with given key in BST */
Node* insert(Node** node, int value)
{
if(*node==NULL){
return newNode(value);
}
if((*node)->data > value){
(*node)->left = insert(&((*node)->left),value);
}
else if((*node)->data < value){
(*node)->right = insert(&((*node)->right),value);
}
return *node;
}

// Driver Program to test above functions
int main()
{
/* Let us create following BST
50
/
30 70
/ /
20 40 60 80 */
Node *root = NULL;
root = insert(&root, 50);
insert(&root, 30);
insert(&root, 20);
insert(&root, 40);
insert(&root, 70);
insert(&root, 60);
insert(&root, 80);

// print inoder traversal of the BST
inorder(&root);

return 0;
}


EDIT:
By changing " ** " in the parameters of the function to "*&" was able to make code much easier to read, with the same functionality.



#include<stdio.h> 
#include<stdlib.h>
#include<iostream>
struct Node
{
int data;
Node *left, *right;
};

// A utility function to create a new BST node
Node* newNode(int data)
{
Node *temp = new Node();
temp->data = data;
temp->left = NULL;
temp->right = NULL;
return temp;
}

// A utility function to do inorder traversal of BST
void inorder(Node *&root)
{
if (root != NULL)
{
inorder(((root)->left));
printf("%d n", (root)->data);
inorder(((root)->right));
}
}

/* A utility function to insert a new node with given key in BST */
Node* insert(Node*& node, int value)
{
if(node==NULL){
return newNode(value);
}
if((node)->data > value){
node->left = insert(((node)->left),value);
}
else if((node)->data < value){
(node)->right = insert(((node)->right),value);
}
return node;
}

// Driver Program to test above functions
int main()
{
/* following BST
50
/
30 70
/ /
20 40 60 80 */
Node *root = NULL;
root = insert(root, 50);
insert(root, 30);
insert(root, 20);
insert(root, 40);
insert(root, 70);
insert(root, 60);
insert(root, 80);

// print inoder traversal of the BST
inorder(root);

return 0;
}









share|improve this question











$endgroup$

















    7












    $begingroup$


    I have an implementation for my first binary search tree in C++. I was wondering if there was some cleaner way to avoid using the double pointer in the way I have my code setup? Such as on one line I have:



    (*node)->left = insert(&((*node)->left),value);


    Which seems a bit "messy", but it almost seems necessary for the way I have implemented the BST. Maybe I am possibly missing a way I can change the syntax slightly to achieve the same result? I understand that I can have a double pointer as a parameter for my functions, but I have been told that it is not the standard in C++. I have my code posted below, along with how I am testing it.I am trying to prepare for technical interviews so any feedback is welcome.



    #include<stdio.h> 
    #include<stdlib.h>
    #include<iostream>
    struct Node
    {
    int data;
    Node *left, *right;
    };

    // A utility function to create a new BST node
    Node* newNode(int data)
    {
    Node *temp = new Node();
    temp->data = data;
    temp->left = NULL;
    temp->right = NULL;
    return temp;
    }

    // A utility function to do inorder traversal of BST
    void inorder(Node **root)
    {
    if (*root != NULL)
    {
    inorder(&((*root)->left));
    printf("%d n", (*root)->data);
    inorder(&((*root)->right));
    }
    }

    /* A utility function to insert a new node with given key in BST */
    Node* insert(Node** node, int value)
    {
    if(*node==NULL){
    return newNode(value);
    }
    if((*node)->data > value){
    (*node)->left = insert(&((*node)->left),value);
    }
    else if((*node)->data < value){
    (*node)->right = insert(&((*node)->right),value);
    }
    return *node;
    }

    // Driver Program to test above functions
    int main()
    {
    /* Let us create following BST
    50
    /
    30 70
    / /
    20 40 60 80 */
    Node *root = NULL;
    root = insert(&root, 50);
    insert(&root, 30);
    insert(&root, 20);
    insert(&root, 40);
    insert(&root, 70);
    insert(&root, 60);
    insert(&root, 80);

    // print inoder traversal of the BST
    inorder(&root);

    return 0;
    }


    EDIT:
    By changing " ** " in the parameters of the function to "*&" was able to make code much easier to read, with the same functionality.



    #include<stdio.h> 
    #include<stdlib.h>
    #include<iostream>
    struct Node
    {
    int data;
    Node *left, *right;
    };

    // A utility function to create a new BST node
    Node* newNode(int data)
    {
    Node *temp = new Node();
    temp->data = data;
    temp->left = NULL;
    temp->right = NULL;
    return temp;
    }

    // A utility function to do inorder traversal of BST
    void inorder(Node *&root)
    {
    if (root != NULL)
    {
    inorder(((root)->left));
    printf("%d n", (root)->data);
    inorder(((root)->right));
    }
    }

    /* A utility function to insert a new node with given key in BST */
    Node* insert(Node*& node, int value)
    {
    if(node==NULL){
    return newNode(value);
    }
    if((node)->data > value){
    node->left = insert(((node)->left),value);
    }
    else if((node)->data < value){
    (node)->right = insert(((node)->right),value);
    }
    return node;
    }

    // Driver Program to test above functions
    int main()
    {
    /* following BST
    50
    /
    30 70
    / /
    20 40 60 80 */
    Node *root = NULL;
    root = insert(root, 50);
    insert(root, 30);
    insert(root, 20);
    insert(root, 40);
    insert(root, 70);
    insert(root, 60);
    insert(root, 80);

    // print inoder traversal of the BST
    inorder(root);

    return 0;
    }









    share|improve this question











    $endgroup$















      7












      7








      7


      1



      $begingroup$


      I have an implementation for my first binary search tree in C++. I was wondering if there was some cleaner way to avoid using the double pointer in the way I have my code setup? Such as on one line I have:



      (*node)->left = insert(&((*node)->left),value);


      Which seems a bit "messy", but it almost seems necessary for the way I have implemented the BST. Maybe I am possibly missing a way I can change the syntax slightly to achieve the same result? I understand that I can have a double pointer as a parameter for my functions, but I have been told that it is not the standard in C++. I have my code posted below, along with how I am testing it.I am trying to prepare for technical interviews so any feedback is welcome.



      #include<stdio.h> 
      #include<stdlib.h>
      #include<iostream>
      struct Node
      {
      int data;
      Node *left, *right;
      };

      // A utility function to create a new BST node
      Node* newNode(int data)
      {
      Node *temp = new Node();
      temp->data = data;
      temp->left = NULL;
      temp->right = NULL;
      return temp;
      }

      // A utility function to do inorder traversal of BST
      void inorder(Node **root)
      {
      if (*root != NULL)
      {
      inorder(&((*root)->left));
      printf("%d n", (*root)->data);
      inorder(&((*root)->right));
      }
      }

      /* A utility function to insert a new node with given key in BST */
      Node* insert(Node** node, int value)
      {
      if(*node==NULL){
      return newNode(value);
      }
      if((*node)->data > value){
      (*node)->left = insert(&((*node)->left),value);
      }
      else if((*node)->data < value){
      (*node)->right = insert(&((*node)->right),value);
      }
      return *node;
      }

      // Driver Program to test above functions
      int main()
      {
      /* Let us create following BST
      50
      /
      30 70
      / /
      20 40 60 80 */
      Node *root = NULL;
      root = insert(&root, 50);
      insert(&root, 30);
      insert(&root, 20);
      insert(&root, 40);
      insert(&root, 70);
      insert(&root, 60);
      insert(&root, 80);

      // print inoder traversal of the BST
      inorder(&root);

      return 0;
      }


      EDIT:
      By changing " ** " in the parameters of the function to "*&" was able to make code much easier to read, with the same functionality.



      #include<stdio.h> 
      #include<stdlib.h>
      #include<iostream>
      struct Node
      {
      int data;
      Node *left, *right;
      };

      // A utility function to create a new BST node
      Node* newNode(int data)
      {
      Node *temp = new Node();
      temp->data = data;
      temp->left = NULL;
      temp->right = NULL;
      return temp;
      }

      // A utility function to do inorder traversal of BST
      void inorder(Node *&root)
      {
      if (root != NULL)
      {
      inorder(((root)->left));
      printf("%d n", (root)->data);
      inorder(((root)->right));
      }
      }

      /* A utility function to insert a new node with given key in BST */
      Node* insert(Node*& node, int value)
      {
      if(node==NULL){
      return newNode(value);
      }
      if((node)->data > value){
      node->left = insert(((node)->left),value);
      }
      else if((node)->data < value){
      (node)->right = insert(((node)->right),value);
      }
      return node;
      }

      // Driver Program to test above functions
      int main()
      {
      /* following BST
      50
      /
      30 70
      / /
      20 40 60 80 */
      Node *root = NULL;
      root = insert(root, 50);
      insert(root, 30);
      insert(root, 20);
      insert(root, 40);
      insert(root, 70);
      insert(root, 60);
      insert(root, 80);

      // print inoder traversal of the BST
      inorder(root);

      return 0;
      }









      share|improve this question











      $endgroup$




      I have an implementation for my first binary search tree in C++. I was wondering if there was some cleaner way to avoid using the double pointer in the way I have my code setup? Such as on one line I have:



      (*node)->left = insert(&((*node)->left),value);


      Which seems a bit "messy", but it almost seems necessary for the way I have implemented the BST. Maybe I am possibly missing a way I can change the syntax slightly to achieve the same result? I understand that I can have a double pointer as a parameter for my functions, but I have been told that it is not the standard in C++. I have my code posted below, along with how I am testing it.I am trying to prepare for technical interviews so any feedback is welcome.



      #include<stdio.h> 
      #include<stdlib.h>
      #include<iostream>
      struct Node
      {
      int data;
      Node *left, *right;
      };

      // A utility function to create a new BST node
      Node* newNode(int data)
      {
      Node *temp = new Node();
      temp->data = data;
      temp->left = NULL;
      temp->right = NULL;
      return temp;
      }

      // A utility function to do inorder traversal of BST
      void inorder(Node **root)
      {
      if (*root != NULL)
      {
      inorder(&((*root)->left));
      printf("%d n", (*root)->data);
      inorder(&((*root)->right));
      }
      }

      /* A utility function to insert a new node with given key in BST */
      Node* insert(Node** node, int value)
      {
      if(*node==NULL){
      return newNode(value);
      }
      if((*node)->data > value){
      (*node)->left = insert(&((*node)->left),value);
      }
      else if((*node)->data < value){
      (*node)->right = insert(&((*node)->right),value);
      }
      return *node;
      }

      // Driver Program to test above functions
      int main()
      {
      /* Let us create following BST
      50
      /
      30 70
      / /
      20 40 60 80 */
      Node *root = NULL;
      root = insert(&root, 50);
      insert(&root, 30);
      insert(&root, 20);
      insert(&root, 40);
      insert(&root, 70);
      insert(&root, 60);
      insert(&root, 80);

      // print inoder traversal of the BST
      inorder(&root);

      return 0;
      }


      EDIT:
      By changing " ** " in the parameters of the function to "*&" was able to make code much easier to read, with the same functionality.



      #include<stdio.h> 
      #include<stdlib.h>
      #include<iostream>
      struct Node
      {
      int data;
      Node *left, *right;
      };

      // A utility function to create a new BST node
      Node* newNode(int data)
      {
      Node *temp = new Node();
      temp->data = data;
      temp->left = NULL;
      temp->right = NULL;
      return temp;
      }

      // A utility function to do inorder traversal of BST
      void inorder(Node *&root)
      {
      if (root != NULL)
      {
      inorder(((root)->left));
      printf("%d n", (root)->data);
      inorder(((root)->right));
      }
      }

      /* A utility function to insert a new node with given key in BST */
      Node* insert(Node*& node, int value)
      {
      if(node==NULL){
      return newNode(value);
      }
      if((node)->data > value){
      node->left = insert(((node)->left),value);
      }
      else if((node)->data < value){
      (node)->right = insert(((node)->right),value);
      }
      return node;
      }

      // Driver Program to test above functions
      int main()
      {
      /* following BST
      50
      /
      30 70
      / /
      20 40 60 80 */
      Node *root = NULL;
      root = insert(root, 50);
      insert(root, 30);
      insert(root, 20);
      insert(root, 40);
      insert(root, 70);
      insert(root, 60);
      insert(root, 80);

      // print inoder traversal of the BST
      inorder(root);

      return 0;
      }






      c++ algorithm binary-search






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 8 at 3:05







      Pulse

















      asked Jan 8 at 2:44









      PulsePulse

      1384




      1384






















          2 Answers
          2






          active

          oldest

          votes


















          8












          $begingroup$

          If you're trying to learn C++, you should get comfortable with constructors and destructors — they're what C++ is all about!



          struct Node 
          {
          int data;
          Node *left, *right;
          };

          // A utility function to create a new BST node
          Node* newNode(int data)
          {
          Node *temp = new Node();
          temp->data = data;
          temp->left = NULL;
          temp->right = NULL;
          return temp;
          }


          That's C style. C++ style would be:



          struct Node { 
          int data_;
          Node *left_ = nullptr;
          Node *right_ = nullptr;

          explicit Node(int data) : data_(data) {}
          };


          Then when you want a new heap-allocated node, you don't call newNode(42) — you call new Node(42)! Or, a good habit you should get into: call std::make_unique<Node>(42) to get back a smart pointer.



          Notice that I added sigils to your data members (data_ etc) to distinguish them from non-member variables; and I declared no more than one variable per line to reduce reader confusion.





          void inorder(Node *&root) 
          {
          if (root != NULL)
          {
          inorder(((root)->left));
          printf("%d n", (root)->data);
          inorder(((root)->right));
          }
          }


          Several things weird here. First, you have a bunch of unnecessary parentheses. (root) is the same thing as root. Second, you're passing root by non-const reference, even though you don't intend to modify it. Third, very minor nit, you're using C-style NULL instead of nullptr. Fourth, why do you print a space before the newline? Fixed up:



          void inorder(const Node *root)
          {
          if (root != nullptr) {
          inorder(root->left);
          printf("%dn", root->data);
          inorder(root->right);
          }
          }


          Remember to remove the redundant parentheses in places like insert(((node)->right),value). It's much easier to read as insert(node->right, value).






          share|improve this answer









          $endgroup$













          • $begingroup$
            Yeah the unnecessary parentheses came from when I was editing from the previous solution. Also, surprisingly was not aware of putting a constructor / destructor into the struct, thanks for pointing that out to me. Much needed feedback.
            $endgroup$
            – Pulse
            Jan 8 at 5:40






          • 1




            $begingroup$
            Actually, leaving Node without any user-declared ctors and functions is much better: It doesn't have any invariants, as much as anyone might pretend, and they only get in the way of implementing the list efficiently and correctly, which does.
            $endgroup$
            – Deduplicator
            Jan 8 at 12:50






          • 1




            $begingroup$
            @Deduplicator "A node always has the data set" is quite obviously a (very simple) invariant which the constructor nicely enforces. And in what way does it make the implementation harder?
            $endgroup$
            – Voo
            Jan 8 at 12:53










          • $begingroup$
            @Voo Well, first I would always put the links first. Then, a new Node is created with new Node{nullptr, nullptr, {args...}}, irrespective what {args...} is, even a function-call, and whether the data-type can be copied, moved, or only in-place-constructed.
            $endgroup$
            – Deduplicator
            Jan 8 at 12:56








          • 1




            $begingroup$
            @Deduplicator Wouldn't that work just as well with a constructor if you use the right signature?
            $endgroup$
            – Voo
            Jan 8 at 13:26



















          4












          $begingroup$


          1. I would have expected an empty line between your includes and the declaration of Node.


          2. You seem inordinately fond of having extra-whitespace at the end of lines. Loose it, both in the code and in the output, as it at best irritates co-workers and diff.


          3. Consider using smartpointers, specifically std::unique_ptr for the link- and root-pointer. That way, you won't leak your tree. Admittedly, not freeing might be an intentional optimisation for faster shutdown, but that seems unlikely.
            Yes, you have as much recursion as in inorder(), using an explicit stack could avoid that. Or much more iteration. Or having back-pointers. Or a custom area-allocator.


          4. As a matter of course, I would always put the links first in any kind of node-class.



          5. newNode is very expansively written, and if the value_type isn't trivially constructible, might not be optimisable by the compiler from initialisation+assignment for all members to just initialisation. Why ask it to?



            Node* newNode(int value) {
            return new Node{value};
            // Or if you move the links: `new Node{nullptr, nullptr, value}`
            // With C++20: `new Node{.data = value}`
            }


            That can easily be used for non-copyable, non-movable, and even only in-place-constructible types.



          6. Prefer nullptr for nullpointer-constants, if you actually need one. That is more type-safe, and sometimes enables additional optimisations.


          7. Try to take advantage of references to simplify calling your functions.


          8. insert() drops any duplicate values. Is that intentional? If so, that needs to be called out in a comment, or made more obvious from the code-structure!



          9. insert() has no need to recurse:



            void insert(Node* &root, int value) {
            auto p = &root;
            while (*p && p[0]->data != value)
            p = p[0]->data > value ? &p[0]->left : &p[0]->right;
            if (!*p)
            *p = newNode(value);
            }


          10. inorder() only needs to know the root-node, not where the pointer to it is saved. Also, it never modifies anything. Thus, it should accept Node const* or Node const&.


          11. inorder() cannot throw by design, so mark it noexcept.


          12. Try to minimize the level of indentation. Guards at the start of a function are quite idiomatic.



          13. What does inorder() do in order? Ah, printing. So, why not call it print_inorder()?



            void print_inorder(const Node *root) noexcept {
            if (!root)
            return;
            print_inorder(root->left);
            printf("%dn", root->data);
            print_inorder(root->right);
            }


          14. Some would suggest favoring iostreams over stdio for added type-safety, but there are downsides for that too.


          15. return 0; is implicit for main().


          16. Naturally, for any further use you would want to wrap your data-structure in its own class-template with members for observing, modifying, iterating, and ctors / dtor for enforcing the invariants and manage the resources. But ensuring full re-usability is probably far out-of-scope at the moment.







          share|improve this answer











          $endgroup$









          • 1




            $begingroup$
            On #3, I think it's worth mentioning that if you use unique_ptr for the links, then the destructor of Node becomes recursive, which means it's probably not a good idea for real code (but is still a good suggestion for OP to think about and understand how it'd work).
            $endgroup$
            – Quuxplusone
            Jan 8 at 15:20






          • 2




            $begingroup$
            The ` extra-whitespace at the end of lines` This is more important than it looks (it feels trivial but I agree with deduplicator that it is important). People specifically set their editors to show extra white space at then end of lines.
            $endgroup$
            – Martin York
            Jan 8 at 19:14










          • $begingroup$
            Relying on the order of members in such an implicit and hidden way for #3 strikes me as an awful, awful maintenance burden for very little benefit. Using the c++20 syntax is fine though (that one's really only in c++20? I guess before it was just a really popular extension?)
            $endgroup$
            – Voo
            Jan 8 at 19:27










          • $begingroup$
            @Voo Yes, it's a popular extension and C got it earlier with C99.
            $endgroup$
            – Deduplicator
            Jan 8 at 20:27










          • $begingroup$
            @Deduplicator Yeah I know that C had it for years, I just assumed C++ would've gotten it around c++11 or possibly 14 as well. Well, better late than never.
            $endgroup$
            – Voo
            Jan 8 at 22:13













          Your Answer





          StackExchange.ifUsing("editor", function () {
          return StackExchange.using("mathjaxEditing", function () {
          StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
          StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
          });
          });
          }, "mathjax-editing");

          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "196"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f211072%2fcleaner-way-to-handle-double-pointer-in-c-bst%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          2 Answers
          2






          active

          oldest

          votes








          2 Answers
          2






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          8












          $begingroup$

          If you're trying to learn C++, you should get comfortable with constructors and destructors — they're what C++ is all about!



          struct Node 
          {
          int data;
          Node *left, *right;
          };

          // A utility function to create a new BST node
          Node* newNode(int data)
          {
          Node *temp = new Node();
          temp->data = data;
          temp->left = NULL;
          temp->right = NULL;
          return temp;
          }


          That's C style. C++ style would be:



          struct Node { 
          int data_;
          Node *left_ = nullptr;
          Node *right_ = nullptr;

          explicit Node(int data) : data_(data) {}
          };


          Then when you want a new heap-allocated node, you don't call newNode(42) — you call new Node(42)! Or, a good habit you should get into: call std::make_unique<Node>(42) to get back a smart pointer.



          Notice that I added sigils to your data members (data_ etc) to distinguish them from non-member variables; and I declared no more than one variable per line to reduce reader confusion.





          void inorder(Node *&root) 
          {
          if (root != NULL)
          {
          inorder(((root)->left));
          printf("%d n", (root)->data);
          inorder(((root)->right));
          }
          }


          Several things weird here. First, you have a bunch of unnecessary parentheses. (root) is the same thing as root. Second, you're passing root by non-const reference, even though you don't intend to modify it. Third, very minor nit, you're using C-style NULL instead of nullptr. Fourth, why do you print a space before the newline? Fixed up:



          void inorder(const Node *root)
          {
          if (root != nullptr) {
          inorder(root->left);
          printf("%dn", root->data);
          inorder(root->right);
          }
          }


          Remember to remove the redundant parentheses in places like insert(((node)->right),value). It's much easier to read as insert(node->right, value).






          share|improve this answer









          $endgroup$













          • $begingroup$
            Yeah the unnecessary parentheses came from when I was editing from the previous solution. Also, surprisingly was not aware of putting a constructor / destructor into the struct, thanks for pointing that out to me. Much needed feedback.
            $endgroup$
            – Pulse
            Jan 8 at 5:40






          • 1




            $begingroup$
            Actually, leaving Node without any user-declared ctors and functions is much better: It doesn't have any invariants, as much as anyone might pretend, and they only get in the way of implementing the list efficiently and correctly, which does.
            $endgroup$
            – Deduplicator
            Jan 8 at 12:50






          • 1




            $begingroup$
            @Deduplicator "A node always has the data set" is quite obviously a (very simple) invariant which the constructor nicely enforces. And in what way does it make the implementation harder?
            $endgroup$
            – Voo
            Jan 8 at 12:53










          • $begingroup$
            @Voo Well, first I would always put the links first. Then, a new Node is created with new Node{nullptr, nullptr, {args...}}, irrespective what {args...} is, even a function-call, and whether the data-type can be copied, moved, or only in-place-constructed.
            $endgroup$
            – Deduplicator
            Jan 8 at 12:56








          • 1




            $begingroup$
            @Deduplicator Wouldn't that work just as well with a constructor if you use the right signature?
            $endgroup$
            – Voo
            Jan 8 at 13:26
















          8












          $begingroup$

          If you're trying to learn C++, you should get comfortable with constructors and destructors — they're what C++ is all about!



          struct Node 
          {
          int data;
          Node *left, *right;
          };

          // A utility function to create a new BST node
          Node* newNode(int data)
          {
          Node *temp = new Node();
          temp->data = data;
          temp->left = NULL;
          temp->right = NULL;
          return temp;
          }


          That's C style. C++ style would be:



          struct Node { 
          int data_;
          Node *left_ = nullptr;
          Node *right_ = nullptr;

          explicit Node(int data) : data_(data) {}
          };


          Then when you want a new heap-allocated node, you don't call newNode(42) — you call new Node(42)! Or, a good habit you should get into: call std::make_unique<Node>(42) to get back a smart pointer.



          Notice that I added sigils to your data members (data_ etc) to distinguish them from non-member variables; and I declared no more than one variable per line to reduce reader confusion.





          void inorder(Node *&root) 
          {
          if (root != NULL)
          {
          inorder(((root)->left));
          printf("%d n", (root)->data);
          inorder(((root)->right));
          }
          }


          Several things weird here. First, you have a bunch of unnecessary parentheses. (root) is the same thing as root. Second, you're passing root by non-const reference, even though you don't intend to modify it. Third, very minor nit, you're using C-style NULL instead of nullptr. Fourth, why do you print a space before the newline? Fixed up:



          void inorder(const Node *root)
          {
          if (root != nullptr) {
          inorder(root->left);
          printf("%dn", root->data);
          inorder(root->right);
          }
          }


          Remember to remove the redundant parentheses in places like insert(((node)->right),value). It's much easier to read as insert(node->right, value).






          share|improve this answer









          $endgroup$













          • $begingroup$
            Yeah the unnecessary parentheses came from when I was editing from the previous solution. Also, surprisingly was not aware of putting a constructor / destructor into the struct, thanks for pointing that out to me. Much needed feedback.
            $endgroup$
            – Pulse
            Jan 8 at 5:40






          • 1




            $begingroup$
            Actually, leaving Node without any user-declared ctors and functions is much better: It doesn't have any invariants, as much as anyone might pretend, and they only get in the way of implementing the list efficiently and correctly, which does.
            $endgroup$
            – Deduplicator
            Jan 8 at 12:50






          • 1




            $begingroup$
            @Deduplicator "A node always has the data set" is quite obviously a (very simple) invariant which the constructor nicely enforces. And in what way does it make the implementation harder?
            $endgroup$
            – Voo
            Jan 8 at 12:53










          • $begingroup$
            @Voo Well, first I would always put the links first. Then, a new Node is created with new Node{nullptr, nullptr, {args...}}, irrespective what {args...} is, even a function-call, and whether the data-type can be copied, moved, or only in-place-constructed.
            $endgroup$
            – Deduplicator
            Jan 8 at 12:56








          • 1




            $begingroup$
            @Deduplicator Wouldn't that work just as well with a constructor if you use the right signature?
            $endgroup$
            – Voo
            Jan 8 at 13:26














          8












          8








          8





          $begingroup$

          If you're trying to learn C++, you should get comfortable with constructors and destructors — they're what C++ is all about!



          struct Node 
          {
          int data;
          Node *left, *right;
          };

          // A utility function to create a new BST node
          Node* newNode(int data)
          {
          Node *temp = new Node();
          temp->data = data;
          temp->left = NULL;
          temp->right = NULL;
          return temp;
          }


          That's C style. C++ style would be:



          struct Node { 
          int data_;
          Node *left_ = nullptr;
          Node *right_ = nullptr;

          explicit Node(int data) : data_(data) {}
          };


          Then when you want a new heap-allocated node, you don't call newNode(42) — you call new Node(42)! Or, a good habit you should get into: call std::make_unique<Node>(42) to get back a smart pointer.



          Notice that I added sigils to your data members (data_ etc) to distinguish them from non-member variables; and I declared no more than one variable per line to reduce reader confusion.





          void inorder(Node *&root) 
          {
          if (root != NULL)
          {
          inorder(((root)->left));
          printf("%d n", (root)->data);
          inorder(((root)->right));
          }
          }


          Several things weird here. First, you have a bunch of unnecessary parentheses. (root) is the same thing as root. Second, you're passing root by non-const reference, even though you don't intend to modify it. Third, very minor nit, you're using C-style NULL instead of nullptr. Fourth, why do you print a space before the newline? Fixed up:



          void inorder(const Node *root)
          {
          if (root != nullptr) {
          inorder(root->left);
          printf("%dn", root->data);
          inorder(root->right);
          }
          }


          Remember to remove the redundant parentheses in places like insert(((node)->right),value). It's much easier to read as insert(node->right, value).






          share|improve this answer









          $endgroup$



          If you're trying to learn C++, you should get comfortable with constructors and destructors — they're what C++ is all about!



          struct Node 
          {
          int data;
          Node *left, *right;
          };

          // A utility function to create a new BST node
          Node* newNode(int data)
          {
          Node *temp = new Node();
          temp->data = data;
          temp->left = NULL;
          temp->right = NULL;
          return temp;
          }


          That's C style. C++ style would be:



          struct Node { 
          int data_;
          Node *left_ = nullptr;
          Node *right_ = nullptr;

          explicit Node(int data) : data_(data) {}
          };


          Then when you want a new heap-allocated node, you don't call newNode(42) — you call new Node(42)! Or, a good habit you should get into: call std::make_unique<Node>(42) to get back a smart pointer.



          Notice that I added sigils to your data members (data_ etc) to distinguish them from non-member variables; and I declared no more than one variable per line to reduce reader confusion.





          void inorder(Node *&root) 
          {
          if (root != NULL)
          {
          inorder(((root)->left));
          printf("%d n", (root)->data);
          inorder(((root)->right));
          }
          }


          Several things weird here. First, you have a bunch of unnecessary parentheses. (root) is the same thing as root. Second, you're passing root by non-const reference, even though you don't intend to modify it. Third, very minor nit, you're using C-style NULL instead of nullptr. Fourth, why do you print a space before the newline? Fixed up:



          void inorder(const Node *root)
          {
          if (root != nullptr) {
          inorder(root->left);
          printf("%dn", root->data);
          inorder(root->right);
          }
          }


          Remember to remove the redundant parentheses in places like insert(((node)->right),value). It's much easier to read as insert(node->right, value).







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 8 at 4:39









          QuuxplusoneQuuxplusone

          12.1k12061




          12.1k12061












          • $begingroup$
            Yeah the unnecessary parentheses came from when I was editing from the previous solution. Also, surprisingly was not aware of putting a constructor / destructor into the struct, thanks for pointing that out to me. Much needed feedback.
            $endgroup$
            – Pulse
            Jan 8 at 5:40






          • 1




            $begingroup$
            Actually, leaving Node without any user-declared ctors and functions is much better: It doesn't have any invariants, as much as anyone might pretend, and they only get in the way of implementing the list efficiently and correctly, which does.
            $endgroup$
            – Deduplicator
            Jan 8 at 12:50






          • 1




            $begingroup$
            @Deduplicator "A node always has the data set" is quite obviously a (very simple) invariant which the constructor nicely enforces. And in what way does it make the implementation harder?
            $endgroup$
            – Voo
            Jan 8 at 12:53










          • $begingroup$
            @Voo Well, first I would always put the links first. Then, a new Node is created with new Node{nullptr, nullptr, {args...}}, irrespective what {args...} is, even a function-call, and whether the data-type can be copied, moved, or only in-place-constructed.
            $endgroup$
            – Deduplicator
            Jan 8 at 12:56








          • 1




            $begingroup$
            @Deduplicator Wouldn't that work just as well with a constructor if you use the right signature?
            $endgroup$
            – Voo
            Jan 8 at 13:26


















          • $begingroup$
            Yeah the unnecessary parentheses came from when I was editing from the previous solution. Also, surprisingly was not aware of putting a constructor / destructor into the struct, thanks for pointing that out to me. Much needed feedback.
            $endgroup$
            – Pulse
            Jan 8 at 5:40






          • 1




            $begingroup$
            Actually, leaving Node without any user-declared ctors and functions is much better: It doesn't have any invariants, as much as anyone might pretend, and they only get in the way of implementing the list efficiently and correctly, which does.
            $endgroup$
            – Deduplicator
            Jan 8 at 12:50






          • 1




            $begingroup$
            @Deduplicator "A node always has the data set" is quite obviously a (very simple) invariant which the constructor nicely enforces. And in what way does it make the implementation harder?
            $endgroup$
            – Voo
            Jan 8 at 12:53










          • $begingroup$
            @Voo Well, first I would always put the links first. Then, a new Node is created with new Node{nullptr, nullptr, {args...}}, irrespective what {args...} is, even a function-call, and whether the data-type can be copied, moved, or only in-place-constructed.
            $endgroup$
            – Deduplicator
            Jan 8 at 12:56








          • 1




            $begingroup$
            @Deduplicator Wouldn't that work just as well with a constructor if you use the right signature?
            $endgroup$
            – Voo
            Jan 8 at 13:26
















          $begingroup$
          Yeah the unnecessary parentheses came from when I was editing from the previous solution. Also, surprisingly was not aware of putting a constructor / destructor into the struct, thanks for pointing that out to me. Much needed feedback.
          $endgroup$
          – Pulse
          Jan 8 at 5:40




          $begingroup$
          Yeah the unnecessary parentheses came from when I was editing from the previous solution. Also, surprisingly was not aware of putting a constructor / destructor into the struct, thanks for pointing that out to me. Much needed feedback.
          $endgroup$
          – Pulse
          Jan 8 at 5:40




          1




          1




          $begingroup$
          Actually, leaving Node without any user-declared ctors and functions is much better: It doesn't have any invariants, as much as anyone might pretend, and they only get in the way of implementing the list efficiently and correctly, which does.
          $endgroup$
          – Deduplicator
          Jan 8 at 12:50




          $begingroup$
          Actually, leaving Node without any user-declared ctors and functions is much better: It doesn't have any invariants, as much as anyone might pretend, and they only get in the way of implementing the list efficiently and correctly, which does.
          $endgroup$
          – Deduplicator
          Jan 8 at 12:50




          1




          1




          $begingroup$
          @Deduplicator "A node always has the data set" is quite obviously a (very simple) invariant which the constructor nicely enforces. And in what way does it make the implementation harder?
          $endgroup$
          – Voo
          Jan 8 at 12:53




          $begingroup$
          @Deduplicator "A node always has the data set" is quite obviously a (very simple) invariant which the constructor nicely enforces. And in what way does it make the implementation harder?
          $endgroup$
          – Voo
          Jan 8 at 12:53












          $begingroup$
          @Voo Well, first I would always put the links first. Then, a new Node is created with new Node{nullptr, nullptr, {args...}}, irrespective what {args...} is, even a function-call, and whether the data-type can be copied, moved, or only in-place-constructed.
          $endgroup$
          – Deduplicator
          Jan 8 at 12:56






          $begingroup$
          @Voo Well, first I would always put the links first. Then, a new Node is created with new Node{nullptr, nullptr, {args...}}, irrespective what {args...} is, even a function-call, and whether the data-type can be copied, moved, or only in-place-constructed.
          $endgroup$
          – Deduplicator
          Jan 8 at 12:56






          1




          1




          $begingroup$
          @Deduplicator Wouldn't that work just as well with a constructor if you use the right signature?
          $endgroup$
          – Voo
          Jan 8 at 13:26




          $begingroup$
          @Deduplicator Wouldn't that work just as well with a constructor if you use the right signature?
          $endgroup$
          – Voo
          Jan 8 at 13:26













          4












          $begingroup$


          1. I would have expected an empty line between your includes and the declaration of Node.


          2. You seem inordinately fond of having extra-whitespace at the end of lines. Loose it, both in the code and in the output, as it at best irritates co-workers and diff.


          3. Consider using smartpointers, specifically std::unique_ptr for the link- and root-pointer. That way, you won't leak your tree. Admittedly, not freeing might be an intentional optimisation for faster shutdown, but that seems unlikely.
            Yes, you have as much recursion as in inorder(), using an explicit stack could avoid that. Or much more iteration. Or having back-pointers. Or a custom area-allocator.


          4. As a matter of course, I would always put the links first in any kind of node-class.



          5. newNode is very expansively written, and if the value_type isn't trivially constructible, might not be optimisable by the compiler from initialisation+assignment for all members to just initialisation. Why ask it to?



            Node* newNode(int value) {
            return new Node{value};
            // Or if you move the links: `new Node{nullptr, nullptr, value}`
            // With C++20: `new Node{.data = value}`
            }


            That can easily be used for non-copyable, non-movable, and even only in-place-constructible types.



          6. Prefer nullptr for nullpointer-constants, if you actually need one. That is more type-safe, and sometimes enables additional optimisations.


          7. Try to take advantage of references to simplify calling your functions.


          8. insert() drops any duplicate values. Is that intentional? If so, that needs to be called out in a comment, or made more obvious from the code-structure!



          9. insert() has no need to recurse:



            void insert(Node* &root, int value) {
            auto p = &root;
            while (*p && p[0]->data != value)
            p = p[0]->data > value ? &p[0]->left : &p[0]->right;
            if (!*p)
            *p = newNode(value);
            }


          10. inorder() only needs to know the root-node, not where the pointer to it is saved. Also, it never modifies anything. Thus, it should accept Node const* or Node const&.


          11. inorder() cannot throw by design, so mark it noexcept.


          12. Try to minimize the level of indentation. Guards at the start of a function are quite idiomatic.



          13. What does inorder() do in order? Ah, printing. So, why not call it print_inorder()?



            void print_inorder(const Node *root) noexcept {
            if (!root)
            return;
            print_inorder(root->left);
            printf("%dn", root->data);
            print_inorder(root->right);
            }


          14. Some would suggest favoring iostreams over stdio for added type-safety, but there are downsides for that too.


          15. return 0; is implicit for main().


          16. Naturally, for any further use you would want to wrap your data-structure in its own class-template with members for observing, modifying, iterating, and ctors / dtor for enforcing the invariants and manage the resources. But ensuring full re-usability is probably far out-of-scope at the moment.







          share|improve this answer











          $endgroup$









          • 1




            $begingroup$
            On #3, I think it's worth mentioning that if you use unique_ptr for the links, then the destructor of Node becomes recursive, which means it's probably not a good idea for real code (but is still a good suggestion for OP to think about and understand how it'd work).
            $endgroup$
            – Quuxplusone
            Jan 8 at 15:20






          • 2




            $begingroup$
            The ` extra-whitespace at the end of lines` This is more important than it looks (it feels trivial but I agree with deduplicator that it is important). People specifically set their editors to show extra white space at then end of lines.
            $endgroup$
            – Martin York
            Jan 8 at 19:14










          • $begingroup$
            Relying on the order of members in such an implicit and hidden way for #3 strikes me as an awful, awful maintenance burden for very little benefit. Using the c++20 syntax is fine though (that one's really only in c++20? I guess before it was just a really popular extension?)
            $endgroup$
            – Voo
            Jan 8 at 19:27










          • $begingroup$
            @Voo Yes, it's a popular extension and C got it earlier with C99.
            $endgroup$
            – Deduplicator
            Jan 8 at 20:27










          • $begingroup$
            @Deduplicator Yeah I know that C had it for years, I just assumed C++ would've gotten it around c++11 or possibly 14 as well. Well, better late than never.
            $endgroup$
            – Voo
            Jan 8 at 22:13


















          4












          $begingroup$


          1. I would have expected an empty line between your includes and the declaration of Node.


          2. You seem inordinately fond of having extra-whitespace at the end of lines. Loose it, both in the code and in the output, as it at best irritates co-workers and diff.


          3. Consider using smartpointers, specifically std::unique_ptr for the link- and root-pointer. That way, you won't leak your tree. Admittedly, not freeing might be an intentional optimisation for faster shutdown, but that seems unlikely.
            Yes, you have as much recursion as in inorder(), using an explicit stack could avoid that. Or much more iteration. Or having back-pointers. Or a custom area-allocator.


          4. As a matter of course, I would always put the links first in any kind of node-class.



          5. newNode is very expansively written, and if the value_type isn't trivially constructible, might not be optimisable by the compiler from initialisation+assignment for all members to just initialisation. Why ask it to?



            Node* newNode(int value) {
            return new Node{value};
            // Or if you move the links: `new Node{nullptr, nullptr, value}`
            // With C++20: `new Node{.data = value}`
            }


            That can easily be used for non-copyable, non-movable, and even only in-place-constructible types.



          6. Prefer nullptr for nullpointer-constants, if you actually need one. That is more type-safe, and sometimes enables additional optimisations.


          7. Try to take advantage of references to simplify calling your functions.


          8. insert() drops any duplicate values. Is that intentional? If so, that needs to be called out in a comment, or made more obvious from the code-structure!



          9. insert() has no need to recurse:



            void insert(Node* &root, int value) {
            auto p = &root;
            while (*p && p[0]->data != value)
            p = p[0]->data > value ? &p[0]->left : &p[0]->right;
            if (!*p)
            *p = newNode(value);
            }


          10. inorder() only needs to know the root-node, not where the pointer to it is saved. Also, it never modifies anything. Thus, it should accept Node const* or Node const&.


          11. inorder() cannot throw by design, so mark it noexcept.


          12. Try to minimize the level of indentation. Guards at the start of a function are quite idiomatic.



          13. What does inorder() do in order? Ah, printing. So, why not call it print_inorder()?



            void print_inorder(const Node *root) noexcept {
            if (!root)
            return;
            print_inorder(root->left);
            printf("%dn", root->data);
            print_inorder(root->right);
            }


          14. Some would suggest favoring iostreams over stdio for added type-safety, but there are downsides for that too.


          15. return 0; is implicit for main().


          16. Naturally, for any further use you would want to wrap your data-structure in its own class-template with members for observing, modifying, iterating, and ctors / dtor for enforcing the invariants and manage the resources. But ensuring full re-usability is probably far out-of-scope at the moment.







          share|improve this answer











          $endgroup$









          • 1




            $begingroup$
            On #3, I think it's worth mentioning that if you use unique_ptr for the links, then the destructor of Node becomes recursive, which means it's probably not a good idea for real code (but is still a good suggestion for OP to think about and understand how it'd work).
            $endgroup$
            – Quuxplusone
            Jan 8 at 15:20






          • 2




            $begingroup$
            The ` extra-whitespace at the end of lines` This is more important than it looks (it feels trivial but I agree with deduplicator that it is important). People specifically set their editors to show extra white space at then end of lines.
            $endgroup$
            – Martin York
            Jan 8 at 19:14










          • $begingroup$
            Relying on the order of members in such an implicit and hidden way for #3 strikes me as an awful, awful maintenance burden for very little benefit. Using the c++20 syntax is fine though (that one's really only in c++20? I guess before it was just a really popular extension?)
            $endgroup$
            – Voo
            Jan 8 at 19:27










          • $begingroup$
            @Voo Yes, it's a popular extension and C got it earlier with C99.
            $endgroup$
            – Deduplicator
            Jan 8 at 20:27










          • $begingroup$
            @Deduplicator Yeah I know that C had it for years, I just assumed C++ would've gotten it around c++11 or possibly 14 as well. Well, better late than never.
            $endgroup$
            – Voo
            Jan 8 at 22:13
















          4












          4








          4





          $begingroup$


          1. I would have expected an empty line between your includes and the declaration of Node.


          2. You seem inordinately fond of having extra-whitespace at the end of lines. Loose it, both in the code and in the output, as it at best irritates co-workers and diff.


          3. Consider using smartpointers, specifically std::unique_ptr for the link- and root-pointer. That way, you won't leak your tree. Admittedly, not freeing might be an intentional optimisation for faster shutdown, but that seems unlikely.
            Yes, you have as much recursion as in inorder(), using an explicit stack could avoid that. Or much more iteration. Or having back-pointers. Or a custom area-allocator.


          4. As a matter of course, I would always put the links first in any kind of node-class.



          5. newNode is very expansively written, and if the value_type isn't trivially constructible, might not be optimisable by the compiler from initialisation+assignment for all members to just initialisation. Why ask it to?



            Node* newNode(int value) {
            return new Node{value};
            // Or if you move the links: `new Node{nullptr, nullptr, value}`
            // With C++20: `new Node{.data = value}`
            }


            That can easily be used for non-copyable, non-movable, and even only in-place-constructible types.



          6. Prefer nullptr for nullpointer-constants, if you actually need one. That is more type-safe, and sometimes enables additional optimisations.


          7. Try to take advantage of references to simplify calling your functions.


          8. insert() drops any duplicate values. Is that intentional? If so, that needs to be called out in a comment, or made more obvious from the code-structure!



          9. insert() has no need to recurse:



            void insert(Node* &root, int value) {
            auto p = &root;
            while (*p && p[0]->data != value)
            p = p[0]->data > value ? &p[0]->left : &p[0]->right;
            if (!*p)
            *p = newNode(value);
            }


          10. inorder() only needs to know the root-node, not where the pointer to it is saved. Also, it never modifies anything. Thus, it should accept Node const* or Node const&.


          11. inorder() cannot throw by design, so mark it noexcept.


          12. Try to minimize the level of indentation. Guards at the start of a function are quite idiomatic.



          13. What does inorder() do in order? Ah, printing. So, why not call it print_inorder()?



            void print_inorder(const Node *root) noexcept {
            if (!root)
            return;
            print_inorder(root->left);
            printf("%dn", root->data);
            print_inorder(root->right);
            }


          14. Some would suggest favoring iostreams over stdio for added type-safety, but there are downsides for that too.


          15. return 0; is implicit for main().


          16. Naturally, for any further use you would want to wrap your data-structure in its own class-template with members for observing, modifying, iterating, and ctors / dtor for enforcing the invariants and manage the resources. But ensuring full re-usability is probably far out-of-scope at the moment.







          share|improve this answer











          $endgroup$




          1. I would have expected an empty line between your includes and the declaration of Node.


          2. You seem inordinately fond of having extra-whitespace at the end of lines. Loose it, both in the code and in the output, as it at best irritates co-workers and diff.


          3. Consider using smartpointers, specifically std::unique_ptr for the link- and root-pointer. That way, you won't leak your tree. Admittedly, not freeing might be an intentional optimisation for faster shutdown, but that seems unlikely.
            Yes, you have as much recursion as in inorder(), using an explicit stack could avoid that. Or much more iteration. Or having back-pointers. Or a custom area-allocator.


          4. As a matter of course, I would always put the links first in any kind of node-class.



          5. newNode is very expansively written, and if the value_type isn't trivially constructible, might not be optimisable by the compiler from initialisation+assignment for all members to just initialisation. Why ask it to?



            Node* newNode(int value) {
            return new Node{value};
            // Or if you move the links: `new Node{nullptr, nullptr, value}`
            // With C++20: `new Node{.data = value}`
            }


            That can easily be used for non-copyable, non-movable, and even only in-place-constructible types.



          6. Prefer nullptr for nullpointer-constants, if you actually need one. That is more type-safe, and sometimes enables additional optimisations.


          7. Try to take advantage of references to simplify calling your functions.


          8. insert() drops any duplicate values. Is that intentional? If so, that needs to be called out in a comment, or made more obvious from the code-structure!



          9. insert() has no need to recurse:



            void insert(Node* &root, int value) {
            auto p = &root;
            while (*p && p[0]->data != value)
            p = p[0]->data > value ? &p[0]->left : &p[0]->right;
            if (!*p)
            *p = newNode(value);
            }


          10. inorder() only needs to know the root-node, not where the pointer to it is saved. Also, it never modifies anything. Thus, it should accept Node const* or Node const&.


          11. inorder() cannot throw by design, so mark it noexcept.


          12. Try to minimize the level of indentation. Guards at the start of a function are quite idiomatic.



          13. What does inorder() do in order? Ah, printing. So, why not call it print_inorder()?



            void print_inorder(const Node *root) noexcept {
            if (!root)
            return;
            print_inorder(root->left);
            printf("%dn", root->data);
            print_inorder(root->right);
            }


          14. Some would suggest favoring iostreams over stdio for added type-safety, but there are downsides for that too.


          15. return 0; is implicit for main().


          16. Naturally, for any further use you would want to wrap your data-structure in its own class-template with members for observing, modifying, iterating, and ctors / dtor for enforcing the invariants and manage the resources. But ensuring full re-usability is probably far out-of-scope at the moment.








          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Jan 9 at 0:46

























          answered Jan 8 at 13:52









          DeduplicatorDeduplicator

          11.2k1850




          11.2k1850








          • 1




            $begingroup$
            On #3, I think it's worth mentioning that if you use unique_ptr for the links, then the destructor of Node becomes recursive, which means it's probably not a good idea for real code (but is still a good suggestion for OP to think about and understand how it'd work).
            $endgroup$
            – Quuxplusone
            Jan 8 at 15:20






          • 2




            $begingroup$
            The ` extra-whitespace at the end of lines` This is more important than it looks (it feels trivial but I agree with deduplicator that it is important). People specifically set their editors to show extra white space at then end of lines.
            $endgroup$
            – Martin York
            Jan 8 at 19:14










          • $begingroup$
            Relying on the order of members in such an implicit and hidden way for #3 strikes me as an awful, awful maintenance burden for very little benefit. Using the c++20 syntax is fine though (that one's really only in c++20? I guess before it was just a really popular extension?)
            $endgroup$
            – Voo
            Jan 8 at 19:27










          • $begingroup$
            @Voo Yes, it's a popular extension and C got it earlier with C99.
            $endgroup$
            – Deduplicator
            Jan 8 at 20:27










          • $begingroup$
            @Deduplicator Yeah I know that C had it for years, I just assumed C++ would've gotten it around c++11 or possibly 14 as well. Well, better late than never.
            $endgroup$
            – Voo
            Jan 8 at 22:13
















          • 1




            $begingroup$
            On #3, I think it's worth mentioning that if you use unique_ptr for the links, then the destructor of Node becomes recursive, which means it's probably not a good idea for real code (but is still a good suggestion for OP to think about and understand how it'd work).
            $endgroup$
            – Quuxplusone
            Jan 8 at 15:20






          • 2




            $begingroup$
            The ` extra-whitespace at the end of lines` This is more important than it looks (it feels trivial but I agree with deduplicator that it is important). People specifically set their editors to show extra white space at then end of lines.
            $endgroup$
            – Martin York
            Jan 8 at 19:14










          • $begingroup$
            Relying on the order of members in such an implicit and hidden way for #3 strikes me as an awful, awful maintenance burden for very little benefit. Using the c++20 syntax is fine though (that one's really only in c++20? I guess before it was just a really popular extension?)
            $endgroup$
            – Voo
            Jan 8 at 19:27










          • $begingroup$
            @Voo Yes, it's a popular extension and C got it earlier with C99.
            $endgroup$
            – Deduplicator
            Jan 8 at 20:27










          • $begingroup$
            @Deduplicator Yeah I know that C had it for years, I just assumed C++ would've gotten it around c++11 or possibly 14 as well. Well, better late than never.
            $endgroup$
            – Voo
            Jan 8 at 22:13










          1




          1




          $begingroup$
          On #3, I think it's worth mentioning that if you use unique_ptr for the links, then the destructor of Node becomes recursive, which means it's probably not a good idea for real code (but is still a good suggestion for OP to think about and understand how it'd work).
          $endgroup$
          – Quuxplusone
          Jan 8 at 15:20




          $begingroup$
          On #3, I think it's worth mentioning that if you use unique_ptr for the links, then the destructor of Node becomes recursive, which means it's probably not a good idea for real code (but is still a good suggestion for OP to think about and understand how it'd work).
          $endgroup$
          – Quuxplusone
          Jan 8 at 15:20




          2




          2




          $begingroup$
          The ` extra-whitespace at the end of lines` This is more important than it looks (it feels trivial but I agree with deduplicator that it is important). People specifically set their editors to show extra white space at then end of lines.
          $endgroup$
          – Martin York
          Jan 8 at 19:14




          $begingroup$
          The ` extra-whitespace at the end of lines` This is more important than it looks (it feels trivial but I agree with deduplicator that it is important). People specifically set their editors to show extra white space at then end of lines.
          $endgroup$
          – Martin York
          Jan 8 at 19:14












          $begingroup$
          Relying on the order of members in such an implicit and hidden way for #3 strikes me as an awful, awful maintenance burden for very little benefit. Using the c++20 syntax is fine though (that one's really only in c++20? I guess before it was just a really popular extension?)
          $endgroup$
          – Voo
          Jan 8 at 19:27




          $begingroup$
          Relying on the order of members in such an implicit and hidden way for #3 strikes me as an awful, awful maintenance burden for very little benefit. Using the c++20 syntax is fine though (that one's really only in c++20? I guess before it was just a really popular extension?)
          $endgroup$
          – Voo
          Jan 8 at 19:27












          $begingroup$
          @Voo Yes, it's a popular extension and C got it earlier with C99.
          $endgroup$
          – Deduplicator
          Jan 8 at 20:27




          $begingroup$
          @Voo Yes, it's a popular extension and C got it earlier with C99.
          $endgroup$
          – Deduplicator
          Jan 8 at 20:27












          $begingroup$
          @Deduplicator Yeah I know that C had it for years, I just assumed C++ would've gotten it around c++11 or possibly 14 as well. Well, better late than never.
          $endgroup$
          – Voo
          Jan 8 at 22:13






          $begingroup$
          @Deduplicator Yeah I know that C had it for years, I just assumed C++ would've gotten it around c++11 or possibly 14 as well. Well, better late than never.
          $endgroup$
          – Voo
          Jan 8 at 22:13




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Code Review Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          Use MathJax to format equations. MathJax reference.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f211072%2fcleaner-way-to-handle-double-pointer-in-c-bst%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Human spaceflight

          Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

          張江高科駅