【复习】C++重要知识点

最新推荐文章于 2020-09-02 20:33:42 发布

一零二四bit

最新推荐文章于 2020-09-02 20:33:42 发布

阅读量216

点赞数

分类专栏： C++进阶文章标签： C++ 问答

本文链接：https://blog.csdn.net/qq_41906009/article/details/103439319

版权

C++进阶专栏收录该内容

6 篇文章 0 订阅

订阅专栏

1. 如何解决菱形继承的问题及其内存分布（举例说明）

虚继承为了解决多重继承（像菱形继承）中的二义性与数据冗余问题，维护了一张虚基表；当B类继承A类时，B类对象中会生成一个虚基表指针，指向一张虚基表，表中存放B类中A类对象相较于该位置的偏移量，C类如此。
这样，当出现菱形继承时，D中只存一份A类对象，D类对象中的B类和C类中分别有一张虚基表指针，避免了数据冗余。而只有一份A类，也不存在二义性。

2. 实现多态的方式。

虚表多态分为运行时多态和编译期多态。
运行时多态在C++中主要是通过虚函数实现，即在基类中存在一些接口（一般为纯虚函数），子类必须重载这些接口，这样通过使用基类的指针或引用指向子类的对象，就可以实现调用子类对应的函数的功能；
编译器多态，通过模板实现，宏也是实现静态多态的一种途径。

3. 虚基表与虚表之间的区别

虚继承为了解决多重继承（像菱形继承）中的二义性与数据冗余问题，维护了一张虚基表；
每个有虚函数的类，编译器都会为它生成一张虚表，表中每一个元素都指向一个虚函数的地址。

4. UDP协议与TCP协议的区别：

王者底层是用UDT实现的！！

TCP 是面向连接的（比如打电话前要先拨号确认连接状态）；UDP是无连接的，即发送前不需要建立连接。
TCP提供可靠的服务。也就是说，通过TCP传输的数据，无差错、不丢失、不重复、且按需到达；UDP尽最大努力交付，即不保证可靠交付。
TCP面向字节流，实际上TCP把数据看作一连串无结构的字节流；UDP是面向数据报的，UDP没有拥塞控制，因此网络上出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
每一条TCP连接只能是点对点的；UDP支持一对一、一对多、多对一、多对多的交互通信。
TCP首部开销２０个字节；而UDP首部开销比较小，只要８个字节。
TCP的逻辑通信信道是全双工的可靠信道；UDP则是不可靠信道。

5. 虚函数与纯虚函数的区别

定义一个函数为虚函数，不代表函数为不被实现的函数，是为了允许用基类的指针来调用子类的这个函数；
定义一个函数为纯虚函数，才代表函数没有被实现，是为了一个实现一个接口，起到一个规范的作用，规范继承这个类的程序员必须实现这个函数。

class A{
public:
    virtual void foo()
    {        
     	cout<<"A::foo() is called"<<endl;
    }
};
class B:public A{
public:
    void foo()
    {     
       cout<<"B::foo() is called"<<endl;
    }
};

int main(void)
{
    A *a = new B();
    a->foo();   // 在这里，a虽然是指向A的指针，但是被调用的函数(foo)却是B的!
    return 0;
}

这个例子是虚函数的一个典型应用。
虚函数虚就虚在所谓"推迟联编"或者"动态联编"上，一个类函数的调用并不是在编译时刻被确定的，而是在运行时刻被确定的。
由于编写代码的时候并不能确定被调用的是基类的函数还是哪个派生类的函数，所以被成为"虚"函数。
虚函数只能借助于指针或者引用来达到多态的效果。

参考博客

6. deque的实现原理

STL中deque 是我们常说的双端队列；
既可以从头部添加元素，又可以从尾部添加元素；
deque的成员函数和vector的成员函数十分相近，但他们的内部实现有有很多不同。

总结：

deque在进行内存管理上更复杂；
与vecor相比内存管理更有效，特别是对大量数据的序列，
但我们看见内存在根据我们的需求不断申请，但是没有释放，如果在数据量波动比较大的地方，可能会比较消耗内存。
不过我们可以使用clear函数将内存释放掉，clear考虑到了这个需求。

7. epoll的LT与ET；惊群效应

水平触发Level Triggered 工作模式

epoll默认状态下就是LT工作模式

当epoll检测到socket上事件就绪的时候, 可以不立刻进行处理. 或者只处理一部分.
仍然会立刻返回并通知socket读事件就绪.
直到缓冲区上所有的数据都被处理完, epoll_wait 才不会立刻返回.
支持阻塞读写和非阻塞读写

边缘触发Edge Triggered工作模式

如果我们在将socket添加到epoll描述符的时候使用了EPOLLET标志, epoll进入ET工作模式.

当epoll检测到socket上事件就绪时, 必须立刻处理.
也就是说, ET模式下, 文件描述符上的事件就绪后, 只有一次处理机会.
ET的性能比LT性能更高( epoll_wait 返回的次数少了很多). Nginx默认采用ET模式使用epoll.
只支持非阻塞的读写

selete和poll其实也是工作在LT模式下。epoll即可以支持LT，也可以支持ET。

对比LT和ET

LT是 epoll 的默认行为. 使用 ET 能够减少 epoll 触发的次数. 但是代价就是强逼着程序猿一次响应就绪过程中就把所有的数据都处理完.
相当于一个文件描述符就绪之后, 不会反复被提示就绪, 看起来就比 LT 更高效一些.
但是在 LT 情况下如果也能做到每次就绪的文件描述符都立刻处理, 不让这个就绪被重复提示的话, 其实性能也是一样的.
另一方面，ET代码复杂程度更高了。

８.长连接与短连接

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。
例如：数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。
而像WEB网站的http服务一般都用短连接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知。所以并发量大，但每个用户无需频繁操作情况下需用短连好．

具体网络中的应用：