摘要: lua的VM執行代碼是從lvm.c中的void luaV_execute(lua_State *L)開始：Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->void luaV_execute (lua_State *L)&n...
閱讀全文
posted @
2012-09-19 12:34 airtrack 閱讀(7205) |
評論 (5) |
編輯 收藏C的NULL
在C語言中，我們使用NULL表示空指針，也就是我們可以寫如下代碼：
int *i = NULL;
foo_t *f = NULL;
實際上在C語言中，NULL通常被定義為如下：
#define NULL ((void *)0)
也就是說NULL實際上是一個void *的指針，然后吧void *指針賦值給int *和foo_t *的指針的時候，隱式轉換成相應的類型。而如果換做一個C++編譯器來編譯的話是要出錯的，因為C++是強類型的，void *是不能隱式轉換成其他指針類型的，所以通常情況下，編譯器提供的頭文件會這樣定義NULL：
#ifdef __cplusplus
#define NULL 0
#else
#define NULL ((void *)0)
#endif
C++的0
因為C++中不能將void *類型的指針隱式轉換成其他指針類型，而又為了解決空指針的問題，所以C++中引入0來表示空指針，這樣就有了類似上面的代碼來定義NULL。實際上C++的書都會推薦說C++中更習慣使用0來表示空指針而不是NULL，盡管NULL在C++編譯器下就是0。為什么C++的書都推薦使用0而不是NULL來表示空指針呢？我們看一個例子：
在foo.h文件中聲明了一個函數：
void bar(sometype1 a, sometype2 *b);
這個函數在a.cpp、b.cpp中調用了，分別是：
a.cpp:
bar(a, b);
b.cpp:
bar(a, 0);
好的，這些代碼都是正常完美的編譯運行。但是突然在某個時候我們功能擴展，需要對bar函數進行擴展，我們使用了重載，現在foo.h的聲明如下：
void bar(sometype1 a, sometype2 *b);
void bar(sometype1 a, int i);
這個時候危險了，a.cpp和b.cpp中的調用代碼這個時候就不能按照期望的運行了。但是我們很快就會發現b.cpp中的0是整數，也就是在overload resolution的時候，我們知道它調用的是void bar(sometype1 a, int i)這個重載函數，于是我們可以做出如下修改讓代碼按照期望運行：
bar(a, static_cast<sometype2 *>(0));
我知道，如果我們一開始就有bar的這兩個重載函數的話，我們會在一開始就想辦法避免這個問題（不使用重載）或者我們寫出正確的調用代碼，然而后面的這個重載函數或許是我們幾個月或者很長一段時間后加上的話，那我們出錯的可能性就會加大了不少。貌似我們現在說道的這些跟C++通常使用0來表示空指針沒什么關系，好吧，假設我們的調用代碼是這樣的：
foo.h
void bar(sometype1 a, sometype2 *b);
a.cpp
bar(a, b);
b.cpp
bar(a, NULL);
當bar的重載函數在后面加上來了之后，我們會發現出錯了，但是出錯的時候，我們找到b.cpp中的調用代碼也很快可能忽略過去了，因為我們用的是NULL空指針啊，應該是調用的void bar(sometype1 a, sometype2 *b)這個重載函數啊。實際上NULL在C++中就是0，寫NULL這個反而會讓你沒那么警覺，因為NULL不夠“明顯”，而這里如果是使用0來表示空指針，那就會夠“明顯”，因為0是空指針，它更是一個整形常量。
在C++中，使用0來做為空指針會比使用NULL來做空指針會讓你更加警覺。
C++ 11的nullptr
雖然上面我們說明了0比NULL可以讓我們更加警覺，但是我們并沒有避免這個問題。這個時候C++ 11的nullptr就很好的解決了這個問題，我們在C++ 11中使用nullptr來表示空指針，這樣最早的代碼是這樣的，
foo.h
void bar(sometype1 a, sometype2 *b);
a.cpp
bar(a, b);
b.cpp
bar(a, nullptr);
在我們后來把bar的重載加上了之后，代碼是這樣：
foo.h
void bar(sometype1 a, sometype2 *b);
void bar(sometype1 a, int i);
a.cpp
bar(a, b);
b.cpp
bar(a, nullptr);
這時候，我們的代碼還是能夠如預期的一樣正確運行。
在沒有C++ 11的nullptr的時候，我們怎么解決避免這個問題呢？我們可以自己實現一個（《Imperfect C++》上面有一個實現）：
const
class nullptr_t
{
public:
template<class T>
inline operator T*() const
{ return 0; }
template<class C, class T>
inline operator T C::*() const
{ return 0; }
private:
void operator&() const;
} nullptr = {};
雖然這個東西被大家討論過很多次了，但是我覺得還是有必要再討論一下，畢竟在C++ 11還沒有普及之前，我們還是應該知道怎么去避免問題，怎么很快的找到問題。
posted @
2012-09-16 01:08 airtrack 閱讀(18111) |
評論 (3) |
編輯 收藏接上一篇：lua源碼剖析（一）
詞法分析
lua對與每一個文件(chunk)建立一個LexState來做詞法分析的context數據，此結構定義在llex.h中。詞法分析根據語法分析的需求有當前token，有lookahead token，LexState結構如圖：
其中token結構中用int存儲實際token值，此token值對于單字符token(+ - * /之類)就表示自身，對于多字符(關鍵字等)token是起始值為257的枚舉值，在llex.h文件中定義：
#define FIRST_RESERVED 257
/*
* WARNING: if you change the order of this enumeration,
* grep "ORDER RESERVED"
*/enum RESERVED {
/* terminal symbols denoted by reserved words */ TK_AND = FIRST_RESERVED, TK_BREAK,
TK_DO, TK_ELSE, TK_ELSEIF, TK_END, TK_FALSE, TK_FOR, TK_FUNCTION,
TK_GOTO, TK_IF, TK_IN, TK_LOCAL, TK_NIL, TK_NOT, TK_OR, TK_REPEAT,
TK_RETURN, TK_THEN, TK_TRUE, TK_UNTIL, TK_WHILE,
/* other terminal symbols */ TK_CONCAT, TK_DOTS, TK_EQ, TK_GE, TK_LE, TK_NE, TK_DBCOLON, TK_EOS,
TK_NUMBER, TK_NAME, TK_STRING
};
token結構中還有一個成員seminfo，這個表示語義信息，根據token的類型，可以表示數值或者字符串。
lex提供函數luaX_next和luaX_lookahead分別lex下一個token和lookahead token，在內部是通過llex函數來完成詞法分析。
語法分析
lua語法分析是從lparser.c中的luaY_parser開始：
Closure *luaY_parser (lua_State *L, ZIO *z, Mbuffer *buff,
Dyndata *dyd, const char *name, int firstchar) {
LexState lexstate;
FuncState funcstate;
Closure *cl = luaF_newLclosure(L, 1); /* create main closure */
/* anchor closure (to avoid being collected) */
setclLvalue(L, L->top, cl);
incr_top(L);
funcstate.f = cl->l.p = luaF_newproto(L);
funcstate.f->source = luaS_new(L, name); /* create and anchor TString */
lexstate.buff = buff;
lexstate.dyd = dyd;
dyd->actvar.n = dyd->gt.n = dyd->label.n = 0;
luaX_setinput(L, &lexstate, z, funcstate.f->source, firstchar);
mainfunc(&lexstate, &funcstate);
lua_assert(!funcstate.prev && funcstate.nups == 1 && !lexstate.fs);
/* all scopes should be correctly finished */
lua_assert(dyd->actvar.n == 0 && dyd->gt.n == 0 && dyd->label.n == 0);
return cl; /* it's on the stack too */
}
此函數創建一個closure并把LexState和FuncState初始化后調用mainfunc開始parse，其中FuncState表示parse時函數狀態信息的，如圖：
每當parse到一個function的時候都會建立一個FuncState結構，并將它與所嵌套的函數通過prev指針串聯起來，body函數就是完成嵌套函數parse。
static void body (LexState *ls, exposed *e, int ismethod, int line) {
/* body -> `(' parlist `)' block END */
FuncState new_fs;
BlockCnt bl;
new_fs.f = addprototype(ls);
new_fs.f->linedefined = line;
open_func(ls, &new_fs, &bl);
checknext(ls, '(');
if (ismethod) {
new_localvarliteral(ls, "self"); /* create 'self' parameter */
adjustlocalvars(ls, 1);
}
parlist(ls);
checknext(ls, ')');
statlist(ls);
new_fs.f->lastlinedefined = ls->linenumber;
check_match(ls, TK_END, TK_FUNCTION, line);
codeclosure(ls, e);
close_func(ls);
}
FuncState中的f指向這個函數的Proto，Proto中保存著函數的指令、變量信息、upvalue信息等其它信息，Proto的結構如圖：
k指向一個這個Proto中使用到的常量，code指向這個Proto的指令數組，Proto **p指向這個Proto內部的Proto列表，locvars存儲local變量信息，upvalues存儲upvalue的信息，cache指向最后創建的closure，source指向這個Proto所屬的文件名，后面的size*分別表示前面各個指針指向的數組的大小，numparams表示固定的參數的個數，is_vararg表示這個Proto是否是一個變參函數，maxstacksize表示最大stack大小。
FuncState中的ls指向LexState，在LexState中有一個Dyndata的結構，這個結構用于保存在parse一個chunk的時候所存儲的gt label list和label list以及所有active變量列表，其中gt label list存儲的是未匹配的goto語句和break語句的label信息，而label list存儲的是已聲明的label。待出現一個gt label的時候就在label list中查找是否有匹配的label，若出現一個label也將在gt label list中查找是否有匹配的gt。
LuaY_parser調用mainfunc開始parse一個chunk：
static void mainfunc (LexState *ls, FuncState *fs) {
BlockCnt bl;
expdesc v;
open_func(ls, fs, &bl);
fs->f->is_vararg = 1;
/* main function is always vararg */ init_exp(&v, VLOCAL, 0);
/* create and */ newupvalue(fs, ls->envn, &v);
/* set environment upvalue */ luaX_next(ls);
/* read first token */ statlist(ls);
/* parse main body */ check(ls, TK_EOS);
close_func(ls);
}
在mainfunc中通過open_func函數完成對進入某個函數進行parse之前的初始化操作，每parse進一個block的時候，將建立一個BlockCnt的結構并與上一個BlockCnt連接起來，當parse完一個block的時候就回彈出最后一個BlockCnt結構。BlockCnt結構中的其它變量的意思是：nactvar表示這個block之前的active var的個數，upval表示這個block是否有upvalue被其它block訪問，isloop表示這個block是否是循環block。mainfunc中調用statlist，statlist調用statement開始parse語句和表達式。
statement分析語句采用的是LL(2)的遞歸下降語法分析法。在statement里面通過case語句處理各個帶關鍵字的語句，在default語句中處理賦值和函數調用的分析。語句中的表達式通過expr函數處理，其處理的BNF如下：
exp ::= nil | false | true | Number | String | ‘...’ | functiondef |
prefixexp | tableconstructor | exp binop exp | unop exp
expr函數調用subexpr函數完成處理。
static BinOpr subexpr (LexState *ls, expdesc *v, int limit) {
BinOpr op;
UnOpr uop;
enterlevel(ls);
uop = getunopr(ls->t.token);
if (uop != OPR_NOUNOPR) {
int line = ls->linenumber;
luaX_next(ls);
subexpr(ls, v, UNARY_PRIORITY);
luaK_prefix(ls->fs, uop, v, line);
}
else simpleexp(ls, v);
/* expand while operators have priorities higher than `limit' */
op = getbinopr(ls->t.token);
while (op != OPR_NOBINOPR && priority[op].left > limit) {
expdesc v2;
BinOpr nextop;
int line = ls->linenumber;
luaX_next(ls);
luaK_infix(ls->fs, op, v);
/* read sub-expression with higher priority */
nextop = subexpr(ls, &v2, priority[op].right);
luaK_posfix(ls->fs, op, v, &v2, line);
op = nextop;
}
leavelevel(ls);
return op; /* return first untreated operator */
}
當分析exp binop exp | unop exp的時候lua采用的是算符優先分析，其各個運算符的優先級定義如下：
static const struct {
lu_byte left; /* left priority for each binary operator */
lu_byte right; /* right priority */
} priority[] = { /* ORDER OPR */
{6, 6}, {6, 6}, {7, 7}, {7, 7}, {7, 7}, /* `+' `-' `*' `/' `%' */
{10, 9}, {5, 4}, /* ^, .. (right associative) */
{3, 3}, {3, 3}, {3, 3}, /* ==, <, <= */
{3, 3}, {3, 3}, {3, 3}, /* ~=, >, >= */
{2, 2}, {1, 1} /* and, or */
};
#define UNARY_PRIORITY 8 /* priority for unary operators */
代碼生成
lua代碼生成是伴隨著語法分析進行的，指令類型Instruction定義在llimits.h中：
/*
** type for virtual-machine instructions
** must be an unsigned with (at least) 4 bytes (see details in lopcodes.h)
*/
typedef lu_int32 Instruction;
Instruction是一個32位的整形數據，其中0~5 bits表示optype，6~13 bits參數A，14~22 bits表示參數B，23~31 bits表示參數C，14~31 bits表示參數Bx或sBx，6~31 bits表示參數Ax。
代碼生成的函數聲明在lcode.h中，以luaK開頭，這一系列的函數大多都有expdesc *v的參數，expdesc的結構定義在lparser.h，如下：
typedef struct expdesc {
expkind k;
union {
struct { /* for indexed variables (VINDEXED) */
short idx; /* index (R/K) */
lu_byte t; /* table (register or upvalue) */
lu_byte vt; /* whether 't' is register (VLOCAL) or upvalue (VUPVAL) */
} ind;
int info; /* for generic use */
lua_Number nval; /* for VKNUM */
} u;
int t; /* patch list of `exit when true' */
int f; /* patch list of `exit when false' */
} expdesc;
expdesc中的t和f分別表示表達式為true和false時，待回填跳轉指令的下標。k表示表達式的類型，u表示對應類型的數據。
代碼生成過程中根據表達式類型做相應的代碼生成操作，lua中每個函數最大有250個寄存器，表達式的計算就是選擇這些寄存器存放并生成數據，而寄存器的下標是在代碼生成階段選擇好的，寄存器的釋放是根據變量和表達式的生命周期結束的時候釋放。代碼生成過程會將變量的生命周期的起始pc和結束指令pc分別存放在Proto中的LocVar的startpc和endpc里面，供調試使用。
posted @
2012-08-12 17:28 airtrack 閱讀(8604) |
評論 (0) |
編輯 收藏很早就想讀lua的源碼，也曾很多次瀏覽過大概。不過我一直沒有深入去讀，一是想自己在讀lua源碼之前，僅憑自己對lua使用的理解自己先實現一個簡單的lua子集，二是我覺得自己實現過lua的子集之后也能幫助自己更容易的理解lua源碼。前段時間，花了幾個月的業余時間，實現了一個簡單粗糙的lua子集（https://github.com/airtrack/luna）之后，我覺得現在可以開始讀lua的源碼了。
從lua.c的main函數開始，lua.c是一個stand-alone的解釋器，編譯完就是一個交互式命令行解釋器，輸入一段lua代碼，然后執行并返回結果，也可以執行一個lua文件。
main:
/* call 'pmain' in protected mode */
lua_pushcfunction(L, &pmain);
lua_pushinteger(L, argc); /* 1st argument */
lua_pushlightuserdata(L, argv); /* 2nd argument */
status = lua_pcall(L, 2, 1, 0);
result = lua_toboolean(L, -1); /* get result */
main函數創建了lua_State之后就按照調用C導出給lua函數的方式調用了pmain函數。pmain函數中通過lua棧獲取到命令行的argc和argv參數之后，對參數進行分析后，主要可以分為兩個分支，一個處理交互命令行，一個處理文件。dotty出來交互命令行，handle_script處理lua文件。
handle_script:
status = luaL_loadfile(L, fname);
lua_insert(L, -(narg+1));
if (status == LUA_OK)
status = docall(L, narg, LUA_MULTRET);
else
lua_pop(L, narg);
在handle_script中先loadfile，然后docall。
loadfile會產生一個什么東西在棧上呢？寫過lua的程序的人估計都會了解到下面這段lua代碼：
local f = load(filename)
f()
load會將文件chunk編譯成一個function，然后我們就可以對它調用。如果我們詳細看lua文檔的話，這個函數可以帶有upvalues，也就是這個函數其實是一個閉包（closure）。按照我自己實現的那個粗糙的lua子集的方式的話，每個運行時期的可調用的lua函數都是閉包。
#define luaL_loadfile(L,f) luaL_loadfilex(L,f,NULL)
luaL_loadfilex:
if (filename == NULL) {
lua_pushliteral(L, "=stdin");
lf.f = stdin;
}
else {
lua_pushfstring(L, "@%s", filename);
lf.f = fopen(filename, "r");
if (lf.f == NULL) return errfile(L, "open", fnameindex);
}
if (skipcomment(&lf, &c)) /* read initial portion */
lf.buff[lf.n++] = '\n'; /* add line to correct line numbers */
if (c == LUA_SIGNATURE[0] && filename) { /* binary file? */
lf.f = freopen(filename, "rb", lf.f); /* reopen in binary mode */
if (lf.f == NULL) return errfile(L, "reopen", fnameindex);
skipcomment(&lf, &c); /* re-read initial portion */
}
if (c != EOF)
lf.buff[lf.n++] = c; /* 'c' is the first character of the stream */
status = lua_load(L, getF, &lf, lua_tostring(L, -1), mode);
luaL_loadfile是一個宏，實際是luaL_loadfilex函數，在luaL_loadfilex函數中，我們發現是通過調用lua_load函數實現，lua_load的函數原型是：
LUA_API int lua_load (lua_State *L, lua_Reader reader, void *data, const char *chunkname, const char *mode);
定義在lapi.c中，它接受一個lua_Reader的函數并把data作為這個reader的參數。在luaL_loadfilex函數中傳給lua_load作為reader是一個static函數getF，getF通過fread讀取文件。
lua_load:
ZIO z;
int status;
lua_lock(L);
if (!chunkname) chunkname = "?";
luaZ_init(L, &z, reader, data);
status = luaD_protectedparser(L, &z, chunkname, mode);
在函數lua_load中，又將lua_Reader和data通過luaZ_init函數把數據綁定到ZIO的結構中，ZIO是buffered streams。之后調用luaD_protectedparser，此函數定義在ldo.c中，在這個函數中，我們發現它使用了構造lua_Reader和data的方式構造了調用函數f_parser和它的數據SParser，并將它們傳給luaD_pcall，luaD_pcall的功能是在protected模式下用SParser數據調用f_parser函數，因此我們只需追蹤f_parser函數即可。
luaD_protectedparser:
status = luaD_pcall(L, f_parser, &p, savestack(L, L->top), L->errfunc);
f_parser:
if (c == LUA_SIGNATURE[0]) {
checkmode(L, p->mode, "binary");
cl = luaU_undump(L, p->z, &p->buff, p->name);
}
else {
checkmode(L, p->mode, "text");
cl = luaY_parser(L, p->z, &p->buff, &p->dyd, p->name, c);
}
f_parser通過數據頭的signature來判斷讀取的數據是binary還是text的，如果是binary的數據，則調用luaU_undump來讀取預編譯好的lua chunks，如果是text數據，則調用luaY_parser來parse lua代碼。我們發現luaU_undump和luaY_parser函數的返回值都是Closure *類型，這個剛好就和我們前面預計的一樣，一個chunk load之后返回一個閉包。
進入luaY_parser函數后，就調用了一個static的mainfunc開始parse lua代碼。
仔細回顧上面看過的函數，我們會發現每個C文件的導出函數都會使用lua開頭，如果沒有lua開頭的函數都是static函數。并且我們會發現lua后的大寫前綴可以標識這個函數所屬的文件：
luaL_loadfile luaL_loadfilex L應該是library的意思，屬于lauxlib
luaD_protectedparser luaD_pcall D是do的意思，屬于ldo
luaU_undump U 是undump的意思，屬于lundump
luaY_parser Y 是代表yacc的意思，lua的parser最早是用過yacc生成的，后來改成手寫，名字也保留下來，屬于lparser
其它的lua函數也都有這個規律。
posted @
2012-07-19 18:24 airtrack 閱讀(12551) |
評論 (3) |
編輯 收藏vimer、emacser的優越感
曾幾何時，剛學編程沒多久，網上看到一群“牛人”吹噓說世界上有三種編輯器：一種是vim，一種是emacs，一種是其它。
當時看到各種介紹vim和emacs的文章都是頂禮膜拜的，希望自己哪天也能成為那種能玩的動“神器”。一直是水平不夠或者其它原因，沒學會。3年多前看到一個vim的視頻，當時下狠心終于把vim學會了，當然有之前一兩年斷斷續續學vim的基礎的幫助。自從學會了vim之后我也加入到了vimer行列，終于學會了“神器”編輯器。終于可以在別人討論其它編輯器的時候回復一句裝逼的“vimer飄過”的語句。前輩們是說vim、emacs高效，因為你學會了之后，你的手不需要離開主鍵盤區域。其實在我看來這完全不是理由，其它編輯器的各種快捷鍵同樣能夠保證你不離開主鍵盤區域完成編輯功能，只不過普通編輯器不會強迫你學習快捷鍵，而vim和emacs是你必須學會快捷鍵才能夠使用。這時“牛人”也許會說vim和emacs都有超強的定制性，可以定制你想要的“任何”功能。看起來是很牛逼的，vim和emacs是有不少很強力的插件，可以把它們定制的很強力，但是要說到“任何”那也只是停留在理論上。C++自動提示功能始終都是vim和emacs的痛，幸好有了clang，自動提示能力終于上了一個檔次，但是那流暢程度和VA比起來還是要差一點，畢竟是基于單個文件分析（每次改動都會重新分析整個文件），不像VA那樣是整個工程分析。至于C++的重構功能，到現在vim和emacs都沒有很好的實現，不要說重構在C++里面沒有用，至少我覺得rename和extract method還是很有用的。vim和emacs其實沒有牛人吹噓的那么神奇，當然它們確實是很優秀的編輯器。最近一段時間我在減少使用vim，是因為經常敲擊ctrl鍵導致左手小指有時會疼痛。這個問題也許會在emacser上面更加嚴重，emacser都是迫切需要“腳踏板”的。
vimer和emacser的優越感是從前輩“牛人”那里聽來，費勁力氣學會，終于可以對沒學會的人來上一句“你的編輯器是其它”產生的。
蘋果系的優越感
蘋果的產品通常比一般的產品有著更貴的價格，通常用戶體驗比起一般的產品也確實要好，這往往成為某些裝逼人事的裝逼利器。當一部分人用上了“先進”的蘋果產品，開始寫各種文章炫耀蘋果的優越性，比起其它怎么怎么好，使得很多沒有試用過蘋果產品的人心生向往，費盡力氣也要體驗體驗。當這些人費盡力氣使用了蘋果的產品后，有很大一部分人自然的覺得自己用上了高端的產品，往往產生優越感。有不少使用Macbook Pro的人說使用Macbook Pro再也沒有關過機，什么東西都是合上就走，并以此產生對Windows的優越感，說Windows是不可能做到。然而我身邊就有一個同事使用thinkpad，裝的是Windows XP，而他的機器一年都是沒關過機，都是合上就走的，這更別說Windows 7了。我自己從去年開始使用Macbook air，剛開始使用第一周死過一次機，后來也出現過一次死機。我覺得Macbook air是不錯，但是還不至于說甩開其它產品幾條街，讓人產生強烈的優越感。
使用蘋果系的人產生優越感往往是因為自己付出了比較大的一部分資金后，看到產品的不少優點之后就開始無視對于其它產品的缺點，從而產生一種高貴的優越感。
Linux程序員的優越感
有不少Linux程序員，覺得自己是Linux程序員能干不少牛逼的事，能看到優秀的源碼。就連調用系統調用都能產生優越感，說Linux的系統調用簡單明了，比起Windows的API來說簡單。這當然是個優點，但這就能讓人產生優越感。而往往即懂Windows又懂Linux的人的卻能夠更好更正確的認識各個系統的優缺點。我了解到一些Linux程序員會產生優越感，有不少是曾今學習Windows編程，發現自己沒能學好（往往是學習GUI編程沒學好），然后看到很多網上牛人都使用Linux，然后轉移到Linux潛心學習，編寫命令行程序，終于修煉成功，之后就開始噴Windows多么不好，進而產生優越感。
C程序員的優越感
C程序員的優越感的產生有點類似Linux程序員，而往往C程序員也就是Linux程序員。有了Linux的優越感之后，更加的認為只要有Linux和C就能解決所有問題，只要比C更復雜的東西都是不值得的。而這些C程序員自然而然的把優越感產生建立在C++之上，而且是這個也是有一定的相似性，也是帶著C的思維學習C++，發現不少C++的東西不是按照他想象的那樣運作之后，就開始鄙視C++最終又回歸為C，而往往也產生對C++程序員的優越感。不過再我看來，如果能夠成為一個優秀的C++程序員，你讓他回去寫C代碼，他同樣能夠寫出優秀的C代碼來。C程序員的優越感其實有些可悲，往往是自己短視，可以不喜歡不使用一種語言，但是這完全不是產生優越感的理由。
技術等級的優越感
一般公司都有技術等級之分，高級工程師一般工作經驗比普通工程師要豐富一點，抑或是在某些方面比較擅長。而他們對待普通工程師的時候往往產生一種“我什么都應該比普通工程師懂的優越感”，跟普通工程師討論問題的時候往往帶著一種高級工程師的優越感，覺得普通工程師的各個方面都不如自己的感覺，因而形成一種嚴格的等級制度，時間長了之后就變成了一種“文化”。這種優越感似乎是有傳遞性的，等那些普通工程師終于熬成高級之后也開始對后來的普通工程師產生優越感。
還有其它不少情況很多人會對某些人某些東西產生優越感，這種優越感的產生一般都是因為付出了更多的某樣東西之后，自然的對事物的分級而產生，覺得自己的層級更高一點，自然而然的產生了優越感。當這種優越感開始在一定范圍內開始傳播之后，對于某些曾今不能體會到優越感的人同樣付出了更多的某樣東西之后，像病毒式的也感染了這種優越感。使得這種優越感一直往下傳遞。
最近發現身邊和網上不少這種優越感案例，有感而發，寥寥幾筆。
posted @
2012-05-15 19:17 airtrack 閱讀(4217) |
評論 (21) |
編輯 收藏
摘要: BitWave的Host：
源碼放在github上，采用NEW BSD LICENSE發布。地址：https://github.com/airtrack/bitwave
閱讀全文
posted @
2011-05-29 17:39 airtrack 閱讀(4690) |
評論 (8) |
編輯 收藏用Lua也有大半年了，從用Lua開始就想寫個Lua調試器，不過由于種種原因沒寫，這周上班抽了點時間寫了（我承認上班偷懶了，不過多是休息時間）。（點此下載）
Lua本身沒有提供調試器，不過它自帶了一個debug庫，提供了基本的變量值獲取和代碼執行hook，有了這些基本功能要寫一個調試器不難。
此調試器根據調試方式分為normal、step in、step over、next line四種mode，分別對應斷點、步進、跳出函數、執行下行的功能。斷點類型分為行斷點和函數斷點，分別在執行到相應行和相應函數的時候斷下。在斷下的時候就可以打印和修改變量，通過建立一個新的chunk并將環境設置成相應函數的環境，再執行chunk來獲取和修改變量。
因為是命令行的，在命令行還沒有機會添加斷點的時候，要添加斷點就要通過debugger.addfuncbreak和debugger.addlinebreak來添加函數和行斷點，通常Lua是用于C++的腳本語言，因此程序通常是有一個可以直接執行Lua腳本指令的入口，這樣的入口就可以打下第一個斷點，這樣在斷下斷點后就可以在命令提示符下做所有的操作了。
代碼是上班抽時間寫的，寫的很隨意，也沒多少注釋，權當玩具吧。目前的功能基本能滿足我的要求了，也不打算繼續改進了。調試器是用來幫助找錯誤，不要過分依賴調試器。Robert C. Martin說Debuggers are a wasteful Timesink。雖說有些偏激，但是不無道理。
posted @
2011-01-01 01:44 airtrack 閱讀(4802) |
評論 (3) |
編輯 收藏