Skip to main content

シャドウイングルール

CODESYS、通常、異なる要素に同じ識別子を使用できます。たとえば、POUと変数に同じ名前を付けることができます。ただし、混乱を防ぐために、この方法は避けてください。

306.

否定的な例:次のコードスニペットでは、ローカル関数ブロックインスタンスの名前は関数と同じです。

このような場合、インスタンスまたは関数がプログラムで呼び出されるかどうかは不明です。

FUNCTION YYY : INT
;
END_FUNCTION

FUNCTION_BLOCK XXX
;
END_FUNCTION_BLOCK

PROGRAM PLC_PRG
VAR
    YYY : XXX;
END_VAR
YYY();
END_PROGRAM


シャドウイング時のコンパイラの動作

異なる要素に同じ識別子が使用されている場合、コンパイラはエラーや警告を報告しません。代わりに、コンパイラは特定の順序でコードを検索して、識別子の宣言を探します。宣言が見つかった場合、コンパイラは他の場所で他の宣言を検索しません。他の宣言が存在する場合、それらはコンパイラに対して「シャドウ」されます。次のセクションでは、シャドウ規則 (つまり、識別子の宣言を検索するときにコンパイラが使用する検索順序) について説明します。 「あいまいなアクセスと修飾されたアクセス」セクションでは、あいまいなアクセスを防止し、シャドーイング ルールをバイパスする方法について説明します。

シャドーイングを防ぐ方法

名前が常に一意であることを確認するには、変数の特定のプレフィックスなどの命名規則に従う必要があります。

詳細については、以下を参照してください。 識別子の指定

命名規則は、の静的コード分析を使用して自動的にチェックできます。 CODESYS。静的コード分析では、名前の重複使用も検出できます YYY エラーとして報告します。

また、属性の一貫した使用を通じて qualified_only 列挙型とグローバル変数リストの場合、および修飾されたライブラリを使用することで、一意でない状況を回避できます。

同じ名前のPOUが デバイス ビューのPOUが呼び出されない場合 POU ビューが呼び出され、演算子 __POOL POUの名前が呼び出されるときに先頭に追加する必要があります。

例: svar_pou := __POOL.POU();

アプリケーションでの検索順序

コンパイラは、アプリケーションのコードで単一の識別子を検出すると、対応する宣言を次の順序で検索します。

  1. ローカル変数

    1. メソッドのローカル変数

    2. 関数ブロック、プログラム、関数、および任意の基本関数ブロックのローカル変数

    3. POUのローカルメソッド

  2. アプリケーションのグローバル変数( qualified_only グローバル変数が宣言されている変数リストに属性が設定されていません

    1. アプリケーションのグローバル変数 qualified_only グローバル変数が宣言されている変数リストに属性が設定されていません

    2. 親アプリケーションのグローバル変数 qualified_only グローバル変数が宣言されている変数リストに属性が設定されていません

    3. ライブラリも変数リストも修飾されたアクセスを必要としない場合の参照ライブラリのグローバル変数

  3. POU またはタイプ名

    1. アプリケーションからのPOUまたはタイプ名(つまり、グローバル変数リスト、関数ブロックなどの名前)

    2. 親アプリケーションからのPOUまたはタイプ名

    3. ライブラリからのPOUまたはタイプ名

  4. ライブラリ

    1. ローカルで参照されるライブラリの名前空間と、ライブラリによって公開されているライブラリ

  5. POU 意見

    1. のグローバル変数 POU ビュー、 qualified_only 属性は、それらが宣言されている変数リストに設定されます

    2. POUまたはタイプ名 POU ビュー(つまり、グローバル変数リスト、関数ブロックなどの名前)

    3. からのライブラリ POU

ヒント

のライブラリマネージャに挿入されているライブラリ POU ビューは、プロジェクト内のすべてのアプリケーションのライブラリマネージャーで、適切なプレースホルダー解像度でミラーリングされます。これらのライブラリは、アプリケーション内のライブラリと共通の名前空間を形成します。したがって、アプリケーション内のライブラリによるプール内のライブラリのシャドウイングはありません。

ライブラリ内の検索順序

コンパイラーは、ライブラリーのコードで単一のIDを検出すると、対応する宣言を次の順序で検索します。

  1. ローカル変数

    1. メソッドのローカル変数

    2. 関数ブロック、プログラム、関数、および任意の基本関数ブロックのローカル変数

    3. POUのローカルメソッド

  2. グローバル変数

    1. ローカル ライブラリのグローバル変数。 qualified_only グローバル変数が宣言されている変数リストに属性が設定されていません

    2. ライブラリも変数リストも修飾されたアクセスを必要としない場合の参照ライブラリのグローバル変数

  3. ローカルライブラリのPOUまたはタイプ名(つまり、グローバル変数リスト、関数ブロックなどの名前)

    1. ローカルライブラリのPOUまたはタイプ名(つまり、グローバル変数リスト、関数ブロックなどの名前)

    2. 参照されたライブラリからのPOUまたはタイプ名

    3. ローカルで参照されているライブラリの名前空間と、ローカルで参照されているライブラリによって公開されているライブラリ

あいまいなアクセスと修飾されたアクセス

これらの検索順序にもかかわらず、あいまいなアクセスが発生する可能性があります。たとえば、修飾アクセスを必要としない 2 つのグローバル変数リストに同じ名前の変数が存在する場合がこれに該当します。このような場合は、コンパイラによってエラーとして報告されます (例: XXXの名称の曖昧な使用)。

この種のあいまいな使用法は、たとえばグローバル変数リストの名前を介してアクセスすることにより、修飾されたアクセスによって一意にすることができます(例: GVL.XXX)。

シャドウイングルールを回避するために、資格のあるアクセスを常に使用することもできます。

  • グローバル変数リストの名前を使用して、リスト内の変数に一意にアクセスできます。

  • ライブラリの名前は、ライブラリ内の要素に一意にアクセスするために使用できます。

  • The THIS 関数ブロックのメソッドに同じ名前のローカル変数が存在する場合でも、ポインターを使用して関数ブロック内の変数に一意にアクセスします。

識別子の宣言場所をいつでも見つけるには、 編集→参照→定義に移動 指図。これは、コンパイラが明らかにあいまいなエラーメッセージを生成する場合に特に役立ちます。

インスタンスパスでの検索

上記の検索順序は、インスタンスパスのコンポーネントとして存在する識別子、または呼び出しの入力として使用される識別子には適用されません。

次のタイプのアクセス用 yy.component、それはによって記述されたエンティティに依存します yy ここでの宣言 component が検索されます。

もしも yy 構造化データ型(つまり、型)を持つ変数を示します STRUCT また UNION)、 それから component 次の順序で検索されます。

  • 機能ブロックのローカル変数

  • 基本機能ブロックのローカル変数

  • 機能ブロックのメソッド

  • 基本機能ブロックのメソッド

もしも yy グローバル変数リストまたはプログラムを示し、 component このリストでのみ検索されます。

もしも yy ライブラリの名前空間を示し、 component 上記の「ライブラリでの検索順序」のセクションで説明されているとおりに、このライブラリで検索されます。

2番目のインスタンスでのみ、コンパイラは、見つかった要素へのアクセスを許可するかどうか(つまり、変数がローカルでのみアクセス可能かどうか、またはメソッドがプライベートかどうか)を決定します。アクセスが許可されていない場合、エラーが発行されます。