目前項(xiàng)目在不停的增長，我想還是在它規(guī)模仍舊很小的時(shí)候把它的模塊分清楚，不同模塊分到不同的
projects
里面，這里面出現(xiàn)了很多問題，也反映了我知識上的很多不足。
1
，
project
最后的輸出要設(shè)置清楚，有的是
static lib
，有的是
dll
，有的是
exe
，不一樣的輸出要設(shè)置好，它們都是
linker
的成果，但是以不同的方式應(yīng)用。
2
，
project dependency
設(shè)置好，
build order
什么的，通過這些把一系列的
project
聯(lián)系起來。
3
，
project
之間的聯(lián)系就通過之間的
lib
，
dll
來聯(lián)系，這時(shí)候就涉及到
linker
的工作了。
?
許多
Visual C++
的使用者都碰到過
LNK2005:symbol already defined
和
LNK1169:one or more multiply defined symbols found
這樣的鏈接錯(cuò)誤，而且通常是在使用第三方庫時(shí)遇到的。對于這個(gè)問題，有的朋友可能不知其然，而有的朋友可能知其然卻不知其所以然，那么本文就試圖為大家徹底解開關(guān)于它的種種疑惑。
大家都知道，從
C/C++
源程序到可執(zhí)行文件要經(jīng)歷兩個(gè)階段
:
(1)
編譯器將源文件編譯成匯編代碼，然后由匯編器
(assembler)
翻譯成機(jī)器指令
(
再加上其它相關(guān)信息
)
后輸出到一個(gè)個(gè)目標(biāo)文件
(object file, VC
的編譯器編譯出的目標(biāo)文件默認(rèn)的后綴名是
.obj)
中；
(2)
鏈接器
(linker)
將一個(gè)個(gè)的目標(biāo)文件
(
或許還會有若干程序庫
)
鏈接在一起生成一個(gè)完整的可執(zhí)行文件。
???
編譯器編譯源文件時(shí)會把源文件的全局符號
(global symbol)
分成強(qiáng)
(strong)
和弱
(weak)
兩類傳給匯編器，而隨后匯編器則將強(qiáng)弱信息編碼并保存在目標(biāo)文件的符號表中。那么何謂強(qiáng)弱呢？編譯器認(rèn)為函數(shù)與初始化了的全局變量都是強(qiáng)符號，而未初始化的全局變量則成了弱符號。比如有這么個(gè)源文件
:
extern int errorno;
int buf[2] = {1,2};
int *p;
int main()
{
?? return 0;
}
其中
main
、
buf
是強(qiáng)符號，
p
是弱符號，而
errorno
則非強(qiáng)非弱，因?yàn)樗皇莻€(gè)外部變量的使用聲明。
有了強(qiáng)弱符號的概念，我們就可以看看鏈接器是如何處理與選擇被多次定義過的全局符號
:
規(guī)則
1:
不允許強(qiáng)符號被多次定義
(
即不同的目標(biāo)文件中不能有同名的強(qiáng)符號
)
；
規(guī)則
2:
如果一個(gè)符號在某個(gè)目標(biāo)文件中是強(qiáng)符號，在其它文件中都是弱符號，那么選擇強(qiáng)符號；
規(guī)則
3:
如果一個(gè)符號在所有目標(biāo)文件中都是弱符號，那么選擇其中任意一個(gè)；
???
由上可知多個(gè)目標(biāo)文件不能重復(fù)定義同名的函數(shù)與初始化了的全局變量，否則必然導(dǎo)致
LNK2005
和
LNK1169
兩種鏈接錯(cuò)誤?？墒?，有的時(shí)候我們并沒有在自己的程序中發(fā)現(xiàn)這樣的重定義現(xiàn)象，卻也遇到了此種鏈接錯(cuò)誤，這又是何解？嗯，問題稍微有點(diǎn)兒復(fù)雜，容我慢慢道來。
???
眾所周知，
ANSI C/C++
定義了相當(dāng)多的標(biāo)準(zhǔn)函數(shù)，而它們又分布在許多不同的目標(biāo)文件中，如果直接以目標(biāo)文件的形式提供給程序員使用的話，就需要他們確切地知道哪個(gè)函數(shù)存在于哪個(gè)目標(biāo)文件中，并且在鏈接時(shí)顯式地指定目標(biāo)文件名才能成功地生成可執(zhí)行文件，顯然這是一個(gè)巨大的負(fù)擔(dān)。所以
C
語言提供了一種將多個(gè)目標(biāo)文件打包成一個(gè)文件的機(jī)制，這就是靜態(tài)程序庫
(static library)
。開發(fā)者在鏈接時(shí)只需指定程序庫的文件名，鏈接器就會自動到程序庫中尋找那些應(yīng)用程序確實(shí)用到的目標(biāo)模塊，并把
(
且只把
)
它們從庫中拷貝出來參與構(gòu)建可執(zhí)行文件。幾乎所有的
C/C++
開發(fā)系統(tǒng)都會把標(biāo)準(zhǔn)函數(shù)打包成標(biāo)準(zhǔn)庫提供給開發(fā)者使用
(
有不這么做的嗎？
)
。
???
程序庫為開發(fā)者帶來了方便，但同時(shí)也是某些混亂的根源。我們來看看鏈接器是如何解析
(resolve)
對程序庫的引用的。
在符號解析
(symbol resolution)
階段，鏈接器按照所有目標(biāo)文件和庫文件出現(xiàn)在命令行中的順序從左至右依次掃描它們，在此期間它要維護(hù)若干個(gè)集合
:
(1)
集合
E
是將被合并到一起組成可執(zhí)行文件的所有目標(biāo)文件集合；
(2)
集合
U
是未解析符號
(unresolved symbols
，比如已經(jīng)被引用但是還未被定義的符號
)
的集合；
(3)
集合
D
是所有之前已被加入到
E
的目標(biāo)文件定義的符號集合。一開始，
E
、
U
、
D
都是空的。
鏈接器的工作過程：
(1):
對命令行中的每一個(gè)輸入文件
f
，鏈接器確定它是目標(biāo)文件還是庫文件，如果它是目標(biāo)文件，就把
f
加入到
E
，并把
f
中未解析的符號和已定義的符號分別加入到
U
、
D
集合中，然后處理下一個(gè)輸入文件。
(2):
如果
f
是一個(gè)庫文件，鏈接器會嘗試把
U
中的所有未解析符號與
f
中各目標(biāo)模塊定義的符號進(jìn)行匹配。如果某個(gè)目標(biāo)模塊
m
定義了一個(gè)
U
中的未解析符號，那么就把
m
加入到
E
中，并把
m
中未解析的符號和已定義的符號分別加入到
U
、
D
集合中。不斷地對
f
中的所有目標(biāo)模塊重復(fù)這個(gè)過程直至到達(dá)一個(gè)不動點(diǎn)
(fixed point)
，此時(shí)
U
和
D
不再變化。而那些未加入到
E
中的
f
里的目標(biāo)模塊就被簡單地丟棄，鏈接器繼續(xù)處理下一輸入文件。
(3):
如果處理過程中往
D
加入一個(gè)已存在的符號
，或者當(dāng)掃描完所有輸入文件時(shí)
U
非空，鏈接器報(bào)錯(cuò)并停止動作。否則，它把
E
中的所有目標(biāo)文件合并在一起生成可執(zhí)行文件。
??? VC
帶的編譯器名字叫
cl.exe
，它有這么幾個(gè)與標(biāo)準(zhǔn)程序庫有關(guān)的選項(xiàng)
: /ML
、
/MLd
、
/MT
、
/MTd
、
/MD
、
/MDd
。這些選項(xiàng)告訴編譯器應(yīng)用程序想使用什么版本的
C
標(biāo)準(zhǔn)程序庫。
/ML(
缺省選項(xiàng)
)
對應(yīng)單線程靜態(tài)版的標(biāo)準(zhǔn)程序庫
(libc.lib)
；
/MT
對應(yīng)多線程靜態(tài)版標(biāo)準(zhǔn)庫
(libcmt.lib)
，此時(shí)編譯器會自動定義
_MT
宏；
/MD
對應(yīng)多線程
DLL
版
(
導(dǎo)入庫
msvcrt.lib
，
DLL
是
msvcrt.dll)
，編譯器自動定義
_MT
和
_DLL
兩個(gè)宏。后面加
d
的選項(xiàng)都會讓編譯器自動多定義一個(gè)
_DEBUG
宏，表示要使用對應(yīng)標(biāo)準(zhǔn)庫的調(diào)試版，因此
/MLd
對應(yīng)調(diào)試版單線程靜態(tài)標(biāo)準(zhǔn)庫
(libcd.lib)
，
/MTd
對應(yīng)調(diào)試版多線程靜態(tài)標(biāo)準(zhǔn)庫
(libcmtd.lib)
，
/MDd
對應(yīng)調(diào)試版多線程
DLL
標(biāo)準(zhǔn)庫
(
導(dǎo)入庫
msvcrtd.lib
，
DLL
是
msvcrtd.dll)
。雖然我們的確在編譯時(shí)明白無誤地告訴了編譯器應(yīng)用程序希望使用什么版本的標(biāo)準(zhǔn)庫，可是當(dāng)編譯器干完了活，輪到鏈接器開工時(shí)它又如何得知一個(gè)個(gè)目標(biāo)文件到底在思念誰？為了傳遞相思，我們的編譯器就干了點(diǎn)秘密的勾當(dāng)。在
cl
編譯出的目標(biāo)文件中會有一個(gè)專門的區(qū)域
(
關(guān)心這個(gè)區(qū)域到底在文件中什么地方的朋友可以參考
COFF
和
PE
文件格式
)
存放一些指導(dǎo)鏈接器如何工作的信息，其中有一種就叫缺省庫
(default library)
，這些信息指定了一個(gè)或多個(gè)庫文件名，告訴鏈接器在掃描的時(shí)候也把它們加入到輸入文件列表中
(
當(dāng)然順序位于在命令行中被指定的輸入文件之后
)
。說到這里，我們先來做個(gè)小實(shí)驗(yàn)。寫個(gè)頂頂簡單的程序，然后保存為
main.c :
/* main.c */
int main() { return 0; }
用下面這個(gè)命令編譯
main.c(
什么？你從不用命令行來編譯程序？這個(gè)
......) :
cl /c main.c
/c
是告訴
cl
只編譯源文件，不用鏈接。因?yàn)?/span>
/ML
是缺省選項(xiàng)，所以上述命令也相當(dāng)于
: cl /c /ML main.c
。如果沒什么問題的話
(
要出了問題才是活見鬼！當(dāng)然除非你的環(huán)境變量沒有設(shè)置好，這時(shí)你應(yīng)該去
VC
的
bin
目錄下找到
vcvars32.bat
文件然后運(yùn)行它。
)
，當(dāng)前目錄下會出現(xiàn)一個(gè)
main.obj
文件，這就是我們可愛的目標(biāo)文件。隨便用一個(gè)文本編輯器打開它
(
是的，文本編輯器，大膽地去做別害怕
)
，搜索
"defaultlib"
字符串，通常你就會看到這樣的東西
: "-defaultlib:LIBC -defaultlib:OLDNAMES"
。啊哈，沒錯(cuò)，這就是保存在目標(biāo)文件中的缺省庫信息。我們的目標(biāo)文件顯然指定了兩個(gè)缺省庫，一個(gè)是單線程靜態(tài)版標(biāo)準(zhǔn)庫
libc.lib(
這與
/ML
選項(xiàng)相符
)
，另外一個(gè)是
oldnames.lib(
它是為了兼容微軟以前的
C/C++
開發(fā)系統(tǒng)
)
。
?VC
的鏈接器是
link.exe
，因?yàn)?/span>
main.obj
保存了缺省庫信息，所以可以用
link main.obj libc.lib
或者
link main.obj
來生成可執(zhí)行文件
main.exe
，這兩個(gè)命令是等價(jià)的。但是如果你用
link main.obj libcd.lib
的話，鏈接器會給出一個(gè)警告
: "warning LNK4098: defaultlib "LIBC" conflicts with use of other libs; use /NODEFAULTLIB:library"
，因?yàn)槟泔@式指定的標(biāo)準(zhǔn)庫版本與目標(biāo)文件的缺省值不一致。通常來說，應(yīng)該保證鏈接器合并的所有目標(biāo)文件指定的缺省標(biāo)準(zhǔn)庫版本一致，否則編譯器一定會給出上面的警告，而
LNK2005
和
LNK1169
鏈接錯(cuò)誤則有時(shí)會出現(xiàn)有時(shí)不會。那么這個(gè)有時(shí)到底是什么時(shí)候？呵呵，別著急，下面的一切正是為喜歡追根究底的你準(zhǔn)備的。
???
建一個(gè)源文件，就叫
mylib.c
，內(nèi)容如下
:
/* mylib.c */
#include <stdio.h>
void foo()
{
?? printf("%s","I am from mylib!\n");
}
用
cl /c /MLd mylib.c
（
ML
要是大寫的，否則不認(rèn)。）
命令編譯，注意
/MLd
選項(xiàng)是指定
libcd.lib
為默認(rèn)標(biāo)準(zhǔn)庫。
lib.exe
是
VC
自帶的用于將目標(biāo)文件打包成程序庫的命令，所以我們可以用
lib /OUT:my.lib mylib.obj
將
mylib.obj
打包成庫，輸出的庫文件名是
my.lib
。接下來把
main.c
改成
:
/* main.c */
void foo();
int main()
{
?? foo();
?? return 0;
}
用
cl /c main.c
編譯，然后用
link main.obj my.lib
進(jìn)行鏈接。這個(gè)命令能夠成功地生成
main.exe
而不會產(chǎn)生
LNK2005
和
LNK1169
鏈接錯(cuò)誤，你僅僅是得到了一條警告信息
:"warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs; use /NODEFAULTLIB:library"
。我們根據(jù)前文所述的掃描規(guī)則來分析一下鏈接器此時(shí)做了些啥。
???
一開始
E
、
U
、
D
都是空集，鏈接器首先掃描到
main.obj
，把它加入
E
集合，同時(shí)把未解析的
foo
加入
U
，把
main
加入
D
，而且因?yàn)?/span>
main.obj
的默認(rèn)標(biāo)準(zhǔn)庫是
libc.lib
，所以它被加入到當(dāng)前輸入文件列表的末尾。接著掃描
my.lib
，因?yàn)檫@是個(gè)庫，所以會拿當(dāng)前
U
中的所有符號
(
當(dāng)然現(xiàn)在就一個(gè)
foo)
與
my.lib
中的所有目標(biāo)模塊
(
當(dāng)然也只有一個(gè)
mylib.obj)
依次匹配，看是否有模塊定義了
U
中的符號。結(jié)果
mylib.obj
確實(shí)定義了
foo
，于是它被加入到
E
，
foo
從
U
轉(zhuǎn)移到
D
，
mylib.obj
引用的
printf
加入到
U
，同樣地，
mylib.obj
指定的默認(rèn)標(biāo)準(zhǔn)庫是
libcd.lib
，它也被加到當(dāng)前輸入文件列表的末尾
(
在
libc.lib
的后面
)
。不斷地在
my.lib
庫的各模塊上進(jìn)行迭代以匹配
U
中的符號，直到
U
、
D
都不再變化。很明顯，現(xiàn)在就已經(jīng)到達(dá)了這么一個(gè)不動點(diǎn)，所以接著掃描下一個(gè)輸入文件，就是
libc.lib
。鏈接器發(fā)現(xiàn)
libc.lib
里的
printf.obj
里定義有
printf
，于是
printf
從
U
移到
D
，而
printf.obj
被加入到
E
，它定義的所有符號加入到
D
，它里頭的未解析符號加入到
U
。鏈接器還會把每個(gè)程序都要用到的一些初始化操作所在的目標(biāo)模塊
(
比如
crt0.obj
等
)
及它們所引用的模塊
(
比如
malloc.obj
、
free.obj
等
)
自動加入到
E
中，并更新
U
和
D
以反應(yīng)這個(gè)變化。事實(shí)上，標(biāo)準(zhǔn)庫各目標(biāo)模塊里的未解析符號都可以在庫內(nèi)其它模塊中找到定義，因此當(dāng)鏈接器處理完
libc.lib
時(shí)，
U
一定是空的。最后處理
libcd.lib
，因?yàn)榇藭r(shí)
U
已經(jīng)為空，所以鏈接器會拋棄它里面的所有目標(biāo)模塊從而結(jié)束掃描，然后合并
E
中的目標(biāo)模塊并輸出可執(zhí)行文件。
???
上文描述了雖然各目標(biāo)模塊指定了不同版本的缺省標(biāo)準(zhǔn)庫但仍然鏈接成功的例子，接下來你將目睹因?yàn)檫@種不嚴(yán)謹(jǐn)而導(dǎo)致的悲慘失敗。
???
修改
mylib.c
成這個(gè)樣子
:
#include <crtdbg.h>
void foo()
{
// just a test , don't care memory leak
?? _malloc_dbg( 1, _NORMAL_BLOCK, __FILE__, __LINE__ );
}
其中
_malloc_dbg
不是
ANSI C
的標(biāo)準(zhǔn)庫函數(shù)，它是
VC
標(biāo)準(zhǔn)庫提供的
malloc
的調(diào)試版，與相關(guān)函數(shù)配套能幫助開發(fā)者抓各種內(nèi)存錯(cuò)誤。使用它一定要定義
_DEBUG
宏，否則預(yù)處理器會把它自動轉(zhuǎn)為
malloc
。繼續(xù)用
cl /c /MLd mylib.c
lib /OUT:my.lib mylib.obj
編譯打包。當(dāng)再次用
link main.obj my.lib
進(jìn)行鏈接時(shí)，我們看到了什么？天哪，一堆的
LNK2005
加上個(gè)貴為
"fatal error"
的
LNK1169
墊底，當(dāng)然還少不了那個(gè)
LNK4098
。鏈接器是不是瘋了？不，你冤枉可憐的鏈接器了，我拍胸脯保證它可是一直在盡心盡責(zé)地照章辦事。
輸出信息：
C:\>link main.obj my.lib
Microsoft (R) Incremental Linker Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
?
LIBCD.lib(dbgheap.obj) : error LNK2005: _malloc already defined in LIBC.lib(mall
oc.obj)
LIBCD.lib(dbgheap.obj) : error LNK2005: __nh_malloc already defined in LIBC.lib(
malloc.obj)
LIBCD.lib(dbgheap.obj) : error LNK2005: __heap_alloc already defined in LIBC.lib
(malloc.obj)
LIBCD.lib(dbgheap.obj) : error LNK2005: _free already defined in LIBC.lib(free.o
bj)
LIBCD.lib(sbheap.obj) : error LNK2005: __get_sbh_threshold already defined in LI
BC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: __set_sbh_threshold already defined in LI
BC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_heap_init already defined in LIBC.
lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_find_block already defined in LIBC
.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_free_block already defined in LIBC
.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_block already defined in LIB
C.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_new_region already defined i
n LIBC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_new_group already defined in
?LIBC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_resize_block already defined in LI
BC.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_heapmin already defined in LIBC.li
b(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_heap_check already defined in LIBC
.lib(sbheap.obj)
LIBCD.lib(sbheap.obj) : error LNK2005: ___sbh_threshold already defined in LIBC.
lib(sbheap.obj)
LINK : warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs; use
?/NODEFAULTLIB:library
main.exe : fatal error LNK1169: one or more multiply defined symbols found
?
???
一開始
E
、
U
、
D
為空，鏈接器掃描
main.obj
，把它加入
E
，把
foo
加入
U
，把
main
加入
D
，把
libc.lib
加入到當(dāng)前輸入文件列表的末尾。接著掃描
my.lib
，
foo
從
U
轉(zhuǎn)移到
D
，
_malloc_dbg
加入到
U
，
libcd.lib
加到當(dāng)前輸入文件列表的尾部。然后掃描
libc.lib
，這時(shí)會發(fā)現(xiàn)
libc.lib
里任何一個(gè)目標(biāo)模塊都沒有定義
_malloc_dbg(
它只在調(diào)試版的標(biāo)準(zhǔn)庫中存在
)
，所以不會有任何一個(gè)模塊因?yàn)?/span>
_malloc_dbg
而加入
E
，但是每個(gè)程序都要用到的初始化模塊
(
如
crt0.obj
等
)
及它們所引用的模塊
(
比如
malloc.obj
、
free.obj
等
)
還是會自動加入到
E
中，同時(shí)
U
和
D
被更新以反應(yīng)這個(gè)變化。當(dāng)鏈接器處理完
libc.lib
時(shí)，
U
只剩
_malloc_dbg
這一個(gè)符號。最后處理
libcd.lib
，發(fā)現(xiàn)
dbgheap.obj
定義了
_malloc_dbg
，于是
dbgheap.obj
加入到
E
，它里頭的未解析符號加入
U
，它定義的所有其它符號也加入
D
，這時(shí)災(zāi)難便來了。之前
malloc
等符號已經(jīng)在
D
中
(
隨著
libc.lib
里的
malloc.obj
加入
E
而加入的
)
，而
dbgheap.obj
又定義了包括
malloc
在內(nèi)的許多同名符號，這引發(fā)了重定義沖突，鏈接器只好中斷工作并報(bào)告錯(cuò)誤。
??
?
現(xiàn)在我們該知道，鏈接器完全沒有責(zé)任，責(zé)任在我們自己的身上。是我們粗心地把缺省標(biāo)準(zhǔn)庫版本不一致的目標(biāo)文件
(main.obj)
與程序庫
(my.lib)
鏈接起來，導(dǎo)致了大災(zāi)難。解決辦法很簡單，要么用
/MLd
選項(xiàng)來重編譯
main.c
；要么用
/ML
選項(xiàng)重編譯
mylib.c
。
??
?
在上述例子中，我們擁有庫
my.lib
的源代碼
(mylib.c)
，所以可以用不同的選項(xiàng)重新編譯這些源代碼并再次打包?？扇绻褂玫氖堑谌降膸?，它并沒有提供源代碼，那么我們就只有改變自己程序的編譯選項(xiàng)來適應(yīng)這些庫了。但是如何知道庫中目標(biāo)模塊指定的默認(rèn)庫呢？其實(shí)
VC
提供的一個(gè)小工具便可以完成任務(wù)，這就是
dumpbin.exe
。運(yùn)行下面這個(gè)命令
dumpbin /DIRECTIVES my.lib
輸出信息：
C:\>dumpbin /DIRECTIVES my.lib
Microsoft (R) COFF Binary File Dumper Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
?
?
Dump of file my.lib
?
File Type: LIBRARY
?
?? Linker Directives
?? -----------------
?? -defaultlib:LIBCD
?? -defaultlib:OLDNAMES
?
? Summary
?
?????????? 8 .data
????????? 27 .drectve
????????? 18 .text
然后在輸出中找那些
"Linker Directives"
引導(dǎo)的信息，你一定會發(fā)現(xiàn)每一處這樣的信息都會包含若干個(gè)類似
"-defaultlib:XXXX"
這樣的字符串，其中
XXXX
便代表目標(biāo)模塊指定的缺省庫名。
知道了第三方庫指定的默認(rèn)標(biāo)準(zhǔn)庫，再用合適的選項(xiàng)編譯我們的應(yīng)用程序，就可以避免
LNK2005
和
LNK1169
鏈接錯(cuò)誤。喜歡
IDE
的朋友，你一樣可以到
"Project
屬性
" -> "C/C++" -> "
代碼生成
(code generation)" -> "
運(yùn)行時(shí)庫
(run-time library)"
項(xiàng)下設(shè)置應(yīng)用程序的默認(rèn)標(biāo)準(zhǔn)庫版本，這與命令行選項(xiàng)的效果是一樣的。
這是一片非常好的文章，如果你看到了這里的話，那我只能恭喜你成功了！
Have? fun
！