問題タブ [abi]

重複の可能性:
仮想のオブジェクト サイズ

GCCコンパイラにsizeof（class）が12を出力する理由 誰かが説明しますか？

コンパイラが生成するデフォルトのコンストラクタとデストラクタがインラインであるかどうかに興味があります。どちらの方法でも正当化できるからです。一方では、デフォルトのコンストラクタ/デストラクタをインラインにしないで、後で追加してもABIが破損しないようにします（デフォルトのみが存在するときにコンパイルされたオブジェクトファイルは、定義したものではなく、生成された定義をインライン化するため）。一方、C ++コンパイラがCコンパイラでコンパイルした場合と同様に実行するCコードをコンパイルする場合、割り当てられたすべての構造に対してコンストラクタ/デストラクタ呼び出しを追加することはできません。C++では、クラス間の機能の違いはstructはデフォルトのアクセス保護であると想定されています。たぶんリンカーはこれにどういうわけか対処しますか？たぶん答えはコンパイラによって異なりますか？

この質問の結果：C ++でPOD構造体を使用している場合、デフォルトの代わりに空のインラインコンストラクタ/デストラクタを自分で定義することで、理論的には一部のコンパイラでメリットがありますか？

次のC++コードについて考えてみます。

ここで、このコードがサードパーティアプリケーションによって使用される共有ライブラリに配置されていると仮定します。

私の質問は次のとおりです。X（たとえばint c）の最後に別のメンバーを追加し、で初期化するとfoobar()、を呼び出す既存のアプリケーションはfoobar()壊れますか？これは、ソースの互換性ではなく、バイナリの互換性に関するものであることに注意してください。

ARM プロセッサのバージョンをプログラムで取得する方法はありますか? Google アナリティクスに送信しようとしています。/proc/cpuinfo フォルダーにあると言われましたが、この情報をコードで取得する方法がわかりません。

「楽しみ」のために Windows で x64 アセンブリを学習しています。Windows でのx64 呼び出し規約に関する MSDN ドキュメントには、次のように記載されています。

呼び出し元は、呼び出し先にパラメーター用のスペースを割り当てる責任があり、呼び出し先にそれほど多くのパラメーターがない場合でも、常に 4 つのレジスタ パラメーターに十分なスペースを割り当てる必要があります。これは、C のプロトタイプ化されていない関数と、vararg C/C++ 関数のサポートを簡素化するのに役立ちます。

私の関数は C のプロトタイプ化されていない関数でも varargs C/C++ 関数でもないので、ローカル変数のように、関数内の汎用ストレージに(呼び出し直後の変更されていない値を想定して)いつでも[rsp+8]to を使用できるということですか?[rsp+32]rsp

私は次のようなコードを持っています

私の質問は、C ++ランタイムによって保存される例外オブジェクトはgoto、catchブロックから出たときに解放されますか？または、ランタイムは、周囲の関数またはそのようなものが存在するまで、それをキャッシュすることを許可されていますか？上記のコードを複数回実行する場合、巻き戻しコードを取得するたびに、メモリがリークしないようにしたいだけです（longjmpコンパイラによって生成されたクリーンアップコードが関数プロローグ内またはその前に実行されないため）。

cygwinでAndroidNDKr6bを使用しています（システムは正しく更新されています）。NDKの操作方法を学ぶために、hello-jniサンプルを変更しています。hello-jni（実際には、ndkfoo.cppという単一の.cppファイルを使用してhelloworldというprjを作成しました）サンプルで使用したいC ++で記述されたライブラリがあるため、Eclipseで新しいAndroidプロジェクトを作成しました（ Android用に更新）、jniディレクトリを追加し、Android.mkファイルとApplication.mkファイルを追加し、.cppをコンパイルするためにそれらを編集しました。コンパイルの最後に、.soファイルを取得します。

さて、helloworld Android.mkでは、リンカーにそのライブラリを含めるように指示するために、いくつかの編集を行う必要があります。ライブラリファイルがlibmylib.soであるとすると、次のandroid.mkスクリプトがあります。

LOCAL_PATH：= $（my-dirを呼び出す）

$（CLEAR_VARS）を含める

LOCAL_MODULE：= ndkfoo

