この話はなぞなぞから始めます。

アリスでさえほとんど答えません、

その後のおとぎ話の残り、

言われた後？

このエッセイはさまざまなトピックに専念しますが、その中にはサブタイトルで提起された質問に対する場所と答えがあり、物語は主に現代のMKの周辺の初期化に関連する問題を中心に展開します。

そのため、MKのハードウェアのセットアップに関連する主な問題の概要を説明します。多数のパラメーターを設定する必要があり、そのほとんどはそれぞれの場合に指定されませんが、それでもなお、任意に設定することはできませんが、事前に定義された値を取る必要があります。 このような単純な問題の声明が意識の流れを引き起こし、あまり明確でない解決策につながる可能性があると考えている場合は、



鼻が痛いインターフェース、すなわちIRPS（ラジアルシリアルインターフェース-彼女は現在UARTキャラクターとして登場したのはこの名前でした）のセットアップに関連する例を見てみましょう。 私は、ロシア語の略語が道路上に部分的にメモを書くという事実である理由にすぐに答えます。私は個人的に、キーボードレイアウトの切り替えをAndroidキーボードの便利な部分とは呼びません個人的には、そうでなければ画面を突くのはとても不便です）。

もちろん、提起された問題の範囲はIRPSに限定されるものではなく、他のMK機器を構成する必要がありますが、例として取り上げました。 そのため、IRPSの動作を設定するには、少なくとも送信フォーマットを設定する必要があります。送信フォーマットは、次のパラメーターによって決定されます-送信速度、送信データビット数、パリティビットの存在とタイプ、ストップビット数。 そして、これはほんの始まりに過ぎず、実際には拡張構成もあり、はるかに長くなりますが、今ではそれについてではありません。 また、IRPSを使用する場合、ケースの70％で標準構成9600-8-0-1が設定され、別の25％で伝送速度のみが変更され、他のすべての構成は残りの5％を共有するが、そのために存在する必要があることも考慮する必要がありますカスタマイズする機能。



この問題を解決するためのさまざまなオプションを検討する前に、特定のオプションの成功を評価するための基準を決定する必要があります。そうしないと、より適切なオプションの選択が好みの議論に変わります。 私の投稿では、以下の状況が決定することを考慮しているため、主に信頼性基準から進みます。1.間違いを犯すのは人間の性質です。2.コンパイラのタスクは、これらのエラーをできるだけ早く指摘し、理想的にはその外観。 上記の2つの仮説の少なくとも1つに同意しない場合、おそらくこの記事はあまり好きではないので、このレッスンは禁止されていませんが、これらの立場から、私は1つまたは別の解決策の受容性を検討しますコメントであなたの立場を継続し、（必然的に合理的に）述べる



そもそも、前世代のMK（PIC、AVR、51）では、対応するレジスターに直接録音することで機器を構成するという素晴らしい仕事をしたため、このような問題が発生した理由を理解できますか？ まあ、まず第一に、あなたは登録を知る必要があります、または、今日それを置くことが慣習であるので、マニュアルを吸ってください、そして私には個人的にこのレッスンは特に面倒ではないようですが、特に現在のマニュアルの品質を考慮して、重要な部分についてコミュニティでは、このアプローチが本当に問題になる可能性があります。



最近のドキュメンテーションの品質についての小さなメモ（私は本当にそう思いました）-草は以前より緑だったかもしれませんが、最近のブログの1つでジャックハンスリーのフレーズに完全に同意します。 「不十分」という言葉が最もソフトな定義になりますが、以前は存在しないと定義されていました。 もちろん、インターネットは素晴らしいものです（そして、ここには皮肉はありません、これは本当に新しい世界の奇跡です）。開発者とフォーラムの両方で、あいまいな場所で質問をすることができ、多くの答えを得ることができます。 、しかし不一致の余地を残さないような方法でドキュメントを書いてみませんか？ 彼らは通常、開発者は良いドキュメントを書くために関与する必要があり、彼らの時間は貴重であり、テクニカルライターはタスクに対処できないと答えますが、私の意見では、これは私の問題ではありません。



