C++ Reference Guide

unique_ptr And The Deprecation Of auto_ptr

Last updated Oct 3, 2008.

The introduction to unique_ptr and the related discussion on rvalue references triggered many questions. Here's one of them:

I read your introduction to unique_ptr recently and wondered: could auto_ptr be deprecated only because the new C++ standard supports rvalue references? In other words, would auto_ptr have remained normative (non-deprecated) otherwise?

Yes and no. There is no doubt that the addition of rvalue references to C++0x has enabled library designers to come up with a superior design of a smart pointer class that implements the strict ownership semantics, as does unique_ptr. Then again, auto_ptr, as explained in the article you're referring to, has been the cause of subtle bugs that innocent users can't detect easily. Such a class has no place in the Standard Library so it had to be deprecated anyway, eventually. It can be said that auto_ptr has always been the black sheep of the Standard Library — even before the term "Standard Library" was coined. So it was just a question of when, not if, auto_ptr would be deprecated. And yet, the decision to deprecate a standard feature isn't to be taken lightly.

When the standards committee deprecates a feature, they usually have to propose a superior alternative, or a prescribed norm. Otherwise, there’s no point in deprecating something that users can't avoid. Take the use of the keyword static to indicate internal linkage for example. When the committee deprecated that use of static, they proposed an alternative mechanism called unnamed namespaces for ensuring file-scope visibility of names.

To summarize, auto_ptr was incorrigibly buggy, in spite of numerous attempts to fix it. Hence, it had to be deprecated. Howard Hinnant designed a superior alternative — unique_ptr. Without rvalue references it would have been impossible to design the latter so you can say that the addition of rvalue references to C++0x led, at least indirectly, to the deprecation of auto_ptr, although that deprecation was inevitable.

What's In A const String?

Here's another question regarding the properties of const qualification and strings:

I'd like to have a data member with the ability of a pointer to a const object which will point to a different constant object at runtime, as does the data member text in class Foo:

class Foo
{
 const char* text;
 void changeText(const char* update)
 {
   // assign a new constant text
   text = update;  // OK, the pointer itself isn't const

   // try modify the text itself
   strcat(text, update); // fails to compile: cannot convert parameter 1 from 'const char *' to 'char_t *'
 }
};

Why do I not witness the same behavior of const when I replace the char * with a std::string object?

class Bar
{
 const std::string ctext;
 void ChangeText(const char* update)
 {
   ctext = update; // fails to compile, although I want it to!
   ctext += update;// fails to compile, OK: change prevented
 }
};

Your two classes use two different types of const, as a matter of fact. In the first example you're using a pointer to const, whereas in the second example the object itself is const.

When the const qualifier applies to objects, it means no more and no less than this: the programmer cannot modify the state of that object. In contrast, when using pointers to const objects, the pointer itself is changeable so you can bind to it a different object at runtime. However, you cannot modify the object bound to the pointer through that very pointer. This scenario is demonstrated clearly in the first example you provided:

text = update; //OK, text is now pointing to a new location, the data in the new location is immutable though
strcat(text, update); // error, strcat modifies the object bound to the pointer

When it comes to class objects, things work exactly in the same way — you cannot change the state of a const-qualified object. However, you can bind a new object to a pointer to const. Generally speaking, the state of an object is the set of values of its nonstatic data members. Let's see which data members std::string has:

• The internal pointer that is pointing to the text buffer.
• An integer that holds the length of that string.
• Another integer variable that tells the object what its capacity is, that is, how many more characters can be appended to the existing buffer without requiring reallocation.

In reality, a typical string class has additional data members that ensure thread safety and facilitate certain optimizations. The bottom line however is this: you can't treat a const std::string as if it were const char *. Any attempt to modify the string's text "behind its back" will fail to compile because that would change the state of the string object. There's another issue here, though. When you assign a new value to the string, you're not just assigning a new address to the string's char * data member. You're also implicitly modifying additional members that store the string's size and its capacity.

I suspect that what you're looking for is in fact const string *, not const string:

std::string mystring, yourstring;
const std::string* pstr;//the string is const, the pointer itself isn't
pstr=&mystring;//fine
*pstr="newtext";//error
pstr=&yourstring; //fine