問題タブ [reinterpret-cast]

Java に移植しようとしている C++ コードがいくつかあります。次のようになります。

何をしているのreinterpret_castですか？

Qtで次のコードを見つけましたが、ここで何が起こっているのか少し混乱しています。

特に何をreinterpret_cast<T>(0)しますか？

誰か説明したいですか？

reinterpret_castのトピックについて書かれた行がたくさんあり、それがどれほど悪いか、特にfstreamからの読み取りや書き込みなどの関数を扱う場合は、それを回避するための最善の方法にまだ戸惑っています。だから、ここに私のジレンマがあります...

ファイルからのデータを入力したい整数配列があるとしましょう。

いくつかの異なるキャストで読むことができます：

最初のもの（Cスタイル）は時代遅れであり、正当な理由でC++で導入された新しいスタイルのキャストです。2つ目は移植性がなく、保証はありません。3つ目は、書くのが面倒で、楽しみを台無しにします。

これに代わるものはありますか？どうすればよいですか？

編集：

目標は、コードを可能な限り移植可能で標準に準拠するようにすることです。

クラス PointsList の 1 つのオブジェクトを別のオブジェクト Points3DList (およびその逆) にキャストしたいと思います。

と

Point と Point3D の間には何の関係もありません (継承も構成も)...

コンバージョンについてどう思いますか

ここで、pl3D は Points3DList オブジェクトへのポインターを表します。この場合のデータモデルは変更できません...

私は当時、reinterpret_cast<>それをどのように使用すべきかについて多くのことを読んできました（そしてほとんどの場合、それを避けてください）。

reinterpret_cast<>to を使用して from をキャストすることは理解していますが、 unsigned char*tochar*は実装で定義されている(したがって非移植性) であり、一方を他方に効率的に変換する方法は他にないようです。

unsigned char*いくつかの計算を処理するために扱うライブラリを使用するとしましょう。内部的には、私はすでにchar*自分のデータを保存するために使用しています（変更すると子犬が殺されるため、変更できません）。

私は次のようなことをしたでしょう：

コードの移植性を高めたい場合は、最初にデータをコピーするしかないようです。何かのようなもの：

もちろん、それは非常に最適ではなく、最初のソリューションよりも移植性が高いかどうかさえわかりません。

問題は、移植性の高いコードを作成するには、この状況で何をするかということです。

親クラス：

派生クラス：

クラスPointsListの1つのオブジェクトを別のオブジェクトPoints3DTopoListにキャストしたいと思います（またはその逆）。

そのような変換は許可されていますか？

そして逆変換？

各Point3TopoのFaceポインターは、NULLに初期化されますか、それとも未定義になりますか？

C++ Without Fear: A Beginner's Guide That Makes You Feel Smart本の(8) 章では、次のことが言及されています。reinterpret_cast

....あるポインター型 (int ) から別の型 (char*) に変換します。キャストは、指し示すデータが解釈される方法を変更するため、static_cast とは対照的に、reinterpret_cast と呼ばれます。

ここでこの段落について説明できますか? 特に作戦名の理由は？

ありがとう。

このプログラムの実行中:

次の出力が得られました。

4202656

この数字は何を表しているでしょうか？メモリアドレスですか？でも、何のメモリアドレス？「abc」は文字の配列としてメモリに格納されていませんか?

ありがとう。

にキャストA*したいchar*場合とその逆の場合、2 つの選択肢があります (つまり、私たちの多くは 2 つの選択肢があると考えています。どちらも機能しているように見えるためです!したがって、混乱が生じます!):

どちらも正常に動作します。

これでもうまくいきます！

では、連鎖した 2 つのジョブが機能するのに、なぜreinterpret_castC++ にあるのでしょうか。 static_cast

このトピックは、この投稿の下部にリストされているような以前のトピックと重複していると考える人もいるかもしれませんが、そうではありません。これらのトピックは理論的にしか議論していませんが、 が本当に必要な理由を示す例を 1 つも示していません。1 つの static_cast が失敗することに同意します。しかし、2つではどうですか？reintepret_cast static_cast

2 つのチェーンの構文static_castが面倒に見える場合は、関数テンプレートを記述して、プログラマーにとってより使いやすくすることができます。

そして、これを次のように使用できます。

any_castまた、役立つ可能性があるこの状況を参照してください: fstream 読み取りおよび書き込みメンバー関数の適切なキャスト。

だから私の質問は基本的に、

• なぜreinterpret_castC++にあるのですか?
• 連鎖した2つ static_castが同じ仕事を確実に失敗する例を1つでも教えてください。

• 使用するキャスト。static_cast または reinterpret_cast?
• Void* から TYPE*​​ へのキャスト: static_cast または reinterpret_cast

の使用reinterpret_castに関する以前のさまざまな質問を読みました。また、C++標準の関連する文言も読みました。基本的に、ポインタからポインタへの操作の結果は、元のポインタ型にキャストバックする以外の目的reinterpret_castには安全に使用できないということになります。

ただし、実際には、のほとんどの実際の使用法は、aがCスタイルのキャストと同じでreinterpret_castあるという（間違った）仮定に基づいているようです。reinterpret_castたとえば、文字セット変換ルーチンの目的でreinterpret_castからにキャストするために使用するchar*コードをたくさん見てきました。unsigned char*これは完全に無害ですが、厳密に言えば移植性はありません。ポインタを逆参照しようとしたときにfromtoがプログラムをクラッシュさせないreinterpret_castというchar*保証はありません。unsigned char*unsigned char*

標準によれば、ポインタから整数への変換、およびその逆の変換が実際に保証されている 他の唯一の実際の使用法のようです。reinterpret_cast

それでも、異なるポインタ型間で安全に変換したい（そしてできるはずの）多くの場合があります。例：uint16_t*新しいC ++ 0xchar16_t*へのポインタ、または実際には元の型と同じサイズ/配置である基本データ型へのポインタ。しかしreinterpret_cast、これが機能することを保証するものではありません。

質問：char*ポインタ間で、同じサイズ/配置の基本データ型（ ->など）に安全に変換するにはどうすればよいunsigned char*ですか？これreinterpret_castが実際に機能することを保証していないようですが、ここではCスタイルのキャストが唯一の安全なオプションですか？