C++的虚拟继承

43.明智地使用多继承。 多继承带来了极大的复杂性。最主要的一条就是二义性。 当派生类为多继承时，其多个基类有同名的成员时，就会出现二义性。通常要明白其使用哪个成员的。显式地限制修饰成员不仅非常笨拙，并且会带来限制。当显式地用一个类名来修饰一个虚函数时，函数就会被固定，而不再具有虚拟的特性。对于虚函数，若两个基类拥有一个同名同參的虚函数，当派生类没有又一次定义虚函数时（能够仅仅声明），...

class.cpp class A { public:     virtual ~A() {}     virtual void f() = 0;// { std::cout     virtual void h() { std::cout     void g() { std::cout     int a; }; class B : public A { publ

虚拟继承在一般的应用中很少用到，所以也往往被忽视，这也主要是因为在C++中，多重继承是不推荐的，而一旦离开了多重继承，虚拟继承就完全失去了存在的必要 （因为这样只会降低效率和占用更多的空间，实在是一无是处）。　　以下面的一个例子为例：　　#include <iostream.h>　　#include <memory.h>　　class CA　　{　　 int k; //...

移植qt4.8.6到海思hi3536芯片

在海思3536芯片上用QT4.8.6开发界面。GUI程序是一个窗体，在终端里用命令行启动，指令形如xxxx -qws，然后点击小叉关闭窗体，窗体消失，但终端里的命令行指令并不返回，用ps查看发现进程没有退出。而相同的代码使用pc上的qt库编译，在pc上是可以正常关闭的，因此推测这个问题与qws相关。通过对main函数的调试发现，进程不结束是卡在了QApplication的析构函数里。这个程序的工程

        正在研究JetsonTX2，目的是开发一个图像采集模块。按照L4T的文档说明改写了板卡自带摄像头模块的dtsi文件，在板子上重编内核生成了Image文件和dts文件夹。到此为止一切顺利，然后按照文档说明更新内核和dtb之后，意想不到的问题发生了。文档介绍的更新内核方法，是将Image复制到板卡的/boot目录下覆盖同名文件，将dts文件夹中的dtb文件复制到/boot/dtb目录下...

题目里的意思说起来有点儿绕嘴。其实是这么个事：在QMenu里添加了很多QAction项，每项都使能了check，就是前面可以加上小勾勾那种。假如要勾上QAction1的小勾勾、勾掉QAction2的小勾勾，按照Qt默认的操作，要先点开QMenu的下拉菜单，点QAction1，这时下拉菜单消失了，需要再点开下来菜单去点QAction2。这就比较麻烦了对不对？这还只是两个QAction，要是搞十几个QAction，就问你烦不烦？我想实现个什么功能呢，就是点开下拉菜单，在我修改小勾勾时候菜单不消失，改完了在下拉菜

官方编译参考：https://caffe2.ai/docs/getting-started.html?platform=windows&configuration=compile 官方的安装指导不全面，留了很多坑，不把坑填了会导致编译失败，本文的主要目的在于填坑，官方文档里说过的内容就不再详细介绍了。 一、下载源码 git clone --recursive https://gith

添加头文件#include ，在代码中调用QWSServer::setBackground(QColor(0,0,0,0));

首先准备好从nvidia官网下载的文件系统，然后解压。把该文件系统内/usr/lib/arm-linux-gnueabihf文件夹拷贝到主机根目录并保持相对目录结构，把该文件系统内/lib/arm-linux-gnueabihf文件夹拷贝到主机根目录并保持相对目录结构。使用NSight打开cuda-toolkit-6-0自带的例程，在工程设置中将目标平台改为ARM，将路径中的x86_64字样修改为

 cvNamedWindow和cvDestroyWindow必须在同一个线程下使用，否则销毁窗体时会产生内存泄露，窗体并不会被真正释放，虽然此时窗体已经不见了。当你再次创建同名窗体时你会发现并没有窗体显示出来，而且在使用vc调试时，关闭程序时会产生内存泄露警告。就这么简单，that's all！