<commit_before>libatbus
========

用于搭建高性能、全异步(a)、树形结构(t)的BUS消息系统的跨平台框架库

> Build & Run Unit Test in |  Linux+OSX(clang+gcc) | Windows+MinGW(vc+gcc) |
> -------------------------|--------|---------|
> Status |  [![Build Status](https://travis-ci.org/owt5008137/libatbus.svg?branch=master)](https://travis-ci.org/owt5008137/libatbus) | [![Build status](https://ci.appveyor.com/api/projects/status/xa8jt1gmqkv0n8mi?svg=true)](https://ci.appveyor.com/project/owt5008137/libatbus) |
>

依赖
------
工具依赖： 支持c++0x或c++11的编译器、cmake、msgpack（用于协议打解包）、libuv（用于网络通道）

> 如果本地未安装libuv，请clone 3rd_party/libuv 子模块


Why not c?
------
本来像用纯c写这个组件的，因为纯c比较容易控制结构清晰和代码简洁，但是为什么之后又改用C++了呢？首先一个原因是初期准备使用的协议打解包组件msgpack是c++的；另一方面c++提供了比较简单好用的数据结构容器和内存管理组件，更重要的是这些东西都是原生跨平台的。所以就干脆用C++和C++风格来实现。

*PS:GCC都转依赖C++了我为嘛不能用？*

关于MsgPack
------
本来是想用flatbuffer做协议打解包的，因为使用flatbuffer的话不需要额外引入外部库。
但是实际使用过程中发现flatbuffer使用上问题有点多（比如有地址对齐问题，动态变更数据有缓冲区限制，string类型预分配了过多缓冲区等等）。

相比之下msgpack兼容性，使用容易程度都好很多。另外虽然我没有针对性的测试，但是据说msgpack的性能大约是protobuf的4倍。
而且如果支持c++03/c++11的话也可以使用纯header库，这是一大优势。当然它和protobuf一样存在打包和解包过程所以性能会低于flatbuffer，而且数据维护比较裸露不像protobuf采用了很多COW和ZeroCopy的技术。解包后的逻辑内存结构也会比较大。
但是考虑到在本lib中的应用，消息体的结构非常简单，并且附加信息很少，所以这些因素的影响都不是很大，反而CPU消耗和平台移植性显得更重要一些。


注意
------
为了代码尽量简洁（特别是少做无意义的平台兼容），依赖部分 C11和C++11的功能，所以不支持过低版本的编译器：
+ GCC: 4.4 及以上（建议gcc 4.8.1及以上）
+ Clang: 3.0 及以上 （建议 clang 3.4及以上）<commit_msg>add gitter<commit_after>libatbus
========

用于搭建高性能、全异步(a)、树形结构(t)的BUS消息系统的跨平台框架库

> Build & Run Unit Test in |  Linux+OSX(clang+gcc) | Windows+MinGW(vc+gcc) |
> -------------------------|--------|---------|
> Status |  [![Build Status](https://travis-ci.org/owt5008137/libatbus.svg?branch=master)](https://travis-ci.org/owt5008137/libatbus) | [![Build status](https://ci.appveyor.com/api/projects/status/xa8jt1gmqkv0n8mi?svg=true)](https://ci.appveyor.com/project/owt5008137/libatbus) |
>

Gitter
------
[![Gitter](https://badges.gitter.im/owt5008137/libatbus.svg)](https://gitter.im/owt5008137/libatbus?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)

依赖
------
工具依赖： 支持c++0x或c++11的编译器、cmake、msgpack（用于协议打解包）、libuv（用于网络通道）

> 如果本地未安装libuv，请clone 3rd_party/libuv 子模块


Why not c?
------
本来像用纯c写这个组件的，因为纯c比较容易控制结构清晰和代码简洁，但是为什么之后又改用C++了呢？首先一个原因是初期准备使用的协议打解包组件msgpack是c++的；另一方面c++提供了比较简单好用的数据结构容器和内存管理组件，更重要的是这些东西都是原生跨平台的。所以就干脆用C++和C++风格来实现。

*PS:GCC都转依赖C++了我为嘛不能用？*

关于MsgPack
------
本来是想用flatbuffer做协议打解包的，因为使用flatbuffer的话不需要额外引入外部库。
但是实际使用过程中发现flatbuffer使用上问题有点多（比如有地址对齐问题，动态变更数据有缓冲区限制，string类型预分配了过多缓冲区等等）。

相比之下msgpack兼容性，使用容易程度都好很多。另外虽然我没有针对性的测试，但是据说msgpack的性能大约是protobuf的4倍。
而且如果支持c++03/c++11的话也可以使用纯header库，这是一大优势。当然它和protobuf一样存在打包和解包过程所以性能会低于flatbuffer，而且数据维护比较裸露不像protobuf采用了很多COW和ZeroCopy的技术。解包后的逻辑内存结构也会比较大。
但是考虑到在本lib中的应用，消息体的结构非常简单，并且附加信息很少，所以这些因素的影响都不是很大，反而CPU消耗和平台移植性显得更重要一些。


注意
------
为了代码尽量简洁（特别是少做无意义的平台兼容），依赖部分 C11和C++11的功能，所以不支持过低版本的编译器：
+ GCC: 4.4 及以上（建议gcc 4.8.1及以上）
+ Clang: 3.0 及以上 （建议 clang 3.4及以上）
{'fraction_non_alphanumeric': 0.18087676907145323, 'fraction_numerical': 0.03727994477045219, 'mean_word_length': 6.646437994722955, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 13, 'https://': 10, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1230539', 'n_tokens_mistral': 1984, 'n_tokens_neox': 2159, 'n_words': 90}