精品午夜久久福利大片,久久精品国产久精国产一老狼,久久久国产亚洲精品

STL的remove函数和list的remove成员函数

多彩人生 — Wed, 14 Oct 2015 07:50:00 GMT

http://www.cnblogs.com/kinuxroot/archive/2013/01/25/stl_remove_problem.html

今天看书刚刚看的�Q�就记录下来吧。这可能是老生常谈了，权且作�ؓ一个警醒的例子吧�?/p>

大家都知道STL有两个非帔R��要的�l�成部分�Q�容器和��法�?/p>

��法��是一个个的函敎ͼ�通过�q�代器和容器兌��在一��P��完成一些工作�?/p>

��法和容器的分离为程序设计提供了很大的灵�z�L��，但是也带来了一些负面效果，下面我讲的这个问题就是一个例子�?/p>

STL的算法里有一个remove函数�Q�而list自��n也有一个remove函数�Q�功能都是一��L��Q�移除某一个元素，那我们应该��用哪一个呢�Q?/p>

看一下下面这�D늨��?/p>

 1     list<int> numbers;  2   3     for ( int number = 0; number <= 6; number ++ ) {  4         numbers.push_front(number);  5         numbers.push_back(number);  6     }  7   8     copy(numbers.begin(), numbers.end(),  9             ostream_iterator<int>(cout, " ")); 10     cout << endl; 11  12     // remove algorithm will remove element but not erase the element from container 13     // it will return the logical desination of container 14     list<int>::iterator endOfNumbers = remove(numbers.begin(), numbers.end(), 3); 15  16     copy(numbers.begin(), numbers.end(), 17             ostream_iterator<int>(cout, " ")); 18     cout << endl;

输出是什么呢�Q?/p>

�W�一行肯定是6 5 4 3 2 1 0 0 1 2 3 4 5 6�Q�那么第二行会输��Z��么？

如果是没有仔�l�看�q�STL的�h肯定会认为remove(number.begin(), numbers.end(), 3)会移除所有��gؓ3的元素。所以输出是�Q? 5 4 2 1 0 0 1 2 4 5 6�?/p>

但是�Q�我们看一下它真正的输出：

6 5 4 2 1 0 0 1 2 4 5 6 5 6

你可能会非常惊讶�Q��ؓ什么最后会多出5�?两个数呢�Q?/p>

我们来讲一下remove��法的原理�?/p>

remove��法工作�?strong>�q�不是直接把元素删除�Q�而是用后面的元素替代前面的元�?/strong>�Q�也��x��说如果我�?234�q�个序列remove 2�Q�返回的序列�?1344�Q?被复制到2的位�|�，4被复制到3的位�|�）�?/p>

�q�样上面的例子就好解释了�Q�那两个3的元素�ƈ没有被移除，而是用后面的元素覆盖了前面的元素。多出的那两个数没有被移除掉而已�?/p>

那么我们应该如何真正完成�U�除呢？remove函数会返回一个�P代器�Q�那个�P代器是这个序列的逻辑�l�点�Q�也��x��我代码里的endOfNumbers�Q�它指向倒数�W�二�?上�?/p>

于是我们要利用list的erase函数完成元素�U�除

numbers.erase(endOfNumbers, numbers.end());

�q�样我们��完成了我们的工作，�E�稍有点曲折……

其实我们可以把这两步攑֜�一��P��比如如果我想接着�U�除所有��gؓ2的元�?/p>

numbers.erase(remove(numbers.begin(), numbers.end(), 2), numbers.end());

�q�样我们��可以一步到位了�?/p>

但是�q�样好么�Q?/p>

不好�?/p>

大家会发玎ͼ�remove函数的原理是复制而不是指针的�U�d��Q�因为函数操�U늚�是�P代器�Q�而C++的�P代器没有定义删除操作�Q�，�q�样会带来一个问题：我们使用list是因为它的修改的效率非常高，改变一下指针就可以了。而这里我们复制了元素�Q�如果在vector中，可能�q�是高效的，因�ؓvector无论如何都要复制�Q�而对于list��׃��是如此了�Q?strong>会极度降低我们的效率�?/strong>

那我们怎么办呢�Q?/p>

