Pointer to a vector

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

edited Nov 28 '18 at 20:14

ΦXocę 웃 Пepeúpa ツ

33.9k113965

asked Nov 28 '18 at 2:17

mpelia

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

add a comment |

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

edited Nov 28 '18 at 20:14

ΦXocę 웃 Пepeúpa ツ

33.9k113965

asked Nov 28 '18 at 2:17

mpelia

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

add a comment |

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

edited Nov 28 '18 at 20:14

ΦXocę 웃 Пepeúpa ツ

33.9k113965

asked Nov 28 '18 at 2:17

mpelia

233

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

edited Nov 28 '18 at 20:14

ΦXocę 웃 Пepeúpa ツ

33.9k113965

asked Nov 28 '18 at 2:17

mpelia

233

edited Nov 28 '18 at 20:14

ΦXocę 웃 Пepeúpa ツ

33.9k113965

asked Nov 28 '18 at 2:17

mpelia

233

edited Nov 28 '18 at 20:14

ΦXocę 웃 Пepeúpa ツ

33.9k113965

edited Nov 28 '18 at 20:14

ΦXocę 웃 Пepeúpa ツ

33.9k113965

edited Nov 28 '18 at 20:14

ΦXocę 웃 Пepeúpa ツ

33.9k113965

asked Nov 28 '18 at 2:17

mpelia

233

asked Nov 28 '18 at 2:17

mpelia

233

asked Nov 28 '18 at 2:17

mpelia

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

add a comment |

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

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

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 - there are almost no reasons to use dynamic storage to store a vector.

– SergeyA
Nov 28 '18 at 20:19

add a comment |

3 Answers
3

active

oldest

votes

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;

}

edited Nov 28 '18 at 20:19

answered Nov 28 '18 at 20:14

ΦXocę 웃 Пepeúpa ツ

33.9k113965

add a comment |

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;

answered Nov 29 '18 at 11:22

Caleth

18k22141

add a comment |

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

answered Nov 28 '18 at 20:33

jameyb

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

add a comment |

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

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

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

Name

Required, but never shown

3 Answers
3

active

oldest

votes

3 Answers
3

active

oldest

votes

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;

}

edited Nov 28 '18 at 20:19

answered Nov 28 '18 at 20:14

ΦXocę 웃 Пepeúpa ツ

33.9k113965

add a comment |

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;

}

edited Nov 28 '18 at 20:19

answered Nov 28 '18 at 20:14

ΦXocę 웃 Пepeúpa ツ

33.9k113965

add a comment |

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;

}

edited Nov 28 '18 at 20:19

answered Nov 28 '18 at 20:14

ΦXocę 웃 Пepeúpa ツ

33.9k113965

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;

}

edited Nov 28 '18 at 20:19

answered Nov 28 '18 at 20:14

ΦXocę 웃 Пepeúpa ツ

33.9k113965

edited Nov 28 '18 at 20:19

answered Nov 28 '18 at 20:14

ΦXocę 웃 Пepeúpa ツ

33.9k113965

answered Nov 28 '18 at 20:14

ΦXocę 웃 Пepeúpa ツ

33.9k113965

answered Nov 28 '18 at 20:14

ΦXocę 웃 Пepeúpa ツ

33.9k113965

add a comment |

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;

answered Nov 29 '18 at 11:22

Caleth

18k22141

add a comment |

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;

answered Nov 29 '18 at 11:22

Caleth

18k22141

add a comment |

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;

answered Nov 29 '18 at 11:22

Caleth

18k22141

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;

answered Nov 29 '18 at 11:22

Caleth

18k22141

answered Nov 29 '18 at 11:22

Caleth

18k22141

answered Nov 29 '18 at 11:22

Caleth

18k22141

answered Nov 29 '18 at 11:22

Caleth

18k22141

add a comment |

-1

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.

answered Nov 28 '18 at 20:33

jameyb

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

add a comment |

-1

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.

answered Nov 28 '18 at 20:33

jameyb

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

add a comment |

-1

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.

answered Nov 28 '18 at 20:33

jameyb

146

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.

answered Nov 28 '18 at 20:33

jameyb

146

answered Nov 28 '18 at 20:33

jameyb

146

answered Nov 28 '18 at 20:33

jameyb

146

answered Nov 28 '18 at 20:33

jameyb

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

add a comment |

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

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

add a comment |

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

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Btukfyl