一把菜刀行江湖

使用fdopen可以将pipe文件句柄转化为文件流对象，这样就可以直接使用fgets的按行解析函数

针对一次对于c语言内联函数使用、编译的研究，提出对于在C语言中使用内联函数，无意定义和实现在头文件是最简单的了

积累一些有趣的C语言疑问，在精益求精的场合可以明辨细微

根据最近分析的栈空间可能溢出的问题，提供一个已验证的方法，测算运行程序的栈空间大小

经过一番探索，获得对于哈希表模数选择的新认识，避免对于素数、质数选择的误区

总结一下对于结构体字节对齐的认识，以及计算某个2的幂次长度字节对齐的一种快速方法

笔者分析了C语言如果全部变量都放入全局空间会有什么特点的场景，进行分析和梳理，脱离了要将大部分全局内存都往栈空间、堆空间移动的冲动

通过几个工具的组合，分析C语言程序的程序的内存占用情况，特别是全局变量的内存占用，并提供良好的实践建议

用一段小程序观察linux内存分配的惰性策略，以及谈谈对于内存管理器的潜在影响

尝试从HelloWorld程序对C语言进行以小见大

以前总纠结于字符串最大长度宏定义，到底是否应该包括结束符零，现在理清了逻辑后，觉得原则上应该是不携带的结束符

cppcheck建议作为开发工具链的一部分，适用于c/c++项目工程

困扰了很久的编译日志输出乱码，算是找到了它的原因，就是两个系统间字符集假定的不同

一般人在面对选择继承时都会有点谨慎，但是在ACE优良的框架设计下，你几乎可以达到这样的使用自由。在私有继承和虚函数私有化相对比较合理时，可以尽情选择使用。在两个类关系紧密时，选择私有继承在合适的场景，也是一个合理的选择

根据ACE自适应有锁、无锁场景的模板实现，谈ACE的默认高效实现；兼谈模板的优势，以及宏的优势，两者在C++中都是不可获取的

通过对于std::vector简单模板类的显示实例化实践，总结了在编译框架整体上禁止隐式模板实例化情况下，对于big file特殊地采取隐式模板实例化的策略，以实现自动化

根据使用积累使用内存管理器的优点和缺点，还是非常建议使用的。兼谈ACE框架内存管理器Allocator的使用经验

发现ACE在编译阶段，也是非常高效的，用-pipe编译选项，减少磁盘IO，提高编译效率

用睡眠策略实现生产者和消费者模型的无锁访问，可以提高生产者和消费者的并行度

对于内存池管理，建议直接使用ACE提供的内存管理器，而不必自己写一个，ACE默认实现高效，还是很值得信赖的！增加以分配器形成分配器梯队的思路具有连续内存分配模式的定大小、定长度的分配器，具有连续访问优势

为什么C语言中充满了typedef 结构体类型的语句，找到一种合理说服自己的解释，简写的惯用法使然

调度策略编程应该在多线程编程中拥有一席之地

尝试通过void*指针的例子说透指针，而且通过void二级指针的转化解释指针的精华

对于常用的GDB使用技巧进行总结

对于网络报文处理头尾预留空间的惯用法，ACE_Message_Block类提供了很好支撑，进而感受到ACE C++网络通信框架良好的设计弹性

以前总怀疑程序崩溃的异常堆栈可能不太准确，是否因为及时性的原因，程序还会跑飞一段时间，是否存在随机的可能，如果内存被破坏不是很厉害的情况，异常堆栈的输出将是非常准确的；其它场景，还需要进一步深入分析！

addr2line在使用地址信息不正确的情况下，会输出文号，但实际上在经过一番特殊处理后，还是可以定位到异常代码的行号

总结几年下来在Linux中C语言编程经验，这些指导意见，我想在以后的实践中也会经常用到，所以，总结出来，以利于共享和演进。随后会不断增补中...

扩展了github上比较经典的map实现，使得它可以支持原始的C语言类型作为键值

gdb调试断点命中时，可以加入自动执行的命令，以避免重复手工劳作，以及形成连续打印

看着貌似gcc的O3优化问题，其实源自程序自身结构体定义和使用问题，导致的栈内存被非法写入，进而造成崩溃问题

errno == 1 的错误码很少见，仔细分析下来是因为防火墙的原因。其它安全模块所导致的问题，也有可能暴露此错误

总结网上查阅到的在C语言中使用RAII进行资源管理的方法，但是，感觉用装饰模式更简单

我们在编译自己的```SO```库时，存在两类使用```SO```库的情况，**显式加载**和**隐含加载**如果**显式加载**，则在合适的时机，在自家```SO```库的API执行过程中，需要主动加载依赖```SO```库，并查找函数名称，获取函数指针，然后进行调用。**隐含加载**，在编译自家库的时间，只需要对方的头文件接口```API```，不需要指定```-lsoname```的依赖```SO```库的编译选项；但在自家库被链接成为可执行程序时，则需要指定```-lsoname```，让编

对于#include <.h>与#include ".h"的惯用法#include <*.h>用来包含系统头文件#include "*.h"用来包含自研模块内头文件更精深的区别，则可以在C语言标准中找寻，但也仅是一个框架限制简而言之，#include <.h> 和 #include ".h" 都会在实现定义的位置查找文件，并将其包含。区别是，若 #include ".h" 可以查找成功，则遮蔽 #include <.h> 所能找到

这里写自定义目录标题结论为什么呢？补充{0}花括号清零 VS memset(dst, 0 , sizeof(dst_type))清零============================================================结论在对C语言一个结构体或一块连续内存清零时，如果是在编译时，就可以确定下来类型和大小的内存区域，特别是小块内存，无疑用**{0}花括号清零**，将目标内存清零是最可取的！为什么呢？美学角度char dst[256] = {0};VS

# 编译器+ 能够用最新的编译器版本，就使用最新的编译器版本--> 最新的编译器可以获得更优的代码生成质量和缺陷代码检查提醒# 语言使用## API接口设计+ 注重使用const修饰关键字和C++中的引用语言特性，做API接口参数传递设计++ void f(const XParaPointer*)--> const体现接口参数在调用过程中不会被修改的约束--> 如果在API接口参数设计中，统一使用const进行限定，那么没有携带const关键词的指针参数，则可以被认...

有非常浅薄的应用场景，去简单地使用SIP消息，而OSIP2 SIP协议栈，其开源证书相对友好，又同时支持了解析、构造消息，但无事务层、对话层状态机涉入的可能。简单地使用osip2消息子层sublayer模式如此: / / allocation/release of memory. xxxx_init(osip_xxx_t *...

设计模式是很不错的，可以用来组织代码的结构，以应对变化。在我的理解中，设计模式是做到了更好的，把固定的东西用代码写出来，而用变量来做用于变化的地方。  在通讯领域经常会遇到各种协议的通讯编程，其实在程序结构上类似的双协议栈结构。通讯入口虽然作为程序的入口，但是，在组织代码中，却不能由它来提纲挈领，这样让你的代码比较难以理解，推荐的模式是双协议栈模式，在核心代码区域只处理纯数据，这样也可以使得程

扫描定时器的特性