タグ付けされた質問 「abi」

5
C ++標準では、初期化されていないブールがプログラムをクラッシュさせることを許可していますか?
C ++の「未定義の動作」により、コンパイラーが必要なことをほとんど実行できることがわかっています。しかし、コードが十分に安全であると思っていたので、驚いたクラッシュがありました。 この場合、実際の問題は、特定のコンパイラを使用する特定のプラットフォームでのみ、最適化が有効になっている場合にのみ発生しました。 問題を再現し、それを最大限に簡略化するために、いくつかのことを試みました。Serializeこれはと呼ばれる関数の抜粋です。これはboolパラメータを取り、文字列trueまたはfalse既存の宛先バッファにコピーします。 この関数はコードレビューに含まれますか?実際には、ブールパラメーターが初期化されていない値である場合にクラッシュする可能性があることを伝える方法はありませんか? // Zero-filled global buffer of 16 characters char destBuffer[16]; void Serialize(bool boolValue) { // Determine which string to print based on boolValue const char* whichString = boolValue ? "true" : "false"; // Compute the length of the string we selected const size_t len = strlen(whichString); …

16
アプリケーションバイナリインターフェイス(ABI)とは何ですか?
私はABIが何であるかを明確に理解したことがありません。ウィキペディアの記事を紹介しないでください。理解できたらここまでそんなに長い投稿はしないでしょう。 これは、さまざまなインターフェイスに関する私の考え方です。 テレビのリモコンは、ユーザーとテレビの間のインターフェースです。これは既存のエンティティですが、それ自体では役に立ちません(機能を提供しません)。リモコンのこれらの各ボタンのすべての機能は、テレビに実装されています。 インターフェース:それは間の「既存のエンティティ」層であり、 functionalityかつconsumerその機能の。インターフェイス自体は何もしません。背後にある機能を呼び出すだけです。 ユーザーが誰であるかに応じて、さまざまなタイプのインターフェースがあります。 コマンドラインインターフェイス(CLI)コマンドは既存のエンティティであり、コンシューマがユーザーであり、機能は背後にあります。 functionality: 私たちがこのインターフェースを説明しているいくつかの目的を解決する私のソフトウェア機能。 existing entities: コマンド consumer: ユーザー グラフィカルユーザーインターフェイス(GUI)ウィンドウ、ボタンなどは既存のエンティティであり、コンシューマがユーザーであり、機能は背後にあります。 functionality: このインターフェイスについて説明している問題を解決するソフトウェア機能。 existing entities: ウィンドウ、ボタンなど consumer: ユーザー アプリケーションプログラミングインターフェイス(API)関数(またはより正確には)のインターフェイス(インターフェイスベースのプログラミングの場合)は既存のエンティティであり、コンシューマーはユーザーではなく別のプログラムであり、機能はこのレイヤーの背後にあります。 functionality: このインターフェイスについて説明している問題を解決するソフトウェア機能。 existing entities: 関数、インターフェイス(関数の配列)。 consumer: 別のプログラム/アプリケーション。 Application Binary Interface(ABI)ここからが私の問題の始まりです。 functionality: ??? existing entities: ??? consumer: ??? ソフトウェアをさまざまな言語で作成し、さまざまな種類のインターフェース(CLI、GUI、API)を提供しましたが、ABIを提供したことがあるかどうかはわかりません。 ウィキペディアは言う: ABIは次のような詳細をカバーします データ型、サイズ、および配置。 関数の引数の受け渡し方法と戻り値の取得方法を制御する呼び出し規約。 システムコール番号、およびアプリケーションがオペレーティングシステムに対してシステムコールを行う方法。 他のABIは次のような詳細を標準化します C ++名のマングリング、 例外の伝播、および …

9
APIとABIの違い
私は、Linuxシステムのプログラミングに新しいですし、読みながら、私はAPIとABIに出くわした のLinuxシステムプログラミングを。 APIの定義: APIは、あるソフトウェアがソースレベルで別のソフトウェアと通信するためのインターフェースを定義します。 ABIの定義: APIがソースインターフェイスを定義するのに対し、ABIは特定のアーキテクチャ上の2つ以上のソフトウェア間の低レベルのバイナリインターフェイスを定義します。これは、アプリケーションがそれ自体と相互作用する方法、アプリケーションがカーネルと相互作用する方法、およびアプリケーションがライブラリと相互作用する方法を定義します。 プログラムはソースレベルでどのように通信できますか?ソースレベルとは何ですか?とにかくそれはソースコードに関連していますか?または、ライブラリのソースがメインプログラムに含まれていますか? 私が知っている唯一の違いは、APIは主にプログラマーによって使用され、ABIは主にコンパイラーによって使用されることです。
192 api  abi 

