問題タブ [pointer-aliasing]

このコードを考慮すると、VC9はエイリアシングを検出しません：

明らかな修正は、一時的なものを使用することです：

これは標準的な動作ですか？私は、コンパイラーが、そのように言われない限り、両方のポインターがおそらくエイリアス化されていると想定することを期待していました。

Beej の Guide to Networking を使用していて、エイリアシングの問題に遭遇しました。彼は、特定の構造体の IPv4 または IPv6 アドレスを返す関数を提案しています。

これにより、GCC は 3 行目のsaに対して厳密なエイリアス エラーを吐き出します。私が理解しているように、この関数を次のように呼び出しているためです。

エイリアシングは、their_addr変数の型sockaddr_storageが異なり、別の型の別のポインターが同じメモリを指しているという事実に関係していると思います。

sockaddr_storageこのくっついている、sockaddr_in、およびを回避する最善の方法はありsockaddr_in6ますか? これはネットワーキングの分野でよく使われているように思えますが、ベスト プラクティスの良い例が見つかりません。

また、エイリアシングの問題がどこで発生するかを正確に説明できる人がいれば、非常にありがたいです。

これと同じような容器があります。

Elt がデフォルトのコンストラクターを持っているという要件を削除したかったのです。

私は g++-4.3 を使用していますが、このコードは以前のアプリケーションよりも25% 遅く動作します。残念ながら、速度低下は合成ベンチマークでは現れません。コンパイラの最適化、エイリアシング、アライメント、または同様のものに関するものだと思います。

パフォーマンスを取り戻すにはどうすればよいですか？（デフォルトのコンストラクターは必要ありませんが）

アップデート：

ちょうど今、新しい g++-4.4 を試してみたところ、後者のコードに対して次の警告が表示されました。

"Strict"、"Typed"、"Restricted"、および"Disjointed"エイリアシングの違いは何ですか?

「バリアント型オブジェクト」を実装するために数年間正常に使用しているコードがいくつかあります。つまり、さまざまなタイプの値を保持できるC ++オブジェクトですが、可能なタイプの中で最大のものと同じだけのメモリを（およそ）使用します。このコードは、POD以外のデータ型もサポートしていることを除けば、タグ付き共用体と精神的に似ています。これは、charバッファー、配置new / delete、およびreinterpret_cast<>を使用してこの魔法を実現します。

最近、gcc 4.4.3（-O3と-Wallを使用）でこのコードをコンパイルしようとしましたが、次のような警告がたくさん表示されました。

私が読んだことから、これはgccの新しいオプティマイザが「バギー」コードを生成する可能性があることを示しています。これは明らかに避けたいものです。

以下にコードの「おもちゃバージョン」を貼り付けました。非PODデータ型をサポートしながら、gcc 4.4.3でコードをより安全にするために、コードに対してできることはありますか？最後の手段として、いつでも-fno-strict-aliasingを使用してコードをコンパイルできることは知っていますが、最適化の下で壊れないコードがあると便利なので、そうはしません。

（コードベースにboostまたはC ++ 0Xの依存関係を導入することは避けたいので、boost / C ++ 0Xソリューションは興味深いものですが、もう少し古風なものを好むことに注意してください）

これらのクラスがあるとします：

パフォーマンス上の理由から、メモリにぎっしりと詰め込みたいと思います (ただし、設計の柔軟性を失いたくありません)。したがって、「パックされた」構造と、新しい B インスタンスを透過的に返すファクトリを作成できます。

問題は、参照カウントが 2 であるため、この "car" インスタンスが破棄されないことです。死ぬと、参照カウントは永遠に 1 になります。内部の shared_ptr を使用し続けて (必要に応じて「アンパックされた」参照に属性を付けることができるように)、このパックされた構造を作成するより良い方法を知っていますか?

アップデート

engineno-op デリータを使用することもできますが、 を保持して を保持しない場合は非常に危険ですcar。

IRCについて誰かと話し合ったところ、この質問が出てきました。標準では、型のオブジェクトを左辺値で変更することが許可されていintますchar。

位置合わせが正常であることがわかっている場合、これを反対方向に実行することは許可されますか？

私が見ている問題は、エイリアシングルールを非対称関係と見なす場合、エイリアシングルールが次の単純なケースをカバーしていないことです。

その理由は、各オブジェクトに一連のsizeof(obj) unsigned charオブジェクト（「オブジェクト表現」と呼ばれる）が含まれているためです。を変更するintと、それらのオブジェクトの一部またはすべてが変更されます。ただし、エイリアシングルールではint、charまたはを変更することは許可されているだけで、その逆は許可されてunsigned charいません。もう一つの例

3.10 / 15（「...を含む集合体または共用体型」）では一方向のみが記述されますが、今回は逆の方向（「要素または非静的データメンバー型である型）が必要です。集計..."）。

他の方向が暗示されていますか？この質問はCにも当てはまります。

g ++は__restrict__ポインターを実装しますが、イテレーターについては何も見つかりませんでした。私の全体的な目的は、コンパイラーにstlループをベクトル化するように促すことです。

編集：

コンパイラーがベクトル化できない場合でも、__restrict__キーワードは、ループ内で不要なリロードが不要であることをコンパイラーに通知できる必要があります。

期待どおりに動作する次のコードがあります。

少し変更しても、まだ機能します。

今問題：

b is a[2] * 2なぜこれがFalseを返すのにTrueを返すのか、誰か説明してもらえますか?

Javaでエイリアシングをどのように処理しますか? 簡単な解決策は、たとえば ArrayList のコピーを作成することですが、コードを記述しようとすると、新しく追加されたデータによってデータが上書きされ続けます。詳細に：

出力：

それ以外の：