Jump to content

Talk:Auto ptr

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

How to free alloc()ed and new[] objects ?

[edit]

So what to do, if I have pointers to objects allocated with malloc() or new[] (which are not handled by auto_ptr) ? --Xerces8 (talk) 08:38, 5 November 2008 (UTC)[reply]

For malloc, you use free. For new[], you use delete[]. Superm401 - Talk 11:44, 19 December 2008 (UTC)[reply]
Yes, and for new one uses delete. Now back to auto_ptr (that is automatic freeing of the object(s)) ;-) --Xerces8 (talk) 15:12, 19 December 2008 (UTC)[reply]
Not possible with auto_ptr. Consider using a vector instead of new[]. Third-party solutions also exist (boost::shared_array), if you can provide a scenario where vector can't be used :). decltype 09:54, 6 March 2009 (UTC)[reply]

Renaming this article to follow a consistent convention

[edit]

Hi, I am currently considering renaming this article to conform to a common convention for C++ Standard Library components. The full discussion can be found here. decltype 09:48, 6 March 2009 (UTC)[reply]

A slightly different implementation in Nicolaï Josuttis book

[edit]

In his book The C++ Standard Library, A Tutorial and Reference, 21st Printing, January 2008, p. 51, Nicolaï Josuttis - member of the Standard Committee library working group - gives a slightly different version, available on http://www.josuttis.com/libbook/ (index of all examples/auto_ptr implementation).

He describes it as follows (p. 51 note 6):

This is a slightly improved version that fixes some minor problems of the version in the C++ standard (auto_ptr_ref is global now and there is an assignment operator from auto_ptr_ref to auto_ptr; see page 55). Ptyxss (talk) 15:49, 23 June 2009 (UTC)[reply]

Use of auto_ptr to make object constant

[edit]

I've removed the text below from the article, because I think it is a bad example. You can equally well use a const reference to an object to make the object constant. One could still try to use the open_vec, leading to a runtime error (which is not better than accidentally changing the vec), and it involves extra code (at runtime + in lines) to enforce compile-time constness-checks, which I think is not something which should be advised.

anoko_moonlight (talk) 12:51, 29 November 2015 (UTC)[reply]

Remove text:

However, an auto_ptr containing an STL container may be used to prevent further modification of the container.

#include <iostream>
#include <vector>
#include <memory> 
#include <map>

using namespace std;

typedef int ContainedType;

int main() {

    auto_ptr<vector<ContainedType> > open_vec(new vector<ContainedType>);

    open_vec->push_back(5);
    open_vec->push_back(3);
    open_vec->push_back(1);

    // Transfers control, but now the vector cannot be changed:
    auto_ptr<const vector<ContainedType> > closed_vec(open_vec); 

    // closed_vec->push_back(8); // Can no longer modify 

    // Safe during the lifetime of the autoptr:
    map<string, const ContainedType *> nmap;

    nmap["First"]  = & closed_vec->at(0);
    nmap["Second"] = & closed_vec->at(1);
    nmap["Third"]  = & closed_vec->at(2);
    
    for (map<string, const ContainedType *>::iterator it = nmap.begin(); it != nmap.end(); ++it) {
        cout << it->first << " -> " << *(it->second) << std::endl;
    }

    return 0;
}