デバイスの開発者はあまりにも自明であると信じているため、開発者に自明なことは常に（より正確には、常にではなく）ユーザーには自明ではないため、ドキュメントの執筆を外部委託することをお勧めしますが、デバイスを使用するデバイス開発者にはお勧めです。 この種のサービスを提供するオフィスを作成することもできますが、製造業者の文書に対する態度を考えると、こうした高価で不要なサービスを使用する可能性は低いでしょう。



ドキュメントのトピックに関する若干の回想。 私は最近、単一チップの説明を調べました（ちなみにIntelによる）。PE_RST_Nという名前の入力があります。これは、+ 3.3Vdc入力として記述され、アサートされると、電力とクロック周波数の存在を通知します。 入力がどのように正確に記述されているか-高または低は示されていません、この信号の時間図はありません（ただし、時間図にはPERST＃信号があり、デバイス状態図では同じ名前で示されています）値0bはリセットのアクティビティを示します。リセットが存在する場合の動作モードの表では、列の値にチェックマークがあり、ヒントのようになっています。 一般に、間接的な兆候の全体に基づいて、デバイスのリセットにつながるこのレッグのアクティブレベルはイエス、ローであると結論付けることができますが、ドキュメントの対応する明確で簡潔で理解可能な説明を読むだけでなく、なぜ推測する必要がありますか？

なぜ私は推測と推測の不安定な地に入ることを余儀なくされるのですか？ おそらく個人的には、これは過去の人生における悪いカルマに対する罰です（私もこの人の天使ではありませんでした）が、他の開発者は何をしましたか？ 私の同僚の一人は、このような文書化は膝から立ち上がるのを困難にするために特別に行われているという興味深い仮説を表明しましたが、なぜそれが英語で書かれているのですか？ それとも私たちのために特別に作られたものですが、西洋では実際の正しい文書を使用していますか？ この場合、「単純な怠inessによって説明できることを悪意を持って説明するべきではない」というフレーズは完全に当​​てはまります（そのようなドキュメントの作成者を逐語的な引用で怒らせません）。



しかし、私の個人的なコレクションの本当の傑作は、プルアップ抵抗器接続の接続制御が次のように記述されている文書で、一般的には国内企業によって製造された悪くないMKの説明です：「0-プルアップ抵抗器のドロップアウト」、1 ...そこに書かれていますか？ -「プルアップ抵抗器は脱落しません」-良い試みですが、推測しませんでした...スタジオでのドラムロール...「値は0の反対です」。 みんな拍手、カーテン。



しかし、上記のすべて（誰かがすでに忘れている場合、ドキュメントの重要でない品質について話している）は、問題の一部であり、その2番目のコンポーネント

現代のMKは前任者よりも本当に複雑であるという事実にあります。 ハードウェアがより複雑になり、「開発者の増え続けるニーズをますます完全に満たす」がこの現象の理由のリストの最初に来ない理由について、私自身のポイントがありますが、全体的な私の考えは一般的に状況を変えません-現代のMKは本当に複雑ですその前任者のうち、ハードウェアブロックがはるかに多く、ブロック自体がより複雑になり、開発者がビジネスに使用できる（および使用する必要がある）追加の機能を実装しています。 START UARTファミリのいくつかの機能（本当に役立つ）のトピックに関する投稿を考えました。これを終えたら、これらの機能の使用を実装するときだけ、この投稿に命を吹き込んだ問題について考えました。



問題の次の部分は、さまざまなメーカーのMKファミリと1つのメーカーの同じシリーズ内のMK亜種の両方の命名法の増加に関連しており、1つの亜種内のかなり多様なデバイスで終わります。 命名法の拡大と同時に、家族の特定の代表者のライフサイクルが短縮され、新しいデバイスへの永続的な移行の問題が生じます。 繰り返しますが、これは常に必要というわけではありませんが、それに対処することは非常に難しいので、別のMKへの切り替えができるだけ痛みがなく、理想的には1行を置き換えるようにソフトウェアを開発することをお勧めします

#define device xxxxx
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、これは標準ライブラリを使用することで容易になります。そのため、私はこの投稿を正しい（私の観点からは、別のことも知っています）について書いています。



IRPS設定を実装するための可能なオプションの検討を開始し、それらの最初のものは、すべての可能なパラメータを持つ単純な初期化関数になります（ここでは、しばらくの間、アルゴリズムプログラミング言語であるANPにサンプルテキストを書く誘惑に苦しみましたが、それはすでに国境の反対側にあると決定しました、善から悪を分離し、いじめから簡単にトローリングを行います）。 そして、次のようなものが得られます

 UARTInit(9600,8,0,1);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

