<a href="http://blog.csdn.net/diandianxiyu_geek/article/details/77877841">【Solidity】1.一個Solidity源檔案的布局</a>
<a href="http://blog.csdn.net/diandianxiyu_geek/article/details/77892188">【Solidity】2.合約的結構體</a>
<a href="http://blog.csdn.net/diandianxiyu_geek/article/details/77930835">【Solidity】3.類型</a>
<a href="http://blog.csdn.net/diandianxiyu_geek/article/details/77942459">【Solidity】4.機關和全局可變量</a>
<a href="http://blog.csdn.net/diandianxiyu_geek/article/details/77964409">【Solidity】5.表達式和控制結構</a>
<a href="http://blog.csdn.net/diandianxiyu_geek/article/details/77981249">【Solidity】6. 合約</a>
<a href="http://blog.csdn.net/diandianxiyu_geek/article/details/77989384">【Solidity】7. 部件</a>
<a href="http://blog.csdn.net/diandianxiyu_geek/article/details/78016231">【Solidity】8. 雜項</a>
源檔案可以包含任意數量的合約定義,include指令和pragma僞指令。
源檔案可以(并且應該)使用所謂的版本編譯訓示進行注釋,以拒絕随後可能引入不相容更改的編譯器版本進行編譯。 我們嘗試将這些更改保持在絕對最小值,尤其是在語義變化也需要更改文法的情況下引入更改,但這并不總是可能的。 是以,至少對于包含突破性更改的版本,讀取更改日志總是一個好主意,這些版本将始終具有0.x.0或x.0.0格式的版本。
版本pragma使用如下:
這樣一個源檔案不會使用比版本0.4.0之前的編譯器編譯,并且它也不會在從0.5.0版本開始的編譯器(第二個條件通過使用^添加)起作用。 這個想法是,直到版本0.5.0才會有變化,是以我們可以随時确定我們的代碼将按照我們打算的方式進行編譯。 我們不會修複編譯器的确切版本,是以修補程式版本仍然可能。
可以為編譯器版本指定更複雜的規則,表達式遵循由npm使用的規則。
Solidity支援與JavaScript中可用的導入語句(來自ES6)的引用語句,盡管Solidity不知道“default export”的概念。
在全局層面,您可以使用以下形式的導入語句:
此語句從“filename”(以及導入的符号)導入所有全局符号到目前全局範圍(與ES6不同,但與Solidity相反)。
…建立一個新的全局符号symbolName,其成員都是來自“filename”的全局符号。
…建立新的全局符号<code>alias</code>和<code>symbol2</code>,分别從“<code>filename</code>”引用<code>symbol1</code>和<code>symbol2</code>。
另一種文法不是ES6的一部分,但可能很便于:
相當于<code>import * as symbolName from "filename";</code>
在上文中,檔案名始終被視為具有<code>/</code>作為目錄分隔符的路徑. <code>.</code>作為目前目錄和<code>..</code>作為父目錄。 當<code>.</code> 或<code>..</code>後跟一個字元,除了<code>/</code>,它不被認為是目前或父目錄。 所有路徑名稱都被視為絕對路徑,除非它們以目前的路徑開頭<code>.</code> 或父目錄<code>..</code>.
要從與目前檔案相同的目錄導入檔案x,請使用導入“<code>./x</code>”作為<code>x</code> ;. 如果使用導入“<code>x</code>”作為<code>x</code>; 相反,可以引用不同的檔案(在全局“包含目錄”中)。
這取決于編譯器(見下文)如何實際解析路徑。 一般來說,目錄層次結構不需要嚴格地映射到本地檔案系統上,它也可以映射到通過例如檔案發現的資源比如 ipfs,http或git。
當調用編譯器時,不僅可以指定如何發現路徑的第一個元素,而且可以指定路徑字首重新映射, <code>github.com/ethereum/dapp-bin/library</code>被重新映射到<code>/usr/local/dapp-bin/library</code>,編譯器将從那裡讀取檔案。 如果可以應用多重重新映射,則首先嘗試使用最長密鑰。 這允許一個“回退-重新映射”與例如 “”映射到“<code>/usr/local/ include/solidity</code>”。 此外,這些重新映射可以依賴于上下文,它允許您配置包導入例如 不同版本的同名庫。
對于solc(指令行編譯器),這些重新映射作為上下文提供:<code>prefix = target</code>參數,其中<code>context</code>和and = target部分都是可選的(在這種情況下,target預設為字首)。 所有重新映射的值都是正常檔案(包括它們的依賴項)。 這個機制是完全向後相容的(隻要沒有檔案名包含<code>=</code>或<code>:</code>),是以不會發生變化。 導入以字首開頭的檔案的目錄上下文檔案中的所有導入将通過将目标替換為字首來重定向。
例如,如果您将本地<code>github.com/ethereum/dapp-bin/</code>克隆到<code>/usr/local/ dapp-bin</code>,則可以在源檔案中使用以下内容:
然後運作編譯器
作為一個更複雜的例子,假設你依靠一些使用非常舊版本的dapp-bin的子產品。 在<code>/usr/local/ dapp-bin_old</code>中檢出舊版本的<code>dapp-bin</code>,然後可以使用
是以<code>module2</code>中的所有導入都指向舊版本,但是在<code>module1</code>中導入擷取新版本。
請注意,solc僅允許您包含某些目錄中的檔案:它們必須位于顯式指定的源檔案之一或重映射目标的目錄(或子目錄)中的目錄(或子目錄)中。 如果要允許直接絕對包含,隻需添加重新映射<code>=/</code>。
如果存在導緻有效檔案的多個重新映射,則選擇具有最長公共字首的重映射。
Remix為github提供自動重新映射,并且還可以通過網絡自動檢索檔案:您可以通過例如導入疊代映射。
其他源代碼提供者可能會在将來被添加。
單行注釋(<code>//</code>)和多行注釋(<code>/*...*/</code>)是可行的。
在下面的例子中,我們記錄了合同的标題,兩個輸入參數的說明和兩個傳回的值。