cout << “meetup” << 0;

7 月 11 號 (下週五) 晚上將在台北舉行第 0 次 C++ Otakus and Users in Taipei (簡稱 COUT) 聚會.

COUT 是:

  • A face-to-face community for C++ programmers in northern Taiwan
  • Not aimed at n00bs
    • 畢竟初衷是幾個老屁股想發洩拉賽聚聚
    • 歡迎初心者, 這裡有人可以讓你請教, 可以點你. 但你需要做該做的功課
    • 預計分享的內容大多會是微硬到很硬
  • Monthly meetup
    • 計劃每個月聚會一次
    • 每月的第二個週五 (TBD?)
    • Social + 拉低賽 + 1~2 個主題分享
  • Google+ community

Join us if you are interested.

Boost.Asio – Strand

相較於 libevent, libev, libuv 這三套知名的 asynchronous I/O framework, Boost.Asio 最大的兩個優點是:

  1. Modern C++ support. 其好處之一是 no cast required, 不用犧牲 callback/handler 等的 type safety
  2. Multi-threading support. AFAIK, 前面提到的三個 async framework 都不能以超過一個 worker thread 去 drive 同一個 event loop. 使用這三個 framework 的時候, 一般的建議是以一個 worker thread 對應 一個 event loop. 這當然可以 workaround, 但需要自幹一些東西. 非官方 support 機制的正確性, 效能, scalability 多少會讓使用者有疑慮

不付責任猜測. 或許因為 libevent 與 libev 誕生的年代比較久遠, 而 libuv 的最主要 target user 是 node.js, 所以三者都選擇無視 multi-core/cpu scale-out 的問題.
Continue reading

Concurrent Connection 承載的上限

上個週末在噗浪上參與了關於一台 server 一個 IP 能夠承載多少 inbound connection 的討論. 才發現原來有不少朋友誤以為上限值是 65536 (2^16) 個, 或是雖然覺得這個說法哪裡怪怪的卻又說不出個道理來.

這篇文字的目的是希望可以在網路上留下中文的腳印, 幫助減少這樣的誤解.
Continue reading

On C-Style Cast in C++

Casts in C++

與 C 不同, C++ 提供了五種轉型的方式:

  1. dynamic_cast
  2. static_cast
  3. reinterpret_cast
  4. const_cast
  5. C-style (in syntax) cast

即便這是個每本 C++ 聖經都會說明的題材, 也一定會提醒避免 C-style (in syntax) cast. 實務上, 依然時常看到已有多年經驗的 programmer 會選擇使用 C-style (in syntax) cast. 先破梗一下, 前面一直強調 in syntax 的原因是, 雖然語法相同, C-style cast 在 C++ 中的語意不完全與 C 相同, 前者是後者的 super set. 這篇文字主要試圖說明 C-style (in syntax) cast 在 C++ 中到底是什麼, 以及為什麼避免.
Continue reading

In Code Documentation

在 G+ 河道上看到朋友貼了 cldoc 的連結, 也在 G+ 寫下自己對這類從 source code 以及其中的 annotation 產生文件之工具的看法. 本篇文字基本上為該 post 的中文版.

許多年以前, 我曾經大量使用從 source code 導出使用說明文件的工具, 特別是 Doxygen. 正如其首頁所說的 – “Doxygen is the de facto standard tool for generating documentation from annotated C++ sources”.

一段時間後我放棄了繼續使用這些工具. 我發現這類看似讓作者方便邊寫 code 就順便寫寫文件的工具, 實務上並沒有這麼美好.

就我有限經驗裡的觀察, 寫 code 與寫文件的不見得是同一 (批) 人. 由於做這兩種工作需要腦袋處於不同思考模式以及這兩種工作的產出多為軟體開發流程中不同階段所需, 即便有時作者是同一 (批) 人, 也不會在同一段時間一起進行.

有幾年工作經驗的 programmer 常會有這樣的認知; 只要不傷及可讀性與正確性, 手滑時在 code 或 comment 裏面留下的拼字/文法錯誤是無傷大雅的. 這類無礙的錯誤不見得會被修正, 特別是在 release 之後. 而給使用者看的說明文件可視為產品門面之一, 不太可能也照我們 programmer 的習慣得過且過 (誤). 因此, 我認為邊寫 code 邊寫 (給使用者看的) 文件不是一件 practical 的事情.

最糟糕的是把這類工具被用在 library. 當你為了修正拼字錯誤而的動到用來產生文件的 annotation, 它就是一個 revision. 理論上該出新 build 版號也要往下跳. 可是你要選擇把跳版號出新 build 這件事吃掉? 還是選擇對使用者解釋為何你把文件中的 teh 改成 the, 他們就要重新 compile…

IMHO, 使用 wiki 等專注於內容產生與協同作業 (而非排版美編) 的工具來編寫文件, 比用 editor 與 IDE 更有效也輕鬆多了.