]]>鍏充簬 shared_from_this 鐨勪竴涓鐐?/title>http://m.shnenglu.com/tommy/archive/2011/03/24/142679.htmlTommy LiangTommy LiangThu, 24 Mar 2011 15:29:00 GMThttp://m.shnenglu.com/tommy/archive/2011/03/24/142679.htmlhttp://m.shnenglu.com/tommy/comments/142679.htmlhttp://m.shnenglu.com/tommy/archive/2011/03/24/142679.html#Feedback0http://m.shnenglu.com/tommy/comments/commentRss/142679.htmlhttp://m.shnenglu.com/tommy/services/trackbacks/142679.htmlhttp://boost.2283326.n4.nabble.com/enabled-shared-from-this-bad-weak-ptr-exception-online-doc-explanation-td2583370.html
Sinceinthe current version you cannot callshared_from_this()ina constructor, you can'tinitializeyourmemberswith an expression that invlovesshared_from_this().Instead, you can set your shared_ptr'sin someinitializingmemberfunction that would be called after the object is constructed:
struct B; struct A { A(shared_ptr<B> b) { //... } };
class B : public enable_shared_from_this<B> { shared_ptr<A> a_; public: voidinit() { a_.reset(new A(shared_from_this())); } };
main() { shared_ptr<B> b(new B); b->init(); }
...also you can wrapinitializationina static constructing function:
]]>Boost.SmartPtrhttp://m.shnenglu.com/tommy/archive/2011/03/23/142547.htmlTommy LiangTommy LiangWed, 23 Mar 2011 02:01:00 GMThttp://m.shnenglu.com/tommy/archive/2011/03/23/142547.htmlhttp://m.shnenglu.com/tommy/comments/142547.htmlhttp://m.shnenglu.com/tommy/archive/2011/03/23/142547.html#Feedback0http://m.shnenglu.com/tommy/comments/commentRss/142547.htmlhttp://m.shnenglu.com/tommy/services/trackbacks/142547.htmlUse scoped_ptr when
A pointer is used in a scope where an exception may be thrown
There are several control paths in a function
The lifetime of a dynamically allocated object can be limited to a specific scope
Exception safety is important (always!)
Use shared_ptr in the following scenarios:
When there are multiple clients of an object, but no explicit owner
When storing pointers in Standard Library containers
When passing objects to and from libraries without (other) expressed ownership
When managing resources that need special cleanup[9]
]]>鍏充簬C++鐨?explicit鍏抽敭瀛?/title>http://m.shnenglu.com/tommy/archive/2006/02/05/3058.htmlTommy LiangTommy LiangSat, 04 Feb 2006 21:16:00 GMThttp://m.shnenglu.com/tommy/archive/2006/02/05/3058.htmlhttp://m.shnenglu.com/tommy/comments/3058.htmlhttp://m.shnenglu.com/tommy/archive/2006/02/05/3058.html#Feedback6http://m.shnenglu.com/tommy/comments/commentRss/3058.htmlhttp://m.shnenglu.com/tommy/services/trackbacks/3058.html綆鑰岃█涔嬶細explicit淇グ鐨勬瀯閫犲嚱鏁頒笉鑳芥媴浠昏漿鎹㈠嚱鏁?BR> 榪欎釜 銆?FONT color=#551a8b>ANSI/ISO C++ Professional Programmer's Handbook 銆嬫槸榪欐牱璇寸殑
explicit Constructors A constructor that takes a single argument is, by default, an implicit conversion operator, which converts its argument to an object of its class (see also Chapter 3, "Operator Overloading"). Examine the following concrete example: class string { private: int size; int capacity; char *buff; public: string(); string(int size); // constructor and implicit conversion operator string(const char *); // constructor and implicit conversion operator ~string(); }; Class string has three constructors: a default constructor, a constructor that takes int, and a constructor that constructs a string from const char *. The second constructor is used to create an empty string object with an initial preallocated buffer at the specified size. However, in the case of class string, the automatic conversion is dubious. Converting an int into a string object doesn't make sense, although this is exactly what this constructor does.
Consider the following: int main() { string s = "hello"; //OK, convert a C-string into a string object int ns = 0; s = 1; // 1 oops, programmer intended to write ns = 1, } In the expression s= 1;, the programmer simply mistyped the name of the variable ns, typing s instead. Normally, the compiler detects the incompatible types and issues an error message. However, before ruling it out, the compiler first searches for a user-defined conversion that allows this expression; indeed, it finds the constructor that takes int. Consequently, the compiler interprets the expression s= 1; as if the programmer had written s = string(1); You might encounter a similar problem when calling a function that takes a string argument. The following example can either be a cryptic coding style or simply a programmer's typographical error. However, due to the implicit conversion constructor of class string, it will pass unnoticed: int f(string s); int main() { f(1); // without a an explicit constructor, //this call is expanded into: f ( string(1) ); //was that intentional or merely a programmer's typo? } 'In order to avoid such implicit conversions, a constructor that takes one argument needs to be declared explicit: class string { //... public: explicit string(int size); // block implicit conversion string(const char *); //implicit conversion ~string(); }; An explicit constructor does not behave as an implicit conversion operator, which enables the compiler to catch the typographical error this time: int main() { string s = "hello"; //OK, convert a C-string into a string object int ns = 0; s = 1; // compile time error ; this time the compiler catches the typo } Why aren't all constructors automatically declared explicit? Under some conditions, the automatic type conversion is useful and well behaved. A good example of this is the third constructor of string: string(const char *);
The implicit type conversion of const char * to a string object enables its users to write the following: string s; s = "Hello"; The compiler implicitly transforms this into string s; //pseudo C++ code: s = string ("Hello"); //create a temporary and assign it to s On the other hand, if you declare this constructor explicit, you have to use explicit type conversion: class string { //... public: explicit string(const char *); }; int main() { string s; s = string("Hello"); //explicit conversion now required return 0; } Extensive amounts of legacy C++ code rely on the implicit conversion of constructors. The C++ Standardization committee was aware of that. In order to not make existing code break, the implicit conversion was retained. However, a new keyword, explicit, was introduced to the languageto enable the programmer to block the implicit conversion when it is undesirable. As a rule, a constructor that can be invoked with a single argument needs to be declared explicit. When the implicit type conversion is intentional and well behaved, the constructor can be used as an implicit conversion operator.