On Sun, May 16, 2010 at 4:00 AM, 鑫炜廖 wrote:

Igor R writes:

...

...

I want to distinguish the error_code set by calling socket::close from any other ways (like system error, network error, etc), otherwise, I can't determine whether I should delete the object in async handlers, because some have already been deleted after I call socket::close. If boost::asio::error::operation_aborted definitely means "socket::close is called", I can distinguish this situation.

It seems to be rather error-prone approach. One day, when your application will have grown a bit, you'll find yourself hunting weird segfaults / access-violations.

But when should I delete the object after I call socket::close? May be there's no async handler, so just deleting object in handlers leads to memory leak.

...

...

I've tried using boost::weak_ptr with boost::bind,but the performance decrease dramatically.

Did you run a performance profiler with fully-optimized application and really discovered that the bottle-neck is in shared_ptr's?! This would be really surprising...

I've tested it separately, when binding a weak_ptr/shared_ptr with a member function, it will cause extra new/delete operations, but raw pointer will not(gcc 4.4.1, boost 1.4.3).The former way is about 20 times slower,as a frequently operation, it seems not acceptable.

That is because you are most likely using the inefficient creation style, probably like this: shared_ptr<myClass> myPtr(new myClass(arg1,arg2)); Which will also new a struct inside the shared_ptr that holds that pointer and bookkeeping information. If you have read the shared_ptr documentation, the efficient creation style is this: shared_ptr<myClass> myPtr = make_shared<myClass>(arg1,arg2); Which will new both your class and the bookkeeping information in the same place in memory, increasing both the speed of creation (only one new), and speed of accessing (better cache coherency). When creating your objects at the same time (literally) as the shared_ptr, that should fix most of those speed issues.