Pointer to a vector












0















What is wrong with the following code



vector < double >* a;
a->push_back(25);
a->push_back(30);
a->push_back(15);
a->push_back(40);
cout << a->at(2) << endl;


It should print 15, but it prints nothing










share|improve this question




















  • 2





    no a = new std::vector<double> somewhere?

    – max66
    Nov 28 '18 at 2:21













  • yeah, that was the problem. Thank you so much :)

    – mpelia
    Nov 28 '18 at 2:26






  • 1





    and don't forget the corresponding delete a

    – max66
    Nov 28 '18 at 2:54













  • Obligatory: you should wrap a pointer like that as std::unique_ptr. In general, if you have new and delete in modern C++ application code, you'd better have a good reason for it. Otherwise, use smart pointers!

    – hyde
    Nov 28 '18 at 20:17








  • 3





    Obligatory - there are almost no reasons to use dynamic storage to store a vector.

    – SergeyA
    Nov 28 '18 at 20:19
















0















What is wrong with the following code



vector < double >* a;
a->push_back(25);
a->push_back(30);
a->push_back(15);
a->push_back(40);
cout << a->at(2) << endl;


It should print 15, but it prints nothing










share|improve this question




















  • 2





    no a = new std::vector<double> somewhere?

    – max66
    Nov 28 '18 at 2:21













  • yeah, that was the problem. Thank you so much :)

    – mpelia
    Nov 28 '18 at 2:26






  • 1





    and don't forget the corresponding delete a

    – max66
    Nov 28 '18 at 2:54













  • Obligatory: you should wrap a pointer like that as std::unique_ptr. In general, if you have new and delete in modern C++ application code, you'd better have a good reason for it. Otherwise, use smart pointers!

    – hyde
    Nov 28 '18 at 20:17








  • 3





    Obligatory - there are almost no reasons to use dynamic storage to store a vector.

    – SergeyA
    Nov 28 '18 at 20:19














0












0








0








What is wrong with the following code



vector < double >* a;
a->push_back(25);
a->push_back(30);
a->push_back(15);
a->push_back(40);
cout << a->at(2) << endl;


It should print 15, but it prints nothing










share|improve this question
















What is wrong with the following code



vector < double >* a;
a->push_back(25);
a->push_back(30);
a->push_back(15);
a->push_back(40);
cout << a->at(2) << endl;


It should print 15, but it prints nothing







c++ c++14






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 28 '18 at 20:14









ΦXocę 웃 Пepeúpa ツ

33.9k113965




33.9k113965










asked Nov 28 '18 at 2:17









mpeliampelia

233




233








  • 2





    no a = new std::vector<double> somewhere?

    – max66
    Nov 28 '18 at 2:21













  • yeah, that was the problem. Thank you so much :)

    – mpelia
    Nov 28 '18 at 2:26






  • 1





    and don't forget the corresponding delete a

    – max66
    Nov 28 '18 at 2:54













  • Obligatory: you should wrap a pointer like that as std::unique_ptr. In general, if you have new and delete in modern C++ application code, you'd better have a good reason for it. Otherwise, use smart pointers!

    – hyde
    Nov 28 '18 at 20:17








  • 3





    Obligatory - there are almost no reasons to use dynamic storage to store a vector.

    – SergeyA
    Nov 28 '18 at 20:19














  • 2





    no a = new std::vector<double> somewhere?

    – max66
    Nov 28 '18 at 2:21













  • yeah, that was the problem. Thank you so much :)

    – mpelia
    Nov 28 '18 at 2:26






  • 1





    and don't forget the corresponding delete a

    – max66
    Nov 28 '18 at 2:54













  • Obligatory: you should wrap a pointer like that as std::unique_ptr. In general, if you have new and delete in modern C++ application code, you'd better have a good reason for it. Otherwise, use smart pointers!

    – hyde
    Nov 28 '18 at 20:17








  • 3





    Obligatory - there are almost no reasons to use dynamic storage to store a vector.

    – SergeyA
    Nov 28 '18 at 20:19








2




2





no a = new std::vector<double> somewhere?

– max66
Nov 28 '18 at 2:21







no a = new std::vector<double> somewhere?

– max66
Nov 28 '18 at 2:21















yeah, that was the problem. Thank you so much :)