前述の標準的なケースの場合（以下、MKに存在する機器の1つの調整可能なチャネルを選択するという質問は、括弧から除外します）。 ここではすべてが順調で、超自然的なことを書く必要はありませんが、このオプションの欠点を見つけ、（もちろん、他の理由で）欠点を排除しようとします。



まず最初に、ハードウェアのセットアップ手順で一般的に必要なものと、それに設定する要件を決定する必要があります。 私の意見では、プログラムは主に信頼でき、安全で、理解できるものでなければなりません。 初期化は原則として一度実行され、あまり速くないため、効率要件はそれほど重要ではありませんが、メモリがコンパクトで速度が要求されない場合、これは評価の追加プラスです。 ところで、少なくとも1つの技術、つまりCharliplekingでは、MKレッグの動作モードを変更する必要があるため、速度をまったく無視しないでください。



このテクノロジーで見られる欠点（そして、それ以外の場合はさらに詳しく説明します）-まず、多数のパラメーターを厳密に定義された順序でリストする必要があり、どこかで間違いを犯した場合、結果は得られません期待していたもの。 各パラメーターにカスタムデータ型を定義すると、パラメーターの順序に関する問題は多少緩和され、次のようになります。

 typedef enum {…UARTSpeed9600…} UARTSpeedT; void UARTInit(UARTSpeesT UartSpeed,…};
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

、ミスをしようとすると、コンパイラから警告が表示されます。 このアプローチは、実行段階とコンパイル段階で少しも費用がかかりません。そのため、私はそれを強くお勧めすると同時に、著者（独自のライブラリを含む）がこのような単純かつ同時に効果的な方法で無視されているという苦痛な戸惑いを表現できます。



彼らの唯一の正当化は、直感的な（皮肉だった）マジックナンバー9600とは対照的に、記憶する必要がある表現を使用する必要があるかもしれません。 別の方法は、関数に入るときの多数のアサーションで、コンパイラーのパラメーターの正確性をチェックします。 原則として、このアプローチはそれほど悪くはありません（小さな魚でも大きなゴキブリよりも優れています）が、デバッグをリリースし、エラーメッセージを実行ステージに転送する必要があります。



ただし、パラメーターの順序の要件を少し滑らかにすると（違反しようとするとscられるようになります）、それでもすべてのパラメーターをリストする必要があり、面倒です。 高度な言語で作業する場合、デフォルトのパラメーター値がありますが、古典的なCのフレームワーク内にとどまる場合（そして、前に警告しない限り、それらに留まる場合）、この方法は私たちには適していません。 さらに、このメソッドには非常に大きな制限があります。つまり、すべてのデフォルトパラメータは定義されたパラメータに従う必要があるため、リストの最後のパラメータを明示的に設定するには、以前のパラメータをすべて指定する必要があります。



C ++などの高度な言語で再び作業する場合、もう1つの方法があります-割り当て演算子をオーバーロードしますが、（4 + 4 * 3 + 4 + 1 = 21）割り当て関数をハード引数の順序と、任意の順序のさらに想像できない数の割り当て関数。 それにもかかわらず、そのような可能性が存在し、良識の規則はそれを言及することを必要としますが、彼らはそれを使用することを義務付けていません。



マクロ言語機能を実際に提供する優れたプリプロセッサがあれば、可変数の型付き引数を使用してマクロ関数呼び出しを記述し、プリプロセッサによって生成された関数呼び出しを取得できますが、それはありません（まあ、Cには優れたプリプロセッサがありません） 、平均がありません）。 この投稿の読者の1人がC言語の標準プリプロセッサを本当にマクロ言語であると考えている場合、DECマシンのアセンブリ言語マクロプロセッサの説明に精通することを強くお勧めします。そうすれば、この主題についてさらに詳しく議論することが可能になります。 しかし、この順序でのみであり、コード生成の他の開発された手段との知り合いを排除しません。 それにもかかわらず、そのようなアプローチは表現手段が限られているため利用できないため、独自のプリプロセッサを作成することはありません。 この悲観的な注意事項については、直接パラメーター転送で初期化関数を使用するオプションの説明を締めくくります。



