re: 好玩的Go語言[未登錄] eXile 2010-01-14 21:40
@陳梓瀚(vczh)
google不可憐，可憐的是網(wǎng)民。
re: 好玩的Go語言 eXile 2010-01-14 10:49
@bluegene
這是想借助開源社區(qū)的力量，比如現(xiàn)在已經(jīng)有人在做Windows 的移植，以及數(shù)據(jù)庫的客戶端，還有人在討論GUI的設(shè)計。對于老外來說，開源只會太遲，不會太早。
re: 好玩的Go語言 eXile 2010-01-14 10:43
@陳梓瀚(vczh)
Go接口的實(shí)現(xiàn)可能是這樣的，假設(shè)函數(shù)定義的形參類型為Myinterface，而實(shí)際調(diào)用的實(shí)參類型為A，所編譯器會對A生成一個關(guān)于Myinterface的方法表，這樣，實(shí)參的值并不是一個簡單的對象指針，而是對象指針再加上方法表的首地址。
re: 好玩的Go語言 eXile 2010-01-13 11:30
吊詭的是，go語言的官方網(wǎng)站我在Windows下不能訪問，但在Linux下可正常訪問
re: 好玩的Go語言 eXile 2010-01-13 11:27
@陳梓瀚(vczh)
1）編譯分析是根據(jù)包packege來進(jìn)行的，一個類的函數(shù)必須定義在一個包中，但可以在不同的文件中。
2）interface有顯式繼承，當(dāng)然也是以嵌入的形式。我也想到了C++的concept，但是Go接口又具有動態(tài)特性。
3）Go具有和C一樣的ABI，一樣的類型，一樣的結(jié)構(gòu)布局，所以從Go調(diào)用C很容易，但是，因?yàn)橛蠫C，所以不支持從C調(diào)用Go。
4）超快的編譯速度，無論是Go還是D語言，對c/c++的一個很大的不滿就是編譯太慢，當(dāng)然不會再出現(xiàn)這個問題。庫是二進(jìn)制的。Go目前有兩套編譯器，其中一個編譯器gccgo的目標(biāo)是和gcc二進(jìn)制兼容。
5）Go語言的庫都是用Go語言來寫的，個人感覺很好讀，代碼量也少得多，每個庫也就是一兩個實(shí)現(xiàn)文件，是學(xué)習(xí)Go的最好途徑。
re: 好玩的Go語言 eXile 2010-01-13 00:09
說到開發(fā)效率, 在服務(wù)器領(lǐng)域，Go絕對優(yōu)于Java，C++，就不用提了。
re: 好玩的Go語言 eXile 2010-01-13 00:05
@陳梓瀚(vczh)
不需要提前聲明估計最根本的原因是為了簡化編譯器的開發(fā)吧?
不是這么簡單。這是Go語言與其它面向?qū)ο笳Z言的最大不同。舉個例子就明白了，
type MyInterface interface { func doIt() } // 接口
type A struct {}
func (self *A) doIt() {} // 指針
type B struct {}
func (b B) doIt() {} //值
type C struct { A } // 嵌入
則A， B，C 都實(shí)現(xiàn)了MyInterface接口，也就都是MyInterface類型。沒有繼承，沒有顯式說明，靜態(tài)綁定。Go把它稱之為“最令人激動的事情之一” 不是沒有道理的。
re: 好玩的Go語言 eXile 2010-01-12 21:13
關(guān)于為什么沒有繼承，官方FAQ是這么說的：它簡化了類之間的關(guān)系，不再有復(fù)雜的類型體系。接口的隱式風(fēng)格，使一個類型不需要提前聲明，就可以一次滿足多個接口，同時又沒有傳統(tǒng)的多重繼承的復(fù)雜性——“這種風(fēng)格需要一段時間來適應(yīng)，但這是Go語言最令人激動的事情之一”。
re: 好玩的Go語言 eXile 2010-01-12 18:04
@陳梓瀚(vczh)
面向?qū)ο蟮膬蓷l重要原則：1.面向接口編程，而不是面向?qū)崿F(xiàn)編程 2 優(yōu)先使用組合而不是繼承， 這在別的語言中只不過是口頭約定，而在Go語言中，你則不得不這樣做。
re: 好玩的Go語言 eXile 2010-01-12 17:31
@陳梓瀚(vczh)
如果可能的話，把相同的代碼提取出來，組成一個新類或新函數(shù)，再組合進(jìn)去。或者，使用一個代理類。我覺得利用嵌入還是比較好解決這個問題的。
re: 好玩的Go語言 eXile 2010-01-12 13:16
是的，畢竟Go沒有繼承，沒有虛函數(shù)，它沒有子類和父類的概念，所有的指針都視為不同的類型。但是，對于Go語言來說，接口不是指針，這是它和其它語言的不同。如果要多態(tài)，就應(yīng)該使用接口，而不是具體的類。
這里只提出一個實(shí)現(xiàn)思路，不再提供源代碼，請各位見諒。
用google的TCMalloc 直接替換malloc實(shí)現(xiàn)
myuml是作者開發(fā)的嗎，似乎還不錯，很輕量，界面也還可以。試用了一下，還是有些需要改進(jìn)。比如，新建一個方法，過程太繁瑣，其實(shí)可以直接輸入：method(arg1:int, arg2:int):int，然后解析出它的參數(shù)和返回值，而不需要一個一個控件在那點(diǎn)半天。另外為什么發(fā)布的是DEBUG版的？
tr1是支持Express的，不過也是要Express SP1
lambda是個令人欣喜的特性，至于右值引用，可以極大地提高標(biāo)準(zhǔn)庫的效率，但是對一般的程序員沒有什么太大影響，不好理解的話，就當(dāng)它不存在好了。
基本概念錯誤，LZ應(yīng)該了解一下什么是函數(shù)類型，什么是函數(shù)指針類型，他們之間的區(qū)別和轉(zhuǎn)化。
Windows下可以，只用于線程的叫critical_section
re: ifstream與CFile的效率 eXile 2009-05-19 12:07
800K的文件，要七秒，286也不至于吧
@螞蟻終結(jié)者
BOOST_FOREACH 的那陀實(shí)現(xiàn)。。。還是算了吧
@空明流轉(zhuǎn)
確實(shí)，沒有l(wèi)ambda之前，for_each沒什么意思。不過好消息是VC2010將會支持lambda.
@OwnWaterloo
謝謝提醒，RANDOM_VAR的定義確實(shí)不對，要改成你說的樣子.
不過你說的加大括號或者foreach_helper加container引用的辦法，是不行的。
至于，為什么使用下劃線開頭，正是因?yàn)檫@種命名方法不常用，所會才會避免偶然和其它變量重名的情況，一般也就是僅限于宏中使用。
這個也要用boost?
template <class T,int N>
inline const int array_size(T (&x)[N]) {
return N;
}
在實(shí)用主義覆蓋一切角落的國度，人們都會變得鼠目寸光。
re: 智能指針LytPtr eXile 2009-03-21 01:49
bool operator==(_Type* Temp)const
實(shí)現(xiàn)中有個小bug
不是做web開發(fā)，而是本地桌面應(yīng)用集成WEB服務(wù)。另外，現(xiàn)在很多本地應(yīng)用實(shí)際上都是用網(wǎng)頁來做界面。
re: 智能指針的代碼實(shí)例 eXile 2009-03-09 17:18
ＩＣＥ中的實(shí)現(xiàn)吧，這個并沒有解決循環(huán)引用的問題。所以他還有一個GCShared
re: 編輯器近況 eXile 2009-02-25 22:12
不錯啊，不過我覺得Notepad++確實(shí)挺好用的，SciTE也不錯，更省資源。
字符串匹配我前兩天剛好找了一個正向的boyer moore horspool算法，不過沒有深究。Notepad++是開源的，里面應(yīng)該有類似實(shí)現(xiàn)。
re: wxwidgets使用之后的一些感覺 eXile 2009-02-09 02:21
wx一直標(biāo)榜的最大的優(yōu)點(diǎn)就是原生界面，其實(shí)我覺得這反而是一個缺點(diǎn)，就拿你說的這個例子，要擴(kuò)展一個組件就很麻煩。而在QT中，使用MVC架構(gòu)很容易實(shí)現(xiàn)一個復(fù)雜的 treelist。
你說的換膚功能，在QT中只需要編寫CSS就可以了，不需要自己編程實(shí)現(xiàn)。
另外，使用原生組件并不一定就比自繪組件性能占優(yōu)，反而有時候在不同的平臺下出現(xiàn)不一樣的界面布局，調(diào)整起來也很麻煩。
re: 自己造的一個線程類 eXile 2009-01-19 14:13
Win32最好不要使用CreateThread, 使用 _beginthreadex
re: 用Google Docs寫博客 eXile 2009-01-15 13:43
一個不太好的消息：Google將關(guān)閉在線筆記本
筆記本將不再吸收新用戶，現(xiàn)有用戶將只能通過網(wǎng)站訪問，而沒有瀏覽器擴(kuò)展。
用戶的在線狀態(tài)，簡單一點(diǎn)，直接保存在內(nèi)存中，復(fù)雜一點(diǎn)，保存在共享內(nèi)存中
那這個IShape把所有的接口都設(shè)計好了，按名創(chuàng)建就行了。
這用不到RTTI。
所謂反射應(yīng)該是這樣的，有一個公共類Object, 使用如下：
Object* object = createByName(“Circle”);
object->invoke("draw");
原來你的需求是這樣的，一般的工廠模式解決的就是這個問題。
C++的反射功能是很弱的，一般而言，都是通過序列化來支持?jǐn)?shù)據(jù)成員的構(gòu)造，如果你還要支持成員函數(shù)(也就是你說的未知類），那就由強(qiáng)類型系統(tǒng)變成了弱類型系統(tǒng)。這個最好還是結(jié)合一個成熟的腳本系統(tǒng)來做吧，比如python等。我推薦Qt, 你可以通QtScript來使用JavaScript，配置文件可以通過Json。
看來確實(shí)是這樣的，只有定義，是不會加載內(nèi)存的，只有在實(shí)際使用時，才會加載。編譯優(yōu)化不太可能。
@bug
會生成多份的，這和類的靜態(tài)變量是不一樣的
@飄雪
靜態(tài)全局變量是不用的，它的作用域只是該文件，聲明沒有意義
re: 再次批判 裘宗燕 eXile 2009-01-05 21:06
大學(xué)教授譯書，都是老家伙掛個名，然后找一幫學(xué)生翻的
如果使用的是SGI STL或者STLPort，那么這種優(yōu)化意義不大，因?yàn)镾GI STL的實(shí)現(xiàn)已經(jīng)考慮了對于POD的優(yōu)化（通過typetraits來判斷是否為POD，然后使用mem*函數(shù)） 。
提高vector性能可從兩方面考慮：
1）使用特定內(nèi)存池，實(shí)現(xiàn)一個Allocator, 利用vector 的第二個模板參數(shù)。這也是提高STL容器性能的常規(guī)辦法。
2）此處成為性能瓶頸，是不是系統(tǒng)設(shè)計方面有什么問題？可以從整個系統(tǒng)優(yōu)化的角度來考慮。
上面有些錯誤：
QSignalMapper* map = new QSignalMapper(this);
connect(button0, SIGNAL(clicked()), map, SLOT(map()));
connect(button1, SIGNAL(clicked()), map, SLOT(map()));
map->setMapping(button0, 0);
map->setMapping(button1, 1);
connect(map, SIGNAL(mapped(int)), this, SIGNAL(numberClicked(int)));