– mpelia
Nov 28 '18 at 2:26





yeah, that was the problem. Thank you so much :)

– mpelia
Nov 28 '18 at 2:26




1




1





and don't forget the corresponding delete a

– max66
Nov 28 '18 at 2:54







and don't forget the corresponding delete a

– max66
Nov 28 '18 at 2:54















Obligatory: you should wrap a pointer like that as std::unique_ptr. In general, if you have new and delete in modern C++ application code, you'd better have a good reason for it. Otherwise, use smart pointers!

– hyde
Nov 28 '18 at 20:17







Obligatory: you should wrap a pointer like that as std::unique_ptr. In general, if you have new and delete in modern C++ application code, you'd better have a good reason for it. Otherwise, use smart pointers!

– hyde
Nov 28 '18 at 20:17






3




3





Obligatory - there are almost no reasons to use dynamic storage to store a vector.

– SergeyA
Nov 28 '18 at 20:19





Obligatory - there are almost no reasons to use dynamic storage to store a vector.

– SergeyA
Nov 28 '18 at 20:19












3 Answers
3






active

oldest

votes


















1














a is a pointer but is not properly initialized... it must be like:



int main()
{
std::vector<double>* a = new std::vector<double>;
a->push_back(25);
a->push_back(30);
a->push_back(15);
a->push_back(40);
std::cout << a->at(2) << std::endl;
delete a;
return 0;
}