別のオプションは、特定の制御構造を使用し、この構造のフィールドの値を設定するプロセス（デフォルトで設定されているものを含む）を初期化プロセス自体から分離することです。 何が私たちにそのような分離を与えますか？ まず第一に、デフォルト値とは異なるパラメーターのみを変更する待望の機会です。

もちろん、同時に、これらの値を非常によく想像して覚えておく必要がありますが、2コマンドコンパイラは達成不可能な理想のままです。 しかし、あなたはこの世界のすべてにお金を払わなければなりません、そしてそのような機会のために、私たちはこれらの非常にデフォルト値を保証する必要性を支払わなければなりません、関数への直接呼び出しを使用するとき、何らかの方法でコンパイラによって保証されました。



もちろん、デフォルト値を設定するための関数を作成し、使用する予定の制御構造に対してそれを呼び出す場合、問題はありません。 そして、これをするのを忘れたら？ 最良の場合、期待したものとは少し異なり、中程度の深刻度の場合、期待したものがまったく得られず、非常に悪い場合、機器を損傷するほど多くは得られませんが、最悪の場合はすべて得られます上記の突然、つまり、まれで繰り返しの少ない状況です。 これは、タスクが決して決してフェッチされないようにするためです。



繰り返しますが、C ++を使用する場合、コンストラクタは私たちの願望に対する自然な答えであり、スマートポインタもねじ込むと、ソリューションは理想に近くなりますが、これはサムライの方法であるため、純粋なCのフレームワークのままです（セグメンテーション障害連続パス）。



制御構造の使用に関連する1つの問題、つまり構造自体の形式とそのコンポーネントの変更方法に対する態度を決定します。

まず第一に、私は個人的に、一般にライブラリの内部構造、特にこのライブラリの制御構造に関する情報をユーザーに提供することに反対することを宣言します。 この振る舞いの逸脱の理由は、呪われた過去のため、OOPの原則からはほど遠いものであり、コンピューターが大きい遠い時代に置かれたため、名前テーブルの大小のRAMがコンパイルを本当に遅くする可能性がありました。 したがって、カプセル化とインターフェイスの概念は、内部抵抗なしで、コンパイル段階でメモリを節約することとはまったく異なる理由で作成されましたが、私は非常に冷静に私の時代に受け入れました。

ちなみに、VMKで教えられたコースに基づいて「数学者のためのプログラミング」という本をお勧めします（かつて、操作方法の観点からこの用語を使わずにOOPの原理を完全に説明しています）。



そして、私の行動は逸脱であり、主流からの逸脱であることが、STMやTIを含む有名なソフトウェアパッケージのソースの調査によって確認されています。 理解できない考慮事項のため、これらのパッケージの作成者は、ヘッダーファイルの入れ子になった包含と再包含に対する保護を使用することによって達成されるすべてについてすべてを知っておく必要があると考えています。 つまり、突然IRPSモジュールがUSBホスト制御レジスタ内のビットの分布を見つけられない場合、「苦しみ、衰弱し、さらには...死ぬ」ことになります。



提起されたトピックに関する小さな余談-hファイルでのincludeディレクティブの使用は悪であると本当に考えます。また、ヘッダーファイルの先頭に条件付きマクロを配置して、喫煙による害を減らす方法のヒントとして再包含を防ぐことをお勧めします。 正しいシンプルな解決策-喫煙しない-は推奨事項の作者によって考慮されていません。つまり、ソフトウェアパッケージのアーキテクチャを検討し、モジュールの関係を決定し、その階層の平均を構築することを暗示しています（平均以上またはよく知られている企業の製品について話している）プログラマー組み込みシステムは定義上機能していません。そのため、私たちは曲がった利き手による害を最小限に抑えることについてのみ話すことができます。

これがどれほど真実かはわかりませんが、個人的には、そのような埋め込みヘッダーファイルには、作成者の優れた（信頼性が高く便利な）コードを書く能力に疑問を投げかけるものがあります。 しかし、これは個人的な意見であり、頻繁な会話で表明され、彼らが言うように、「しかし、私はそれがそのように可能であったことを知りませんでした」。