LOCAL_SRC_FILES：= ndkfoo.cpp

LOCAL_C_INCLUDES + = $（LOCAL_PATH）/ mylib

LOCAL_LDLIBS + = -L $（LOCAL_PATH）/../../ mylib / libs / armeabi / -lmylib

$（BUILD_SHARED_LIBRARY）を含める

私のディレクトリは次のように構成されています。

（したがって、libmylib.soへのパスはd：/ android / worksheet / mylib / libs / armeabiです）。

残念ながら、これは機能していないようです。mylibへのすべての参照をndkfoo.cppから削除すると、それはコンパイルされ、私の電話でも実行されます。mylibへの参照を削除しないと、コンパイルされますがリンクされません。次の結果が得られます。

D：/android/android-ndk-r6b/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windo ws / bin /../ lib / gcc / arm-linux-androideabi / 4.4.3 / .. / ../../../arm-linux-androideabi/ bin / ld.exe：-lmylibが見つかりません

追伸 helloworldプロジェクトのjniディレクトリでndk-buldを実行していることを忘れました。Pss。私はインターネット上で多くの同様の質問を見つけました。私は常にVisualC/ C ++ IDEを使用しているので、GCCやmakefileなどを初めて使用します...

仮想を含む他の変更が派生クラスで行われた場合でも、クラスのビューの ABI は安定したままですか?

つまり、インターフェイスInterfaceA(多くの純粋仮想関数を持つ抽象クラス) とDerivedBそれを継承するクラスがあるとします。を取る関数を持つライブラリを作成しますInterfaceA *。私が知りたいのは、インターフェイス自体が変更されない限り、インターフェイスがバイナリ互換性を維持しているかどうかです。

明らかに、変更した場合InterfaceA、コードがバイナリ互換であることは期待できません。ただし、単に変更するとどうなるでしょうかDerivedB。つまり、さらにインターフェイスを継承したり、他の仮想関数を追加したりします。極端な言い方をすると、 を定義する別のクラスから多重継承しますInterfaceA。InterfaceAこれらすべての変更にもかかわらず、バイナリ互換性は維持されますか?

今までの私の仮定と経験は、互換性があるということです。これの確認（または互換性がない場合は反論）を探しているだけです。

注: 動的型付けやその他のキャストについては気にしません。インターフェイス関数自体についてのみ気にします。

また、注意: 使用されているコンパイラのバージョンは、全体として ABI が安定していると想定してください。メジャー バージョンの変更はありません。

数か月前、私は 64 ビット Windows を搭載した CPU intel i7-2630qm を搭載したラップトップを手に入れました。このシステムでプログラミング スキルを練習しているときに、整数サイズに関していくつかの違いに遭遇しました。これは、おそらく新しい 64 ビット システムによるものだと思います。

コードを見てみましょう。

Cコード：

質問 ：

201.) この新しいラップトップを入手する前のことを覚えています。つまり、古い 32 ビット システムをまだ使用しているということです%lld。 .

2.)しかし、この現象は、新しいラップトップを使用しているときに発生しなくなりました。代わりに、変数numを type に変更しても、両方の整数が正しく出力されshortます。

3.)それは 64 ビット システム上にありint、引数として使用すると long long に昇格する新しい整数昇格がありますか??または、引数として渡すと 64 ビットにもshort昇格できる整数ですか? long long?

int4.)それに加えて、16ビットシステムでは16ビットであり、32ビットシステムでは32ビットになるという1つのことでかなり混乱しています.しかし、なぜ64にならないのですか? 64ビットの場合はビット??

================================================== ================================ アドオン:

1.)新しいラップトップを使用している間、IDE のプロジェクトとして「コンソール プログラム (64 ビット)」を選択しましたが、32 ビットの古い PC システムでは「コンソール プログラム」を選択しました。

2.)演算子をint使用して「コンソール プログラム (64 ビット)」プロジェクトのサイズを確認したところ、 16ビットのままsizeofで 32 ビットが返されます。通常の 64 ビット サイズ。shortlonglong long

との違いを説明してx86ください。ほとんどの場合、32ビットプログラムはx86で実行されるため、少し混乱します...x32x64x86x32