c++名詞解惑#
一腥刹。堆和棧的區(qū)別：
++++++棧：
- FILO
- os自動(dòng)分配釋放贱鼻，函數(shù)參數(shù)宴卖，局部變量等。
- 一級(jí)緩存邻悬， 被調(diào)用時(shí)處于存儲(chǔ)空間中症昏，調(diào)用完畢立即釋放。
- 棧數(shù)據(jù)在多個(gè)線程或者多個(gè)棧之間是不可以共享的父丰，但是在棧內(nèi)部多個(gè)值相等的變量是可以指向一個(gè)地址的肝谭。
++++++堆： - FIFO
- 程序員分配釋放，分配方式類似于列表,全局變量等蛾扇。
- 存放在二級(jí)緩存中攘烛，調(diào)用這些對(duì)象的速度要相對(duì)來(lái)得低一些。
二镀首。RALL：
三坟漱。智能指針：
###############################
為什么是c++#
對(duì)于如何接管內(nèi)存管理, 語(yǔ)言作者們分成了截然不同的兩派
1，垃圾收集更哄，比如java
垃圾收集并不意味著內(nèi)存泄漏成為過(guò)去式, 倒是野指針確實(shí)成為了過(guò)去式, 因?yàn)橹灰€有指針引用一個(gè)對(duì)象, 這個(gè)對(duì)象就絕對(duì)不會(huì)被釋放. (不過(guò), 帶有垃圾收集的語(yǔ)言或多或少都廢除了指針吧, 用引用替代了指針)芋齿。
垃圾收集器的另一個(gè)問(wèn)題是, 除了內(nèi)存, 它無(wú)法對(duì)程序使用的其他資源執(zhí)行垃圾收集. 垃圾收集是以內(nèi)存管理為目標(biāo)產(chǎn)生的, 只能收集不再使用的內(nèi)存, 而不能收集程序使用的其他資源, 如消息列隊(duì), 文件描述符, 共享內(nèi)存, 鎖.等等. 程序員不得不對(duì)其他資源執(zhí)行手工管理, 像 C 程序員那樣小心翼翼的操作.
最終垃圾收集仍然沒(méi)有解決 "人容易犯錯(cuò)" 的問(wèn)題, 還是把其他資源的泄漏問(wèn)題丟給了程序員.
2腥寇，RAII (Resource Acquisition Is Initialization) + 智能指針
C++ 要想實(shí)現(xiàn) RAII + 智能指針, 兩大技術(shù)缺一不可 ：
一. 自動(dòng)確定并調(diào)用 構(gòu)造函數(shù)和析構(gòu)函數(shù)
以 "編譯器自動(dòng)保證對(duì)象生命期" 的技術(shù)依托下, C++ 發(fā)明了 RAII 技術(shù), 將資源的管理變成了對(duì)象的管理
二. 模板
模板的引入使得 RAII 技術(shù)得以 "一次實(shí)現(xiàn)到處使用".
但是, 如果對(duì)象分配于堆上, 程序員不得不手工調(diào)用 delete 刪除對(duì)象.
如果指針也是自動(dòng)對(duì)象就好了.
C++ 標(biāo)準(zhǔn)的第一次嘗試是納入 std::auto_ptr . 但是效果并不好, 不是所有指針都可以為 auto_ptr 所代替. 最要命的是, STL 容器無(wú)法使用 auto_ptr.
C++ 標(biāo)準(zhǔn)的第二次嘗試就是納入了 std::shared_ptr , shared_ptr 在進(jìn)入 C++11 標(biāo)準(zhǔn)之前, 已經(jīng)在 Boost 庫(kù)里實(shí)踐了相當(dāng)長(zhǎng)的時(shí)間.
============結(jié)論============
首先得益于 C++ 的"模板技術(shù)", shared_ptr 只需實(shí)現(xiàn)一次, 即變成可用于任何類型的指針. 其次, 得益于 C++ 的"自動(dòng)生命期管理", 智能指針將需要程序員管理的堆對(duì)象也變成了能利用編譯器自動(dòng)管理的自動(dòng)變量.
也就是, 智能指針徹底的將 delete 關(guān)鍵字 變成了 shared_ptr 才能使用的內(nèi)部技術(shù). 編譯器能自動(dòng)刪除 shared_ptr 對(duì)象, 也就是編譯器能自動(dòng)的發(fā)出 delete 調(diào)用.
模板是智能指針技術(shù)必不可少的一部分, 否則要利用 RAII 實(shí)現(xiàn)智能指針就只能利用 "單根繼承" 這一老土辦法了. 沒(méi)錯(cuò), 這也是 MFC 使用的. ( MFC 誕生在 模板還沒(méi)有加入 C++ 的年代. )
###############################
不選擇python的原因#
lua
llvm-python
go, c之父
perl,bash,awk,python腳本快速簡(jiǎn)單
python缺乏IDE, 各種 profiler static/dymanic analyzer 工具, 缺乏編譯器檢查這種重要的消bug工具,很多人為了找出 bug , 都開(kāi) -Werror 參數(shù)啊觅捆！ 把警告視作錯(cuò)誤,在 C++ 執(zhí)行大量的努力赦役，就是要把 bug 消滅在編譯期的時(shí)候,python 確把編譯這種重要的消bug工具輕輕的丟了,沒(méi)有真正的調(diào)試器。python 沒(méi)有類型檢查,可是運(yùn)行時(shí)經(jīng)常爆出沒(méi)類型檢查導(dǎo)致的各種類型不匹配導(dǎo)致的錯(cuò)誤.更災(zāi)難的事情是栅炒，這種語(yǔ)法上的錯(cuò)誤掂摔，居然是自動(dòng)的變成了面條代碼： 只在控制臺(tái)打印錯(cuò)誤，程序不會(huì)退出赢赊，有些乙漓，有的錯(cuò)誤不會(huì)退出的
,如果是 GUI 程序，經(jīng)常會(huì)發(fā)現(xiàn)各種莫名其妙的功能問(wèn)題域携。prthon-er轉(zhuǎn)投go, c++er 對(duì) go 很冷靜簇秒，因?yàn)橛辛薱++11.
arch shell
debian
還在用plasma 4的distro傻的嗎?
sed
###############################
QT & IOS & Python#
在Windows上都用XAML，他有不同的名字秀鞭，譬如說(shuō)WPF趋观，Silverlight，Metro锋边，Universal等皱坛，都一樣。
偶的大多桌面代碼都是
delphi（c dll）cocoa（osx）
delphi多了跨win osx
在慢慢轉(zhuǎn)qt／qml豆巨，這東西是真跨平臺(tái) 一套代碼哪都跑win linux osx web
python學(xué)web剩辟。熟悉 HTTP 協(xié)議，熟悉 JSON 或 XML往扔，把這個(gè)后端當(dāng)作一個(gè)不輸出 HTML 而輸出 XML / JSON 格式的網(wǎng)站來(lái)做就對(duì)了贩猎。作為ios后端
C和S之間通信協(xié)議多種多樣，如其他知友提到的HTTP萍膛，至于數(shù)據(jù)交換格式也是各種各樣吭服，如json,xml,yaml等，當(dāng)然還有二進(jìn)制的AMF,Protobuf等蝗罗。
現(xiàn)在流行的RESTful的API規(guī)范也可作為進(jìn)階的選擇艇棕。
應(yīng)該看你的app是什么類型的。是需要長(zhǎng)連接的串塑，還是需要短連接多次請(qǐng)求的沼琉。
后端http協(xié)議，后端返回json桩匪，前端解析即可
直接上python + django + django rest, 一條龍服務(wù)
App和服務(wù)端交互其實(shí)跟你用什么語(yǔ)言做后端沒(méi)什么關(guān)系, 無(wú)非就是App發(fā)起請(qǐng)求至服務(wù)端 服務(wù)端返回xml或者Json
python
相反打瘪，使用類似 import item.subitem.subsubitem 這樣的語(yǔ)法時(shí)，這些子項(xiàng)必須是包，最后的子項(xiàng)可以是包或模塊瑟慈，但不能是前面子項(xiàng)中定義的類桃移、函數(shù)或變量。
我想我只會(huì)用mac + github + markdown + sublime/vim寫(xiě)blog了