だから彼らは（STMとTI）彼らが望むように、私は「あなたが知っているほど眠れない」、または別の言い回しで「あなたが知らないことはあなたを心配させることはできない」という原則を守り続けます。 したがって、ライブラリのユーザーはその内部構造に関するFIG情報をあきらめなかったと信じていますが、C内ではそれを提供する義務があります（そしてTurbo Pascalではユニットコンセプトでどれだけクールでしたが、実現不可能の夢は何ですか？ C ++には含まれないこと17）。 だからどこかで

 Typedef struct { UARTSpeedT UARTSpeed; … } UARTConfigT;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そしてその外観は共産主義労働者の勝利と同じくらい避けられない。 しかし、誰も私たちに泥沼への道に沿って別の一歩を踏み出し、スタイルで制御情報の値を設定することを強制しません

 UARTConfigT UARTConfig; UARTConfig.UARTSpeed=UARTSpeed9600;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ユーザーは私たちの特定の分野に全く興味がなく、必要なことが起こるという自信だけが必要だからです。 したがって、次のコードフラグメントに示すように、1つまたは別のSET-teraの使用が望ましいと思われ、別の関数またはメンバー関数としての実装は好みの問題のままです。

 void UARTSetSpeed(UARTConfigT *UARTConfig, UARTSpeedT UARTSpeed); UARTSetSpeed(&UartConfig, UARTSpeed9600);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

関数の命名スタイルがどれほど重いかおaび申し上げますが、名前に20文字を追加することで30分間のデバッグを節約できれば、勝ちました。

このアプローチは、OOPの原則に従うことに加えて、実用的な価値があります-C ++を使用する場合（ただし、使用しない場合、忘れないでください？）、1つのオーバーロード関数を記述し、スタイルでさまざまなパラメーターを設定することができます

 void UARTSetParam(UARTConfigT *UARTConfig, UARTSpeedT UartSpeed); void UARTSetParam(UARTConfigT *UARTConfig, UARTParityT UartParity);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

など、名前を記憶するために必要な機能の数を減らすことにより、ユーザーの脳への負荷を減らすことができます。

もちろん、「DarZaNeBy」（Heinleinを大切にしている人への特別な挨拶）とセッターへのアクセスには、フィールドに値を直接割り当てるよりも、実行に時間がかかり、コードを保存するためにより多くのメモリが必要です（インライン関数の場合、このステートメントと疑わしい）、しかし、私の観点から、利点は勝ります。



もう1つの興味深い側面は、ユーザーがコントロール構造を必要とせず、それについて（彼が考えることは何でも）知らないということです。そのため、ユーザーには見えないようにするとよいでしょう。これにより、その使用方法または匿名インスタンスに特定の制限が課せられますが、これについては後で詳しく説明します。



したがって、個々のフィールドの値を設定する方法では、明示的に指定されていないフィールドの値に関して疑問が生じ、それに応じてデフォルトで設定されます。 ここでは、2つの側面を区別する必要があります。フィールドにゴミが存在しないことを保証することと、構造体の以前の使用で残った値です。 また、初期化された変数を使用して最初の変数を処理できる場合、初期化関数の明示的かつ直接的な呼び出しを行わない2番目の変数は、デザイナー（私たちにはない）でも解決できません。



初期初期化に関しては、これは制御されているので原則として正しく許容される構造の宣言点での直接初期化、またはそのゼロ化を保証するグローバル変数の領域に構造を配置するかのいずれかであり、この方法は原則として受け入れられないと考えていますそれは制御不能であり、デフォルト値に大きな制限を課しているため、それらは0に等しくなければなりません。いずれにしても、再利用の問題はそのような手法を解決しません。 社会化は良いスタイルのデモンストレーションとしてのみ見ることができますが、解決策としてではありません。



スズメの餌に他のすべてを混ぜた後、どのような解決策が受け入れられると思いますか？ このソリューションは複雑です。つまり、デフォルト値を提供することができ、パラメーターを選択的に変更することができます。ユーザーエラーを排除し、血中コレステロールを下げ、この包括的なソリューションの典型であるように、はるかに有用で必要なことを行います。 そして、その重要な特性のもう1つは、純粋なCで記述されています。つまり、武道道は損傷を受けませんでした。



