柳鲲鹏

我只用到erase()，前后还加了锁，每次只删除一个。_M_unhook：顾名思义，该函数的作用是将某个节点从链表中卸下。网上搜索，说是erase()在多线程条件下会崩溃，我是有加锁的。使用了vector，结果崩溃了。一气之下，换用list。

【代码】gcc编译时去掉警告。

【代码】gcc编译时undefined reference to的一种情形。

【代码】C++输出类名。

编译时试图链接/lib/x86_64-linux-gnu/libstdc++.so.6，结果发现有问题。说明要换用gcc的。

当你在子类加了一个与父类同名函数，然后信心满满的调用，结果发现调用的还是父类。再次运行，是不是就正确了？父类可以实现这个函数。

本来好好的用指针，现在多了个shared_ptr，转换为其他类型，就不能直接转了。如果类型不匹配，结果为NULL。不检查类型，出错了你负责。

这几天发现程序工作异常。如果是开机启动，就出错；如果是手工启动，就正常。原因也简单，就是负责创建的进程，还没有正式工作。

由于系统不支持UTF8中文，所以改成了wchar_t。我看了一下字幕，0、2、4不显示，1、2、3显示。后来猜测到是字节对齐问题。0行有两个字节被占用了。原因找到了，就有办法解决。

swprintf和sprintf最大区别，就是swprintf要加个长度限制。

真有牛人提供了解决办法。

这几天调整安装，发现有些文件安装到/lib下。就想复制到安装目录，这样影响更少。然后发现rpaht有问题。修改为当前路径最好。在编译的时候，大多使用$ORIGIN。因为$有特殊含义，所以这里进行了转义。可以看到由编译的绝对路径，变成了相对路径。.或者$ORIGIN。

【代码】CMake为rpath设置相对路径。

上周跟踪崩溃，结论非常奇怪，似乎死在sleep。sleep是正宗系统函数，这个也动不动崩溃，那系统每分钟都要死几次。所以肯定与sleep无关。也就是说，代码在sleep，其他部分还在工作，导致崩溃。那么为什么看起来死在sleep上？

【代码】Could NOT find Threads (missing: Threads_FOUND)

解压后，再配置一下PATH。

经过定位，确认是memcpy(dst, src, strlen(str))这一句出错。这src是产生线程时的参数。我直接把src赋值，就没问题。应用经常崩溃，于是就想转为服务，让系统帮忙重启。这个事情当然信心满满，咱之前做过，最近也刚刚实验过。systemctl start weiyu，然后就卡死在这里。甚至我把main基本清理干净了，还是卡死。目前只能放弃，以后有机会再深入研究。我另外的一个测试程序就完全正常。

这几天接手代码之后，添加了柳氏风格的LOG。昨天检查LOG的时候，发现有的设备会初始化多次。于是研究了代码，使用的是线程初始化，如果中途断线还要一直初始化。仔细想想，这个思路有点问题。怎样确保当前只有一个初始化的工作？指针为NULL，时间大于1，指定间隔后再次初始化。指针为NULL，时间为1，正在初始化；指针不为NULL，表示正常；

试了一下__FILE_NAME__这个宏不能用，怎么办？特意加了括号，保证是个独立体。

【代码】Ubuntu上cJSON下载编译。

这一套代码也是久经考验，一直能用，怎么就报错了？destroy与别的重复。

最近在调试摄像头APP时，发现拔下摄像头时，会卡死。网上搜索了一番，说是在使用之前，使用pthread_detach操作即可。正好看到有人更新了库，其中明确说是解决卡死问题。我对于这个线程问题，一时也有点糊涂，以后专门研究看看。更新代码后试了一下，有所改善。具体有没有解决，存疑。试了之后，并无效果。

在代码中的关键字WEAK， 表示弱定义。

最早接触volatile这个关键字，大约是2000年从JAVA中看到的。大意是说某个变量容易改变，用到的地方多，所以要加。可能取到的不是当前值。当时是非常疑惑的：咱这个变量是一个实例，怎么就可能不是当前值。也就是说，你要正确理解volatile这个关键字的用处，必须从执行的角度。近来学习材料，终于明白了。

红绿两个灯，可以单独点亮、关闭，也可以同时点亮关闭。就是这个延时，写法太愚蠢。