share|improve this answer

































    1















    What is wrong ...?




    You are using a pointer where an automatic duration value is more appropriate.



    std::vector < double > a;
    a.push_back(25);
    a.push_back(30);
    a.push_back(15);
    a.push_back(40);
    std::cout << a.at(2) << std::endl;





    share|improve this answer































      -1














      Your pointer wasn't initialized. Additionally, based on the answer by ΦXocę 웃 Пepeúpa ツ, make sure when you are working with pointers to use new/delete correctly. For every new keyword, there should be a delete. It is also good practice to avoid dangling pointers (pointers that do not reference anything) by setting them to NULL (as of C++11, it's recommended to use nullptr: NULL vs nullptr (Why was it replaced?) and What exactly is nullptr? questions offer some good explanations) when you are done.



      However, in this case, I agree with Acorn. You shouldn't have to point to a vectorobject because of how it allocates memory. It should be sufficient to just use a vector for your solution.






      share|improve this answer
























      • It is also good practice to avoid dangling pointers (pointers that do not reference anything) by setting them to NULL - nothing good about this anti-pattern.

        – SergeyA
        Nov 28 '18 at 20:35











      • Please clarify? I specifically stated that nullptr is better than using NULL. What is not good here?

        – jameyb
        Nov 28 '18 at 20:39











      • It is not about nullptr vs null. It is about that setting pointer to nullptr after deleting is is a false safety and antipattern.

        – SergeyA
        Nov 28 '18 at 20:42











      • Well, it depends doesn't it? Perhaps if you want to discuss this later it'd be more appropriate to talk in the chat or something. I am confused as to exactly how you can claim it is false. Reading through the question and answers below, it seems that it really does depend: stackoverflow.com/questions/1931126/…

        – jameyb
        Nov 28 '18 at 20:48








      • 1





        See stackoverflow.com/questions/704466/… (some answers after the top one). The main problem with that is false sense of safety. Even on your own link, it is mentioned that it is a bandaid over fundamental problem. WHY your application deletes the pointer twice? It could be argued that it is better to let it crash rather than mask the problem, until it pops somewhere else.

        – SergeyA
        Nov 28 '18 at 20:53













      Your Answer






      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: "1"
      };
      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: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      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%2fstackoverflow.com%2fquestions%2f53511138%2fpointer-to-a-vector%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      1














      a is a pointer but is not properly initialized... it must be like:



      int main()
      {
      std::vector<double>* a = new std::vector<double>;
      a->push_back(25);
      a->push_back(30);
      a->push_back(15);
      a->push_back(40);
      std::cout << a->at(2) << std::endl;
      delete a;
      return 0;
      }





      share|improve this answer






























        1














        a is a pointer but is not properly initialized... it must be like:



        int main()
        {
        std::vector<double>* a = new std::vector<double>;
        a->push_back(25);
        a->push_back(30);
        a->push_back(15);
        a->push_back(40);
        std::cout << a->at(2) << std::endl;
        delete a;
        return 0;
        }





        share|improve this answer




























          1












          1








          1







          a is a pointer but is not properly initialized... it must be like:



          int main()
          {
          std::vector<double>* a = new std::vector<double>;
          a->push_back(25);
          a->push_back(30);
          a->push_back(15);
          a->push_back(40);
          std::cout << a->at(2) << std::endl;
          delete a;
          return 0;
          }





          share|improve this answer















          a is a pointer but is not properly initialized... it must be like:



          int main()
          {
          std::vector<double>* a = new std::vector<double>;
          a->push_back(25);
          a->push_back(30);
          a->push_back(15);
          a->push_back(40);
          std::cout << a->at(2) << std::endl;
          delete a;
          return 0;
          }






          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 28 '18 at 20:19

























          answered Nov 28 '18 at 20:14









          ΦXocę 웃 Пepeúpa ツΦXocę 웃 Пepeúpa ツ

          33.9k113965




          33.9k113965

























              1















              What is wrong ...?




              You are using a pointer where an automatic duration value is more appropriate.



              std::vector < double > a;
              a.push_back(25);
              a.push_back(30);
              a.push_back(15);
              a.push_back(40);
              std::cout << a.at(2) << std::endl;





              share|improve this answer




























                1















                What is wrong ...?




                You are using a pointer where an automatic duration value is more appropriate.



                std::vector < double > a;
                a.push_back(25);
                a.push_back(30);
                a.push_back(15);
                a.push_back(40);
                std::cout << a.at(2) << std::endl;





                share|improve this answer


























                  1












                  1








                  1








                  What is wrong ...?




                  You are using a pointer where an automatic duration value is more appropriate.



                  std::vector < double > a;
                  a.push_back(25);
                  a.push_back(30);
                  a.push_back(15);
                  a.push_back(40);
                  std::cout << a.at(2) << std::endl;





                  share|improve this answer














                  What is wrong ...?




                  You are using a pointer where an automatic duration value is more appropriate.



                  std::vector < double > a;
                  a.push_back(25);
                  a.push_back(30);
                  a.push_back(15);
                  a.push_back(40);
                  std::cout << a.at(2) << std::endl;






                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Nov 29 '18 at 11:22









                  CalethCaleth

                  18k22141




                  18k22141























                      -1














                      Your pointer wasn't initialized. Additionally, based on the answer by ΦXocę 웃 Пepeúpa ツ, make sure when you are working with pointers to use new/delete correctly. For every new keyword, there should be a delete. It is also good practice to avoid dangling pointers (pointers that do not reference anything) by setting them to NULL (as of C++11, it's recommended to use nullptr: NULL vs nullptr (Why was it replaced?) and What exactly is nullptr? questions offer some good explanations) when you are done.



                      However, in this case, I agree with Acorn. You shouldn't have to point to a vectorobject because of how it allocates memory. It should be sufficient to just use a vector for your solution.






                      share|improve this answer
























                      • It is also good practice to avoid dangling pointers (pointers that do not reference anything) by setting them to NULL - nothing good about this anti-pattern.

                        – SergeyA
                        Nov 28 '18 at 20:35











                      • Please clarify? I specifically stated that nullptr is better than using NULL. What is not good here?

                        – jameyb
                        Nov 28 '18 at 20:39











                      • It is not about nullptr vs null. It is about that setting pointer to nullptr after deleting is is a false safety and antipattern.

                        – SergeyA
                        Nov 28 '18 at 20:42











                      • Well, it depends doesn't it? Perhaps if you want to discuss this later it'd be more appropriate to talk in the chat or something. I am confused as to exactly how you can claim it is false. Reading through the question and answers below, it seems that it really does depend: stackoverflow.com/questions/1931126/…

                        – jameyb
                        Nov 28 '18 at 20:48








                      • 1





                        See stackoverflow.com/questions/704466/… (some answers after the top one). The main problem with that is false sense of safety. Even on your own link, it is mentioned that it is a bandaid over fundamental problem. WHY your application deletes the pointer twice? It could be argued that it is better to let it crash rather than mask the problem, until it pops somewhere else.

                        – SergeyA
                        Nov 28 '18 at 20:53


















                      -1














                      Your pointer wasn't initialized. Additionally, based on the answer by ΦXocę 웃 Пepeúpa ツ, make sure when you are working with pointers to use new/delete correctly. For every new keyword, there should be a delete. It is also good practice to avoid dangling pointers (pointers that do not reference anything) by setting them to NULL (as of C++11, it's recommended to use nullptr: NULL vs nullptr (Why was it replaced?) and What exactly is nullptr? questions offer some good explanations) when you are done.



                      However, in this case, I agree with Acorn. You shouldn't have to point to a vectorobject because of how it allocates memory. It should be sufficient to just use a vector for your solution.






                      share|improve this answer
























                      • It is also good practice to avoid dangling pointers (pointers that do not reference anything) by setting them to NULL - nothing good about this anti-pattern.

                        – SergeyA
                        Nov 28 '18 at 20:35











                      • Please clarify? I specifically stated that nullptr is better than using NULL. What is not good here?

                        – jameyb
                        Nov 28 '18 at 20:39











                      • It is not about nullptr vs null. It is about that setting pointer to nullptr after deleting is is a false safety and antipattern.

                        – SergeyA
                        Nov 28 '18 at 20:42











                      • Well, it depends doesn't it? Perhaps if you want to discuss this later it'd be more appropriate to talk in the chat or something. I am confused as to exactly how you can claim it is false. Reading through the question and answers below, it seems that it really does depend: stackoverflow.com/questions/1931126/…

                        – jameyb
                        Nov 28 '18 at 20:48








                      • 1





                        See stackoverflow.com/questions/704466/… (some answers after the top one). The main problem with that is false sense of safety. Even on your own link, it is mentioned that it is a bandaid over fundamental problem. WHY your application deletes the pointer twice? It could be argued that it is better to let it crash rather than mask the problem, until it pops somewhere else.

                        – SergeyA
                        Nov 28 '18 at 20:53
















                      -1












                      -1








                      -1







                      Your pointer wasn't initialized. Additionally, based on the answer by ΦXocę 웃 Пepeúpa ツ, make sure when you are working with pointers to use new/delete correctly. For every new keyword, there should be a delete. It is also good practice to avoid dangling pointers (pointers that do not reference anything) by setting them to NULL (as of C++11, it's recommended to use nullptr: NULL vs nullptr (Why was it replaced?) and What exactly is nullptr? questions offer some good explanations) when you are done.



                      However, in this case, I agree with Acorn. You shouldn't have to point to a vectorobject because of how it allocates memory. It should be sufficient to just use a vector for your solution.






                      share|improve this answer













                      Your pointer wasn't initialized. Additionally, based on the answer by ΦXocę 웃 Пepeúpa ツ, make sure when you are working with pointers to use new/delete correctly. For every new keyword, there should be a delete. It is also good practice to avoid dangling pointers (pointers that do not reference anything) by setting them to NULL (as of C++11, it's recommended to use nullptr: NULL vs nullptr (Why was it replaced?) and What exactly is nullptr? questions offer some good explanations) when you are done.



                      However, in this case, I agree with Acorn. You shouldn't have to point to a vectorobject because of how it allocates memory. It should be sufficient to just use a vector for your solution.







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Nov 28 '18 at 20:33









                      jameybjameyb

                      146




                      146













                      • It is also good practice to avoid dangling pointers (pointers that do not reference anything) by setting them to NULL - nothing good about this anti-pattern.

                        – SergeyA
                        Nov 28 '18 at 20:35











                      • Please clarify? I specifically stated that nullptr is better than using NULL. What is not good here?

                        – jameyb
                        Nov 28 '18 at 20:39











                      • It is not about nullptr vs null. It is about that setting pointer to nullptr after deleting is is a false safety and antipattern.

                        – SergeyA
                        Nov 28 '18 at 20:42











                      • Well, it depends doesn't it? Perhaps if you want to discuss this later it'd be more appropriate to talk in the chat or something. I am confused as to exactly how you can claim it is false. Reading through the question and answers below, it seems that it really does depend: stackoverflow.com/questions/1931126/…

                        – jameyb
                        Nov 28 '18 at 20:48








                      • 1





                        See stackoverflow.com/questions/704466/… (some answers after the top one). The main problem with that is false sense of safety. Even on your own link, it is mentioned that it is a bandaid over fundamental problem. WHY your application deletes the pointer twice? It could be argued that it is better to let it crash rather than mask the problem, until it pops somewhere else.

                        – SergeyA
                        Nov 28 '18 at 20:53





















                      • It is also good practice to avoid dangling pointers (pointers that do not reference anything) by setting them to NULL - nothing good about this anti-pattern.

                        – SergeyA
                        Nov 28 '18 at 20:35











                      • Please clarify? I specifically stated that nullptr is better than using NULL. What is not good here?

                        – jameyb
                        Nov 28 '18 at 20:39











                      • It is not about nullptr vs null. It is about that setting pointer to nullptr after deleting is is a false safety and antipattern.

                        – SergeyA
                        Nov 28 '18 at 20:42











                      • Well, it depends doesn't it? Perhaps if you want to discuss this later it'd be more appropriate to talk in the chat or something. I am confused as to exactly how you can claim it is false. Reading through the question and answers below, it seems that it really does depend: stackoverflow.com/questions/1931126/…

                        – jameyb
                        Nov 28 '18 at 20:48








                      • 1





                        See stackoverflow.com/questions/704466/… (some answers after the top one). The main problem with that is false sense of safety. Even on your own link, it is mentioned that it is a bandaid over fundamental problem. WHY your application deletes the pointer twice? It could be argued that it is better to let it crash rather than mask the problem, until it pops somewhere else.

                        – SergeyA
                        Nov 28 '18 at 20:53



















                      It is also good practice to avoid dangling pointers (pointers that do not reference anything) by setting them to NULL - nothing good about this anti-pattern.

                      – SergeyA
                      Nov 28 '18 at 20:35





                      It is also good practice to avoid dangling pointers (pointers that do not reference anything) by setting them to NULL - nothing good about this anti-pattern.

                      – SergeyA
                      Nov 28 '18 at 20:35













                      Please clarify? I specifically stated that nullptr is better than using NULL. What is not good here?

                      – jameyb
                      Nov 28 '18 at 20:39





                      Please clarify? I specifically stated that nullptr is better than using NULL. What is not good here?

                      – jameyb
                      Nov 28 '18 at 20:39













                      It is not about nullptr vs null. It is about that setting pointer to nullptr after deleting is is a false safety and antipattern.

                      – SergeyA
                      Nov 28 '18 at 20:42





                      It is not about nullptr vs null. It is about that setting pointer to nullptr after deleting is is a false safety and antipattern.

                      – SergeyA
                      Nov 28 '18 at 20:42













                      Well, it depends doesn't it? Perhaps if you want to discuss this later it'd be more appropriate to talk in the chat or something. I am confused as to exactly how you can claim it is false. Reading through the question and answers below, it seems that it really does depend: stackoverflow.com/questions/1931126/…

                      – jameyb
                      Nov 28 '18 at 20:48







                      Well, it depends doesn't it? Perhaps if you want to discuss this later it'd be more appropriate to talk in the chat or something. I am confused as to exactly how you can claim it is false. Reading through the question and answers below, it seems that it really does depend: stackoverflow.com/questions/1931126/…

                      – jameyb
                      Nov 28 '18 at 20:48






                      1




                      1





                      See stackoverflow.com/questions/704466/… (some answers after the top one). The main problem with that is false sense of safety. Even on your own link, it is mentioned that it is a bandaid over fundamental problem. WHY your application deletes the pointer twice? It could be argued that it is better to let it crash rather than mask the problem, until it pops somewhere else.

                      – SergeyA
                      Nov 28 '18 at 20:53







                      See stackoverflow.com/questions/704466/… (some answers after the top one). The main problem with that is false sense of safety. Even on your own link, it is mentioned that it is a bandaid over fundamental problem. WHY your application deletes the pointer twice? It could be argued that it is better to let it crash rather than mask the problem, until it pops somewhere else.

                      – SergeyA
                      Nov 28 '18 at 20:53




















                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Stack Overflow!


                      • 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.


                      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%2fstackoverflow.com%2fquestions%2f53511138%2fpointer-to-a-vector%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

                      A CLEAN and SIMPLE way to add appendices to Table of Contents and bookmarks

                      Calculate evaluation metrics using cross_val_predict sklearn

                      Insert data from modal to MySQL (multiple modal on website)