Re: [討論] 為什麼不要用c++寫網站

※ 引述《Lordaeron (Terry)》之銘言：
: CGI 這東西，看了這麼多人回，都沒人講出來，表示這邊的都是高手了。
: 資O會，以前某套內部的系統是CGI 當底的，後面接的是C。
其實也沒有那麼陌生，經歷過php, Rails時代的人都有被cgi折磨過

只不過現代server side都轉向JavaEE那個樣子，類似Asp.net那樣依附個CGI還是
蠻少見的。
現代的web無論是spring還是go那邊都是走向自己從network connection開始管。
（我知道Spring有內置Tomcat）

: 所以, 在這種基本上是I/O bound 的工作面前，用以CPU bound 為強項的語言。
: 是不是大材小用了?
其實C/C++這種可以編譯爲native code的還是快，但是一般的編寫方式用用不上。
網路連線其實沒有那麼burst的，一堆時間都在idle，不然poll(), coroutines發明
出來做什麼。也畢竟是HTTP/2以前的連線非常沒有效率，每段msg，先是廢話一堆。
gRPC也只是把header的廢話個壓縮掉。

這也是爲什麼有javascript來拉json這樣的東西出現，web中一堆沒有用的資料都是
css這樣的東西，真實有用的資料用類似out of band的手段丟一丟還比較快。

就算這個protocol進化到gRPC protobuf那麼沒有浪費，抱歉現在的socket編程根本
跳不開CPU copy，從Transport layer過來那邊kernel給你copy到userspace去，
然後reply的時候又userspace 給copy到kernel去包一包。

我前一段時間想弄個VPN程式看到這邊都要吐血了，是有DMA方案啦，DPDK。
沒幾個平臺支援，想要部署到Android或者iOS都不可能。

: 但當我看到它每一個取char * 傳進來的字串長度是用sizeof 時，就該明白....讚啦。: 還好它只是檢查它長度是否大於0。
native code的東西對這種memory boundary就很煩，有debug的人會發現，比如在
一個64bits memory的OS上，兩個32bits變數我只watch一個，結果旁邊variable
動一下，我這邊給拉起來。

string判斷size一不小心沒有null terminator就crash了，string類的function
用之前一定要看看有沒有n version, strnlen()就解決問題了沒有？

在ptt這樣不支援UTF-8的可沒有這種好事。
Jave就沒有這種煩惱了，也沒有Pass by reference這樣這的煩惱。

寫C++的時候要經常看看是不是move還是copy這種屁事.

: 推 alihue: 推，其實現代 jvm 速度已經沒有那麼慢了 06/20 08:24: → superpandal: jvm佔用記憶體阿 外加某些工具啟動龜速 運作也馬乎也 06/20 10:05: → superpandal: 沒什麼優勢 06/20 10:06ART講記憶體處理不好是還可以，GraalVM就沒這個問題了
至於ready time這個您有load過一堆c++ libraries，要處理symbols也很慢
: 推 brucetu: c++ compile真的是很耽誤開發 06/20 11:10: 推 tsaigi: sizeof XDDD 很有畫面 06/20 12:35: 推 qwe78971: 確實 每次compile 也超耗時 06/20 13:51C還好，C++真是痛苦，template每次展開都是毀天滅地般的時間。
還好有更糟的rust

--
你比較喜歡哪一個?
當年不是黨國大老但是被江浙財團捧紅的中國帥哥
跟同樣擁兵一方的諸侯約會裁軍結果半途諸侯們爽約，平常有在寫日記的莊嚴男人開始發飆在旁邊讀著荒漠甘泉冷眼旁觀看著薔薇戰爭的人，為了中國的事情爭吵
別國調侃是不是中國總統，義正詞嚴的說著我是民族的燈塔的威嚴老先生

--

好是好，擴展蠻麻煩的。 kernel中不能隨便spin lock的，一個deadlock真的全世界陪葬

(u)int32_t其實在PC/Server這樣的地方用，或者需要定義fixed length的data structure 都是沒有問題的。 但是麻煩還是不要都用32bits，int的意義在於一般都是compiler設定效能最佳化到最好的 data type。stm8也是這樣講，就算int在這個8bits MCU上是32bits長。 至於爲什麼不用更大的data type來存資料比較保險，就有一個paramter pass的問題， 特別是CISC的暫存器又少，大一點就要堆到memory中去了

web不是只有Java EE，26的Bilibili的Go洩露事件，說明Go使用比人想象的廣 另外我的工作和IO蠻有關係的，怎麼不能評論

Android一票公司，當然web方面甚至說涉及到網路程式都是spring一本道