【Solidity】1.一个Solidity源文件的布局 - 深入理解Solidity索引一个Solidity源文件的布局

<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>）是可行的。

在下面的例子中，我们记录了合同的标题，两个输入参数的说明和两个返回的值。