10
ポインタを渡すのではなく、Cで構造体を値で渡すことの欠点はありますか?
ポインタを渡すのではなく、Cで構造体を値で渡すことの欠点はありますか? 構造体が大きい場合、明らかに大量のデータをコピーするパフォーマンスの側面がありますが、構造体が小さい場合、基本的には、いくつかの値を関数に渡すことと同じです。 戻り値として使用すると、さらに興味深いかもしれません。Cには関数からの戻り値が1つしかありませんが、多くの場合、いくつか必要です。簡単な解決策は、それらを構造体に入れて返すことです。 これには賛成または反対の理由がありますか? ここで私が話していることは誰にとっても明白ではないかもしれないので、簡単な例を挙げます。 Cでプログラミングしている場合は、遅かれ早かれ次のような関数の記述を開始します。 void examine_data(const char *ptr, size_t len) { ... } char *p = ...; size_t l = ...; examine_data(p, l); これは問題ではありません。唯一の問題は、すべての関数で同じ規則を使用するために、パラメーターの順序を同僚に同意する必要があることです。 しかし、同じ種類の情報を返したい場合はどうなりますか?通常は次のようになります。 char *get_data(size_t *len); { ... *len = ...datalen...; return ...data...; } size_t len; char *p = get_data(&len); これは正常に機能しますが、はるかに問題があります。戻り値は戻り値ですが、この実装ではそうではありません。上記から、関数get_dataがlenが指すものを見ることが許可されていないことを知る方法はありません。そして、値がそのポインタを通じて実際に返されることをコンパイラにチェックさせるものは何もありません。だから来月、誰かがコードを正しく理解せずにコードを変更すると(彼はドキュメントを読んでいないため)、だれにも気付かれずにコードが壊れるか、ランダムにクラッシュし始めます。 だから、私が提案する解決策は単純な構造です struct blob { char …



4
DLLとの間でオブジェクト、特にSTLオブジェクトを安全に渡すにはどうすればよいですか?
C ++ DLLとの間でクラスオブジェクト、特にSTLオブジェクトを渡すにはどうすればよいですか? 私のアプリケーションはDLLファイルの形式でサードパーティのプラグインとやり取りする必要があり、これらのプラグインがどのコンパイラでビルドされるかを制御できません。STLオブジェクトの保証されたABIがないことを承知しており、アプリケーションを不安定にすることを心配しています。
106 c++  windows  dll  stl  abi 


3
C ++ 17、C ++ 14、およびC ++ 11オブジェクトをリンクしても安全ですか
3つのコンパイル済みオブジェクトがあり、すべて同じコンパイラ/バージョンで生成されているとします。 AはC ++ 11標準でコンパイルされました BはC ++ 14標準でコンパイルされました CはC ++ 17標準でコンパイルされました 簡単にするために、すべてのヘッダーがC ++ 11で記述されており、3つの標準バージョン間でセマンティクスが変更されていない構成体のみを使用しているため、相互依存関係がヘッダーインクルードで正しく表現され、コンパイラーが異議を唱えなかったとします。 これらのオブジェクトのどの組み合わせがそれであり、単一のバイナリにリンクするのは安全ではありませんか?どうして? 編集:主要なコンパイラ(gcc、clang、vs ++など)に関する回答を歓迎します
97 c++  c++11  linker  c++14  abi 

4
T *をレジスタに渡すことができるのに、unique_ptr <T>はできないのはなぜですか?
私はCppCon 2019でチャンドラー・カルースの講演を見ています: ゼロコストの抽象化はありません その中で、彼は、std::unique_ptr&lt;int&gt;over を使用することによって生じるオーバーヘッドの大きさに驚いた様子の例を示していint*ます。そのセグメントは、およそ17:25の時点で始まります。 彼のサンプルのスニペットのペア(godbolt.org)のコンパイル結果を確認できます。実際、コンパイラーがunique_ptr値を渡そうとはしていないようです。ただのアドレス-レジスタ内、ストレートメモリ内のみ。 Carruth氏が27:00頃に指摘する点の1つは、C ++ ABIが値渡しパラメーター(すべてではないが、一部ではない可能性があります。レジスター内ではなく。 私の質問: これは実際には一部のプラットフォームでのABI要件ですか?(どれですか?)または、特定のシナリオでの悲観化に過ぎないのでしょうか? なぜABIはそのようなのですか?つまり、構造体/クラスのフィールドがレジスター内、または単一のレジスター内に収まる場合、なぜそのレジスター内で渡すことができないのでしょうか? C ++標準委員会は、この点について近年、またはこれまでに議論しましたか? PS-この質問をコードなしで残さないように: 単純なポインタ: void bar(int* ptr) noexcept; void baz(int* ptr) noexcept; void foo(int* ptr) noexcept { if (*ptr &gt; 42) { bar(ptr); *ptr = 42; } baz(ptr); } 一意のポインタ: using std::unique_ptr; void bar(int* ptr) noexcept; void baz(unique_ptr&lt;int&gt; …

1
スタックメモリが使用されていないときに割り当てられるのはなぜですか?
次の例を考えてみます。 struct vector { int size() const; bool empty() const; }; bool vector::empty() const { return size() == 0; } 生成されたアセンブリコードvector::empty(clangによる最適化あり): push rax call vector::size() const test eax, eax sete al pop rcx ret なぜスタックスペースを割り当てるのですか?一切使用しておりません。省略することができます。MSVCとgccの最適化ビルドもこの関数にスタックスペースを使用するため(godboltを参照)、理由があるはずです。pushpop
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.