为了兼容各类编译器，保持对外提供C++接口

flayer

头几天一名网友征询如何用C++中调用CBrother，我发了Demo给他，后果他始终告知我有问题，近程调试了下，发现他在Winows下用的编译器是MinGW，而我公布CBrother的windows版本使用的是VS，后果发现MinGW和VS在关于同名虚接的重载完成不同，调用错了接口地址致使了解体。如斯看来，C++的ABI真是一件让人头疼的事件。
这些年来，C++组委会不断的更新C++特性和语法，把C++搞的花狸狐哨的，也没说把ABI的完成在各个平台上一致一下。
C++尚且如斯，Rust和新出的Carbon还宣称要代替C++，不知道是谁给的勇气。我始终了解一门编程言语的存在指的是这门言语的语法，而不该该是对应的某一套代码。好比说老牌的C和C++其语法不得人心，就会有不同的人根据规范去完成不同的编译器。假定某一天世界上一切言语的编译器和解释器代码都丧失了，我置信C言语一定会有人写出新的编译器，并兼容以前历史上的一切二进制文件接口，那末这些所谓的要代替老先辈的新言语会有报酬它们重写吗？就算写，又如何兼容之前编译器编译的二进制文件接口呢？想要乱拳打死教师傅，这些年老的言语需求斟酌的问题还得多，不仅是简化语法这么简略。他们喊的代替C++的标语，也就是只能圈一波年老粉了。
CBrother降级到v2.5.2
为了兼容一切编译器,默许提供C接口,假如要使用C++接口需求添加 __CBROTHER_CPLUS_PLUS 宏，开源的代码也修正为C接口的反对代码中闲暇的大括号，以前正文掉一个if语句后，过剩的两个大括号会报错，这一点以前无视了新增strascii接口经过下标获得字符串内字符的ascii值CLibFunc反对从一个地址创立函数Xml操作类问题修复，减少了几个接口全局const在module里无奈拜候的