�{�案是��用list自己的remove函数

numbers.remove(1);

我们可以�q�样删除所有��gؓ1的元素�?/p>

也即是说�Q�如果要删除list中的元素�Q?strong>我们应该使用list的remove成员函数�Q�而不是remove��法�Q?/p>

��结

我们都知道，STL是一个效率、复用性、灵�z�L��折��L��产物�Q�其中效率至关重要，所以STL已经��止了一些效率低的操作（比如list的随��问）�Q�而鼓�׃��M��用其它的容器�?/p>

但是�Q?strong>在算法中�Q��ؓ了灵�z�L��，STL�q�是会牺牲一些东�?/strong>�Q�比如我们这个例子�?/p>

个�h觉得�Q�STL作�ؓC++标准库的一个组成部分，特点和C++本��n一模一��P��强大而复杂，有些地方难以理解�Q�很多细节需要学习注意，我们要学会避免陷入某些陷�׃��中，比如�q�个例子��是一个效率陷阱�?/p>

其它更多的陷阱是错误处理斚w��的，STL本��n�q�没有规定过多的错误处理�Q�大部分的错误处理都交给了我们，理由很简单：性能至上�Q�如果一个东西自�w�没有错误检查，我们可以包装一个带错误��查的�c�；但是如果�q�个东西自��n��带了错误检查，那么我们��没有�Q何方法提升它的效率了。这也是很多C和C++库的设计原则�?/p>

所以，很多时候，需要我们深入细�?/strong>�Q�然后再军_��到底怎么做。因为C++��是如此�Q�有很多路可以走�Q�需要我们自己选择最好的一条�\�?/p>

分类: C++

多彩人生 2015-10-14 15:50 发表评论

多彩人生 — Fri, 22 Jun 2012 14:42:00 GMT

shared_from_this()�?enable_shared_from_this的成�? 函数�Q�返回shared_ptr。首先需要注意的是，�q�个函数仅在shared_ptr的构造函数被调用之后才能�? 用。原因是enable_shared_from_this::weak_ptr�q�不在构造函��C��讄��Q�而是在shared_ptr�? 构造函��C��讄��?/span>

如下代码是错误的�Q?

class D:public boost::enable_shared_from_this
{
public:
D()
{
      boost::shared_ptr p=shared_from_this();
}
};
复制代码
�?因很��单，在D的构造函��C��虽然可以保证enable_shared_from_this的构造函数已�l�被调用�Q�但正如前面所 ��_��weak_ptr�q�没有设�|��?

如下代码也是错误的：

class D:public boost::enable_shared_from_this
{
public:
void func()
{
      boost::shared_ptr p=shared_from_this();
}
};
void main()
{
D d;
d.func();
}
复制代码
�?误原因同上�?

如下代码是正��的�Q?

void main()
{
boost::shared_ptr d(new D);
d->func();
}
复制代码
�q?里boost::shared_ptr d(new D)实际上执行了3个动作：首先调用enable_shared_from_this的构造函敎ͼ�其次调用D的构造函敎ͼ�最后调�? shared_ptr的构造函数。是�W?个动作设�|�了enable_shared_from_this�? weak_ptr�Q�而不是第1个动作。这个地�Ҏ��很违背c++常理和逻辑的，必须��心�?

�l�论是，不要在构造函��C��使用shared_from_this�Q�其�ơ，如果要��用shared_ptr�Q�则应该在所有地方均使用�Q�不能��用D d�q�种方式�Q�也决不要传递裸指针�?

另一个值得注意的地�Ҏ��在类的��承树中不能有2个或更多个enable_shared_from_this。例如如下代码是错误的：

class A:public boost::enable_shared_from_this
{
public:
A():a(1){}
virtual ~A(){}
boost::shared_ptr get_ptra(){return shared_from_this();}
int a;
};
class B:public A,public boost::enable_shared_from_this
{
public:
B():b(2){}
boost::shared_ptr get_ptrb()
{
      return boost::enable_shared_from_this::shared_from_this();
}
int b;
};
int _tmain(int argc, _TCHAR* argv[])
{
{
      boost::shared_ptr x(new B);
      boost::shared_ptr a1 = x->get_ptra();
      boost::shared_ptr b1 = x->get_ptrb();
}
return 0;
}
复制代码
�?意上面代码中�Q�B同时拥有2个enable_shared_from_this的基�c�，一个是 enable_shared_from_this�Q�另一个是enable_shared_from_this。在 boost::shared_ptr x(new B);�q�行代码中，shared_ptr的构造函��C��会设�|?个基�c�M��的一个的weak_ptr。在上面的例子中�Q�仅讄�� enable_shared_from_this的。如果修改B的定义�ؓ�Q?

class B:public boost::enable_shared_from_this,public A�Q?

则仅讄��enable_shared_from_this的weak_ptr。很明显都是错误的�?

那么enable_shared_from_this以及shared_ptr��Z��要如此实现呢�Q�又��Z��么会有如此怪异的结果呢�Q?

首先考察shared_ptr的构造函敎ͼ�

template
explicit shared_ptr( Y * p ): px( p ), pn( p ) // Y must be complete
{
boost::detail::sp_enable_shared_from_this( pn, p, p );
}
template void sp_enable_shared_from_this( shared_count const & pn, boost::enable_shared_from_this const * pe, Y const * px )
{
if(pe != 0) pe->_internal_weak_this._internal_assign(const_cast(px), pn);
}
复制代码
�?意这个sp_enable_shared_from_this是一个模板函敎ͼ�而且仅调用了一�ơ，所以不可能2�? enable_shared_from_this基类的weak_ptr都被赋倹{��但问题在于�Q�在调换了B的定义之后结果居然是不一��L��。这里有一个很�? �U�的�~�译器BUG。按道理来说�Q�编译器在编译这�D�代码时�Q�应该注意到无法真正��x��该怎么实例化sp_enable_shared_from_this�q�且报一个错�Q�但vc 2008�q�没有报错，而是通过�~�译了。（g++会在此处报错�Q?

那么正确的解法是怎样的呢�Q?

class B:public A
{
public:
B():b(2){}
boost::shared_ptr get_ptrb()
{
      return boost::dynamic_pointer_cast(shared_from_this());
}
int b;
};
复制代码
�?意到�q�里B�q�没有直接��承enable_shared_from_this�Q�而是使用dynamic_pointer_cast�q�行了类型�{换�?

关于��Z��么enable_shared_from_this是这样实现的�Q�可以参看作者原文：

Every enable_shared_from_this base contains a weak_ptr, The shared_ptr constructor looks up the enable_shared_from_this base and initializes its weak_ptr accordingly. This doesn't work when there are
two or more enable_shared_from_this bases, though.

I could put the weak_ptr in a virtual polymorphic base. This would force polymorphism on all clients of enable_shared_from_this... probably acceptable. It will also force a dynamic_pointer_cast in every
shared_from_this, and this may be harder to swallow, particularly in cases where RTTI is off. So I'm not sure.

If you do want the above behavior, it's easy to duplicate, as I already responded in my first post on the topic. Just make FooB return dynamic_pointer_cast( FooA() ) and remove the enable_shared_from_this
base (A needs to be made polymorphic, of course).

注意��Z��让dynamic_pointer_cast能工作，A必须��h��虚函敎ͼ�那么最��单的做法当然是��o其析构函 ��Cؓ虚函敎ͼ�通常一个class如果希望被��承，析构函数��应该�ؓ虚函敎ͼ��?/div>

多彩人生 2012-06-22 22:42 发表评论

enable_shared_from_this�Q��{载）

多彩人生 — Fri, 22 Jun 2012 14:41:00 GMT

�?C++ 中需要自己来处理内存�Q�稍微处理不当，��׃��存在非常郁闷的内存泄漏问�?

�q�好�Q�现�?C++ 中推��Z��强大的智能指针，�?smart_ptr �Q�本文先�E�微介绍一�?smart_ptr �Q�然后具体说�?shared_ptr �?weak_ptr �Q�特别是 enable_shared_from_this �?shared_from_this

除了标准库中�?auto_ptr 之外

�?boost 或�?tr1 中的 smart_ptr 主要是有下面几种

scoped_ptr
scoped_array
shared_ptr
shared_array
intrusive_ptr
weak_ptr

�q�些里面最隄��解的是综合应用了 weak_ptr �?shared_ptr �?enable_shared_from_this �c�，在该�c�M��定了成员函数 shared_from_this() �Q�返�?shared_ptr 。这个函��C��?shared_ptr 的构造函数被调用之后才能使用。原因是 enable_shared_from_this::weak_ptr �q�不在构造函��C��讄��Q�此处的构造函数指的是�c�d�� T 的构造函敎ͼ��Q�而是�?shared_ptr 的构造函��C��讄��Q�此处的构造函数指的是�c�d�� shared_ptr 的构造函敎ͼ��?

在下面的代码中：

Cpp代码

#include

#include



#include

#include

#include



using namespace std;



struct Ansible

  : public boost::enable_shared_from_this

{

    boost::shared_ptr get_shared()

    {

        boost::shared_ptr r(this);



        return r;

    }



    ~Ansible()

    {

        cout<<"Destructor"<

    }

};



int main(int argc,char* argv[])

{

    boost::shared_ptr a(new Ansible);

    Ansible& r = *a;

    //boost::shared_ptr b = r.get_shared();

    boost::shared_ptr b = r.shared_from_this();



    cout<<"Reference Number "<



    return 0;

}

#include #include #include #include #include using namespace std; struct Ansible : public boost::enable_shared_from_this { boost::shared_ptr get_shared() { boost::shared_ptr r(this); return r; } ~Ansible() { cout<<"Destructor"< a(new Ansible); Ansible& r = *a; //boost::shared_ptr b = r.get_shared(); boost::shared_ptr b = r.shared_from_this(); cout<<"Reference Number "<

若不使用 shared_from_this() 成员函数�Q�则会输�?a �?b �?use_count() 都�ؓ 1 �Q�然后调�?2 �ơ类�?Ansible 的析构函敎ͼ�若添加了该成员函敎ͼ��?a �?b �?use_count() 输出�?2 �Q�只是调用一��?Ansible 的析构函数。原因是 enable_shared_from_this 里面�?shared_ptr 的时候构造了一�?weak_ptr �c�，�?weak_ptr 只是监视�Q�不增加引用计数

�Q�下面是转蝲�Q?http://huyuguang1976.spaces.live.com/blog/cns!2A9E272E3C33AFF1!185.entry �Q?

所以如下代码是错误的：

class D:public boost::enable_shared_from_this

{

public:

    D()

    {

        boost::shared_ptr p=shared_from_this();

    }

};

原因很简单，�?D 的构造函��C��虽然可以保证 enable_shared_from_this 的构造函数已�l�被调用�Q�但正如前面所��_�� weak_ptr �q�没有设�|��?

如下代码也是错误的：

class D:public boost::enable_shared_from_this

{

public:

    void func()

    {

        boost::shared_ptr p=shared_from_this();

    }

};

void main()

{

    D d;

    d.func();

}

错误原因同上�?

如下代码是正��的�Q?

void main()

{

    boost::shared_ptr d(new D);

    d->func();

}

�q�里 boost::shared_ptr d(new D) 实际上执行了 3 个动作：首先调用 enable_shared_from_this 的构造函敎ͼ�其次调用 D 的构造函敎ͼ�最后调�?shared_ptr 的构造函数。是�W?3 个动作设�|�了 enable_shared_from_this �?weak_ptr �Q�而不是第 1 个动作。这个地�Ҏ��很违�?c++ 常理和逻辑的，必须��心�?

�l�论是，不要在构造函��C��使用 shared_from_this �Q�其�ơ，如果要��?shared_ptr �Q�则应该在所有地方均使用�Q�不能��?D d �q�种方式�Q�也决不要传递裸指针�?br />

另解�Q�：�Q�：�Q?br />struct X

{

         boost::shared_ptr getX()

{

         boost::shared_ptr r ;//????如何实现

         return r;

}

};

要得到X的智能指�?只是在对象指针是受shared_ptr保护的基��上的,举例如下:

void test_X()

{

         {

X x;

                  boost::shared_ptr px = x.getX();//错误

}

         {

X* x = new X();

boost::shared_ptr px = x->getX();//错误

}

         {

boost::shared_ptr x (new X());

boost::shared_ptr px = x->getX();//正确

}

}

多彩人生 2012-06-22 22:41 发表评论

关于boost::thread 的一件怪事

多彩人生 — Mon, 14 May 2012 13:50:00 GMT
本想��试printf的线�E�安全的,�l�果发现boost::thread的一件有��的�?见代�?br />
#include <cstdio>
#include <boost/thread.hpp>
#include <boost/bind.hpp>

int fun1()
{
   for(int i=0; i<10; i++)
      printf("哈哈哈哈哈哈\n");
   return 0;
}

int fun2(int count)
{
   for(int i=0; i<count; i++)
      printf("呵呵呵呵呵呵\n");
   return 0;
}

int main()
{
   boost::thread(fun1);     // 不以打印
   boost::thread(fun2, 10); // 可以打印
   boost::thread t(fun1);   // 可以打印

   getchar();
   return 0;
}
不知什么原因，知道的可以告诉我�?img src ="http://www.shnenglu.com/colorful/aggbug/174897.html" width = "1" height = "1" />

多彩人生 2012-05-14 21:50 发表评论