結局のところ、日本の鋼の貧弱な性質と、刃への刃の古典的なフェンシングの不可能性について話すことができますが、一撃で戦いを解決することは非常に美しいです。まず、鞘から刃を引き抜き、血の滴を振り落として単一の動きで返すことで終わります道路上の不運な相手。 批評家に関しては、最近、「Don Juanのインポテンツによる批評は客観的に公平になり得るが、それでも不快な意味合いを持っている」という素晴らしいフレーズを読みました。

正直なところ、私はこの瞬間に投稿を停止し、読者を全く戸惑いと失望に追い込みたいと思っていますが、それでもさらなるテストを行い、非常に美しく説明された解決策が厄介で不便であることが判明したという事実から別の種類の失望を得ることができます。



そこにあります。

 UARTConfigT UARTConfigInit(void) { UARTConfigT UARTConfig; UARTConfig.UARTSpeed=UARTSpeed9600; return UARTConfig; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、Cでは、配列を除く任意の型を返すことができ、配列を含む構造体を返すことができます。これには少し驚かされますが、KerniganとRichieにはそのような解決策の理由があったようです。 しかし、悪いことは起こり得ません。そのような解決策は絶対に信頼でき、言語標準に準拠しています。 しかし、これは初期化手順にすぎませんが、重要なパラメーターのタスクをどのように実行しますか？ 中間変数を使用するオプションは、ユーザーのエラーの例外を保証せず、次のスタイルでカスケード使用を作成するわけではないため、inりで却下されます。

 UARTConfigT UARTConfigSpeed(UARTSpeedT UARTSpeed,UARTConfigT UARTConfig) { UARTConfig.UARTSpeed=UARTSpeed; return UARTConfig; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パラメーターを設定する順序に注意してみましょう。このようなソリューションの利点は次のとおりです。

 UARTConfigSpeed(UARTSpeed4800,UARTConfigParity(UARTParityEven,UARTConfigInit()));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、パラメータ値は関数名の直後に続きます。関数名は、次の式に比べて見やすくなっています

 UARTConfigSpeed(UARTConfigParity(UARTConfigInit(),UARTParityEven),UARTSpeed4800));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、TurboVisionでプログラミングした人は、最後にたくさんの閉じ括弧があるこの忘れられないスタイルを認識していましたが、1行の式を作成する必要はなく、代替案はすでに悪夢のように見えます

 UARTConfigSpeed(UARTSpeed4800, UARTConfigParity(UARTParityEven, UARTConfigInit() ) );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、これはすでに好みの問題であり、定義によって議論することはできません-味は議論されていません。



このオプションの利点-制御構造の初期化をスキップする可能性を排除し、ユーザーがこの構造に精通していないことを排除します。匿名であるため、関数パラメーターの対応をチェックします（列挙型のため）。正しくしましたが、構造を使用するのを忘れていました（間違いを犯すのは人間の性質であることを覚えています）。 すべての操作がまだIRPSの実際の設定につながっていないという事実を見失い、まだ機能が必要です

 int UARTConfigUse(UARTConfigT UARTConfig) { return DO_something(); //      };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最終フォームの例は次のようになります

 UARTConfigUse( UARTConfigSpeed(UARTSpeed4800, UARTConfigParity(UARTParityEven, UARTConfigInit() ) ) );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ケーキのチェリーとして、最後の間違いの可能性を制御できることを示します-残念ながら、この可能性は標準言語ツールには適用されず、GCCファミリーにのみ存在します-初期化と設定が機能する戻り値を無視することに関する警告__attribute __（（warn_unused_result））と記述する必要があります。この方法があなたのために特に機能するかどうかは、コンパイラの開発者に依存します。たとえば、KEILで機能しましたが、IARでは機能しません（IARを非推奨にするわけではありません。マクロといくつかの中間コンパイル時変数に基づいて、この問題に対する他の解決策がありますが、残念ながら、結果を保証しません。



表現力と信頼性の問題をすべて解決するのに、与えられたチューニング方法が理想的であると個人的に考えることができないのはなぜですか？実行コストの点で効率が低いためだけに、簡単に言えば、時間の経過に伴う例外的な大食いのためです。

非原始型の結果を返す関数に関連して、この投稿に対するエピグラフで提起された質問に答える時が来ました。結局のところ、コンパイラーの警告が表示されるため、内部変数へのポインターを返すことができません（警告がオフになっている場合は、そうすることができます）。

コンパイラはこの問題をどのように解決しますか？私はそれがどうあるべきかわからない、私はC言語標準を読まなかった（そう、そうだし、それを認めることを恥じていない）、私は実装の詳細がそこに記述されているかどうかは分からない次のメカニズムがあります。非プリミティブ型を返す関数を呼び出す関数（メインを含む）を入力すると、この型の変数を格納するのに十分なスペースがスタックに割り当てられます。次に、呼び出された初期化関数は、戻りアドレスの下でスタックに内部変数のビットごとのコピーを実行し、作業の完了後、返された結果の値はスタックの最上部にあります。パラメータ値を変更するための関数を呼び出す前に、この値はスタックにコピーされ、引数として渡されます。結果はビット単位でスタックから割り当てられたメモリ領域に再度コピーされ、そこからパラメータ値を変更する次の機能のためにアクセスできます。

つまり、特定のデータ（および非常に大きなサイズになる可能性がある）は、割り当てられたメモリ領域（ところで、スタック上）とスタックの最上部との間で絶えずドラッグされます。もちろん、これは高速な作業には寄与しません。



どうすれば関数の速度を上げることができますか-戻り値の型を変更し、効率的にコピーされるポインターを返します。しかし、その後、初期化関数の結果として、ポインターは何かを指し示す必要があり、不適切な再帰に陥る危険があります。 use関数での一時的なオブジェクトの作成とその後の削除は素晴らしいことですが、宗教的な理由で動的オブジェクトを使用することはできません（静的のみ、ハードコアのみ）。



奇妙なことに、内部変数へのポインターを返すことは、すべての構成関数が同じサイズのパラメーターで機能する場合は機能しますが（スタックの上部の情報は損なわれません）、それでもサーベルダンスの印象を残します（つまり、サーベルではなく、サーベル） 、それは非常に危険なトリックです）。中断が許可される場合、特にスリルがそのような決定であなたを待っています。



ローカル構造を使用することは可能ですが、その名前が表示され、ユーザーの壊れやすい肩にそれが気になります。したがって、どのように運命に抵抗しても、グローバルなガバナンス構造とそれへのポインターは、唯一の許容できる信頼できるオプションであると思われます。ポインタが変更されない場合、なぜ関数から関数に渡すのかを尋ねます。しかし、これは初期化関数の呼び出しを保証する唯一の方法であり、ポインターではなく、構造とは関係のない何か、たとえば任意の整数を渡すことができますが、この方法では、ユーザーに初期化関数を呼び出させ、型に対して、結果のタイプが変更されないように、作業の計画に使用します。



上記の考慮事項を考慮して、次のソリューション変更を取得します。

 typedef UARTConfigT *UARTConfigPT; UARTConfigPT UARTConfigInit(void) { static UARTConfigT UARTConfig; UARTConfig.UARTSpeed=UARTSpeed9600; return &UARTConfig; }; UARTConfigPT UARTConfigSpeed(UARTSpeedT UARTSpeed,UARTConfigPT UARTConfigP) { UARTConfigP->UARTSpeed=UARTSpeed; return UARTConfigP; }; int UARTConfigUse(UARTConfigPT UARTConfigP) { return DO_something(); //      };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、アプリケーションは変更されません。

パフォーマンスは大幅に向上します。このための料金は少量のメモリであり、制御構造用に永久に予約されており、ハードウェアの初期化後は不要です。同時に、機器の動作モードを本当に迅速に変更する必要がある場合、そのようなソリューションを適用する可能性が議論の対象になりますが、一般的な標準（ユニバーサルで、したがって非効率的な）ライブラリを使用する可能性は大きな問題です。手。



ところで、高速でメモリフリーの理想的なソリューションは、初期化関数によって返される構造体へのポインタを取得し、それを呼び出しでチェーンに沿って渡すことですが、コンパイラは残酷に私の空想の翼を壊し、演算子＆がL式にのみ適用可能であることを宣言します 一般に、私はこれが何を意味するのか理解していますが、なぜ彼らがそのように私と一緒にいるのか理解していません。残酷。



このような単純なトピックに関する投稿には少なすぎることが判明しましたが、逸脱は多くの場所を占めました。それは思慮深い読者に喜びを与え、最も尊敬される一般人を楽しませるコメントや議論の推進力になると思います。