Solidityプログラミング3のリソースファイルの構成
4767 ワード
3.1バージョン文
ソースファイルは、バージョン文で高バージョンコンパイラのコンパイルを拒否できます.一部の高バージョンでは、互換性のない特性が導入され、コンパイル後に予知できない結果が発生する可能性があります.このバージョンの変化を最小限に抑えながら、文法と意味の同期修正をできるだけ要求することを望んでいます.この要求は達成しにくいです.したがって、0.X.0またはX.0.0で命名された各バージョンの変更ログを読む必要があります.バージョン文は次のように使用されます.
このようなソースファイルは0.4.0以前のコンパイラでコンパイルされず、0.5.0バージョン以上(0.5.0を含む)のコンパイラでもコンパイルできません(使用しました ^ )も参照してください.これは0.5.0までは大きな変化は起こらないので,我々のコードが予想される結果に従って実行できると確信できる.
3.2その他のリソースファイルの導入
3.2.1構文
Solidityは、JavaScript(ES 6)と似ているimportインポートリソースファイルをサポートしていますが、デフォルトでエクスポートされた機能はサポートされていません.import文のフォーマットは次のとおりです.これはグローバルで有効です.
この文は、「filename」を現在のプロジェクトにグローバルにインポートするとともに、「filename」に含まれるすべてのグローバルインポートファイルをグローバルにインポートします.後方互換性のサポート
「filename」のすべてのグローバルシンボルを含むsymbolNameというグローバルシンボルを新規作成します.
「filename」ファイルからsymbol 1とsymbol 2のグローバルシンボルをインポートし、symbol 1にaliasという別名を付けます.
もう一つはES 6文法ではありませんが、便利です
この文は
3.2.2パス
上記の「filename」は、/をディレクトリ区切り記号、.を現在のディレクトリ、...を上位ディレクトリとします..と...の後に/以外の文字が付いている場合は、ファイルディレクトリとして扱われません.ディレクトリのデフォルトは、.または...で始まる場合を除き、絶対パスです.現在のディレクトリの下のファイルxをインポートし、使用できます.
使用する場合
参照されるのは、異なるファイル(グローバル使用"include directory")です.ファイルパスの参照は、異なるコンパイラによって異なります.一般的に、ディレクトリ構造はローカルファイルシステムに厳密に対応する必要はありません.ipfs、http、gitにマッピングできます.
3.2.3コンパイラ使用
コンパイラの使用により、パスの最初の要素を検索する方法だけでなく、パス接頭辞マッピングも指定できます.次のようになります.
パスはローカルパスにマッピングできます
コンパイラは、ローカルパスから必要なファイルを読み込むことができます.複数のマッピング関係が同時に存在する場合、最長パスが優先されます.これにより、「/usr/local/include/solidity」などの代替マッピングを使用して、/usr/local/include/solidityにマッピングできます.これらのマッピングは、異なるバージョンの同じ名前のlibraryをインポートするなど、状況に応じてパッケージを構成できます.
Solc
solc(コマンドラインコンパイラ)では、
をクリックしてください.context:および=targetはオプションです.すべての依存ファイルを含む正しいファイルがコンパイルされます.これは完全に後方互換性のあるメカニズムで、インポートされたすべてのファイルで、定義された「prefix」フィールドで始まるとtarget定義の値に直接置き換えられます.たとえば、clone github.com/ethereum/dapp-bin/ローカル/usr/local/dapp-binの場合、次のimport文を使用できます.
コンパイルすると次のようになります.
古いバージョンのdapp-binのモジュールコードを使用している場合は、古いバージョンのdapp-binは/usr/local/dapp-binからold check outは、次のように使用できます.
これにより、すべてのmodule 2のimportは古いバージョンを指し、2 module 1は新しいバージョンを指します.注意solcでは、特定のディレクトリのみが許可されます.ファイルを明確に指定したディレクトリまたはマッピングターゲット内のディレクトリです.絶対含むことを許可する場合は、再マッピング=/複数の再マッピングが有効なファイルを指す場合は、最長の再マッピング接頭辞を含むことを優先します.
Remix
Remixはgithubの自動再マッピング機能を提供し、必要なリソースファイルをネットワークから自動的に取得できます.マッピングを次のようにインポートできます.
3.2.4コメント
単一ロー・コメントの提供 (//)と複数行コメント(/*......*/)
転載先:https://www.cnblogs.com/StephenWu/p/7087254.html
ソースファイルは、バージョン文で高バージョンコンパイラのコンパイルを拒否できます.一部の高バージョンでは、互換性のない特性が導入され、コンパイル後に予知できない結果が発生する可能性があります.このバージョンの変化を最小限に抑えながら、文法と意味の同期修正をできるだけ要求することを望んでいます.この要求は達成しにくいです.したがって、0.X.0またはX.0.0で命名された各バージョンの変更ログを読む必要があります.バージョン文は次のように使用されます.
pragma solidity ^0.4.0;
このようなソースファイルは0.4.0以前のコンパイラでコンパイルされず、0.5.0バージョン以上(0.5.0を含む)のコンパイラでもコンパイルできません(使用しました ^ )も参照してください.これは0.5.0までは大きな変化は起こらないので,我々のコードが予想される結果に従って実行できると確信できる.
3.2その他のリソースファイルの導入
3.2.1構文
Solidityは、JavaScript(ES 6)と似ているimportインポートリソースファイルをサポートしていますが、デフォルトでエクスポートされた機能はサポートされていません.import文のフォーマットは次のとおりです.これはグローバルで有効です.
import "filename";
この文は、「filename」を現在のプロジェクトにグローバルにインポートするとともに、「filename」に含まれるすべてのグローバルインポートファイルをグローバルにインポートします.後方互換性のサポート
import * as symbolName from "filename";
「filename」のすべてのグローバルシンボルを含むsymbolNameというグローバルシンボルを新規作成します.
import {symbol1 as alias, symbol2} from "filename";「filename」ファイルからsymbol 1とsymbol 2のグローバルシンボルをインポートし、symbol 1にaliasという別名を付けます.
もう一つはES 6文法ではありませんが、便利です
import "filename" as symbolName;この文は
import * as symbolName from "filename";3.2.2パス
上記の「filename」は、/をディレクトリ区切り記号、.を現在のディレクトリ、...を上位ディレクトリとします..と...の後に/以外の文字が付いている場合は、ファイルディレクトリとして扱われません.ディレクトリのデフォルトは、.または...で始まる場合を除き、絶対パスです.現在のディレクトリの下のファイルxをインポートし、使用できます.
import "./x" as x;使用する場合
import "x" as x;参照されるのは、異なるファイル(グローバル使用"include directory")です.ファイルパスの参照は、異なるコンパイラによって異なります.一般的に、ディレクトリ構造はローカルファイルシステムに厳密に対応する必要はありません.ipfs、http、gitにマッピングできます.
3.2.3コンパイラ使用
コンパイラの使用により、パスの最初の要素を検索する方法だけでなく、パス接頭辞マッピングも指定できます.次のようになります.
github.com/ethereum/dapp-bin/library パスはローカルパスにマッピングできます
/usr/local/dapp-bin/libraryコンパイラは、ローカルパスから必要なファイルを読み込むことができます.複数のマッピング関係が同時に存在する場合、最長パスが優先されます.これにより、「/usr/local/include/solidity」などの代替マッピングを使用して、/usr/local/include/solidityにマッピングできます.これらのマッピングは、異なるバージョンの同じ名前のlibraryをインポートするなど、状況に応じてパッケージを構成できます.
Solc
solc(コマンドラインコンパイラ)では、
context:prefix=target をクリックしてください.context:および=targetはオプションです.すべての依存ファイルを含む正しいファイルがコンパイルされます.これは完全に後方互換性のあるメカニズムで、インポートされたすべてのファイルで、定義された「prefix」フィールドで始まるとtarget定義の値に直接置き換えられます.たとえば、clone github.com/ethereum/dapp-bin/ローカル/usr/local/dapp-binの場合、次のimport文を使用できます.
import "github.com/ethereum/dapp-bin/library/iterable_mapping.sol" as it_mapping;コンパイルすると次のようになります.
solc github.com/ethereum/dapp-bin/=/usr/local/dapp-bin/ source.sol 古いバージョンのdapp-binのモジュールコードを使用している場合は、古いバージョンのdapp-binは/usr/local/dapp-binからold check outは、次のように使用できます.
solc module1:github.com/ethereum/dapp-bin/=/usr/local/dapp-bin/
\ module2:github.com/ethereum/dapp-bin/=/usr/local/dapp-bin_old/ \ source.solこれにより、すべてのmodule 2のimportは古いバージョンを指し、2 module 1は新しいバージョンを指します.注意solcでは、特定のディレクトリのみが許可されます.ファイルを明確に指定したディレクトリまたはマッピングターゲット内のディレクトリです.絶対含むことを許可する場合は、再マッピング=/複数の再マッピングが有効なファイルを指す場合は、最長の再マッピング接頭辞を含むことを優先します.
Remix
Remixはgithubの自動再マッピング機能を提供し、必要なリソースファイルをネットワークから自動的に取得できます.マッピングを次のようにインポートできます.
import "github.com/ethereum/dapp-bin/library/iterable_mapping.sol" as it_mapping;3.2.4コメント
単一ロー・コメントの提供 (//)と複数行コメント(/*......*/)
転載先:https://www.cnblogs.com/StephenWu/p/7087254.html