【代码】error LNK2001: 无法解析的外部符号 snprintf。

libusb_open_device_with_vid_pid调用libusb_open。native_uvc_unref_device调用libusb_close。后来就没有再仔细研究了。

增加-Wno-error=deprecated-declarations。具体增加位置看编译脚本。

【代码】warning: incompatible implicit declaration of built-in function ‘memset’

　　泰山OFFICE在任务栏上图标显示正确，在系统监视器中就是系统默认的。这怎么办呢？　　正好另外一个托盘小程序，在系统监视器中显示正确。这就好办了，抄一下。具体代码如下：这个东西搜索了好久，还是在自己代码中发现的，哈哈。

以上，在 C 编译器中不会有的，C 编译器一般不会偷偷插入开发者不知道的指令，你写了什么代码，对应的机器指令和你预期的所差无几。如果一个项目如果对内存和编译后的机器指令做精准控制，那么应该优先选择 C 而不是 C++，C++ 编译器在背后插入了太多的指令。随着 C++ 的不断有新标准出炉，编译器在 C++ 背后做的事情越来越多，相比较而言 C 语言编译器在背后就老实许多。链接：https://www.zhihu.com/question/266995763/answer/2751818359。

有人问，如果我想先执行再判断条件呢？可以使用do/while。这个代码是没有输出的。原因就是先判断条件，符合时再执行。

当n%a时只有a是2的幂函数的值时才能用 & 代替。也就是a = 2^k (k为整数）

编译C，头文件中的宏定义，在别的系统上正常，在另外系统上编译出错。具体宏定义： 原因编译器版本老，不支持新特性。()内的参数不能有##。去掉括号内参数的##，如下：

/usr/bin/ld: udev/udevd.o: in function `static_dev_create_from_modules':/home/quantum6/udev-167/udev/udevd.c:829: undefined reference to `makedev'/usr/bin/ld: udev/udevd.o: in function `is_devpath_busy':/home/quantum6/udev-167/udev/udevd.c:512: undefin.

　　感觉自己哪里都对：库编译通过，位置也对，dlopen()正确打开库，函数名（比如函数名是mainForMac）也正确，结果到了dlsym出错了，怎么回事？原因　　显然，库是c++编译的，实际上函数名在内部已经发行了变化。这个时候mainForMac可能变成了mainForMacZ3之类。当然了，试图使用新的函数名也是错误想法。解决办法　　应该这样声明mainForMac：#ifdef __cplusplusextern "C"{#endifint mainForMac(cons

代码也简单：#include <stdlib.h>#include <stdio.h>void output_number_bin(const int number){ char string[16]; itoa(number, string, 2); printf("%d->%s\n", number, string);}

　　思路：使用strstr，从左向右依次查找，找到最后出现的那个。从右向左找也行（也许更快），实现起来比较麻烦，没有这个易懂。#include <stdio.h>#include <stdlib.h>#include <assert.h>#include <string.h> char* taishan_strrstr(const char *pSrc, const char* pSub){ assert(pSrc); as

　　以为好像发过，没找到。所以重新写一下。技术说明：LOG系列是纯输出 DEBUG/FILE系列除了输出，还写入到文件　　某些情况下输出看不到，或者不方便看，写入文件就是首选。具体用法　　比如你要判断某个函数有没有走到，来一句LOG_HERE();，编译后再测试，就可以看到输出。非常的方便。　　也可以改进一下，增加时间信息。具体代码#ifndef FT_TS_LOG_FILE_NAME#if defined(_WINDOWS) || defined(WIN32)#define

　　最近一段时间，因为加载调用各种本地库，在LINUX/MAC上专门研究了rpath问题。最初是想使用全路径方式，这样也能正确执行，有两个缺点：路径太长，不好维护。 安装路径如果变化，就错了。　　改进办法是什么？就是使用相对路径，这样搜索加载时基于安装目录下的相对路径，就避免了上述问题。那么相对路径是相对于谁？开始以为，位于同一个目录下的库文件，rpath使用.（当前目录）。结果报错说找不到。后来经过实验，结论是：　　rpath搜索相对路径时，是从当前执行文件开始。　　举例来说：安装目录是A