問題タブ [unsafe]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c# - 列挙型で安全でない値を使用するにはどうすればよいですか?
この列挙型をC#アプリケーションで使用する必要がありますが、これらの値を使用できません。タイプをuintとして指定すると、-1の値を使用でき、intを指定すると、最後の2つの値を使用できません。ここでチェックされていないキーワードを使用して、これらすべての値を定義できるようにする方法はありますか?これらの値は外部ソースからのものであるため、変更できません。
c# - 小規模で集中的なタスクの場合、C#をC ++のパフォーマンスにどれだけ近づけることができますか?
私は、C ++とC#の速度の違いは、主にC#がJITコンパイラーによって取り込まれるバイトコードにコンパイルされること(それは正しいですか?)とC#が行うすべてのチェックについて考えていました。
unsafeコンパイルオプションと、安全でないコードを共通言語ランタイムで検証できないためにキーワードを使用することの両方で、これらの関数の多くをオフにすることが可能であることに気付きました。
したがって、両方の言語で単純なコンソールアプリケーションを作成し、それが架空のコインを無限に反転させ、10,000回程度の反復ごとに結果を画面に表示した場合、速度の違いはどのくらいになるでしょうか。とてもシンプルなプログラムなので、これを選びました。
これをテストしたいのですが、C ++がわからないか、コンパイルするためのツールがありません。これは私のC#バージョンです:
コードのセクションを意図的に「安全でない」コンパイルしたり、オーバーフローチェックなどのコンパイルオプションの一部が有効になっていないDLLにコンパイルしたりするのに十分な違いはありますか?それとも、C ++でセクションをコンパイルすることが有益であるという逆の方向に進みますか?その時も相互運用速度が関係してくると思います。
主観を避けるために、私はこの質問の特定の部分を次のように繰り返します。
- C#には、安全でないコードを使用することでパフォーマンスが向上しますか?
- オーバーフローチェックを無効にするなどのコンパイルオプションはパフォーマンスを向上させ、安全でないコードに影響を与えますか?
- 上記のプログラムはC++で高速ですか、それとも無視できるほど異なりますか?
- C ++などの言語で長時間集中的な数値計算タスクをコンパイルしたり、ボーナスとして/ unsafeを使用したりする価値はありますか?主観的ではありませんが、これを行うことで集中的な操作をより速く完了することができますか?
c# - C#の安全でない構造体にポインターの配列を配置できない根本的な理由は何ですか?
CのようにC#の安全でない構造体の中に子構造体へのポインターの配列を置くことができれば、ノードごとに1つのオブジェクトを持つというオーバーヘッドなしに複雑なデータ構造を構築する方がはるかに簡単で、時間の浪費も少なくなります。構文的にクリーンで、はるかに読みやすくなっています。
安全でない構造体内の固定配列が「値型」でのみ構成され、ポインターでは構成されないというアーキテクチャ上の深い理由はありますか?
構造体内に明示的に名前が付けられたポインターのみを使用することは、言語を弱めるための意図的な決定である必要があると思いますが、これがなぜそうなのか、または構造体内にポインター配列を許可しない理由についてのドキュメントは見つかりません。コレクターは、安全でないとマークされた構造体で何が起こっているかを気にする必要はありません。
Digital MarsのDは、構造体とポインターを比較してエレガントに処理します。簡潔データ構造を迅速に開発できないことを私は見逃しています。参照をC#で抽象化することにより、少なくともマーケティングの意味ではポインターがまだ存在しているにもかかわらず、言語から多くの力が取り除かれているように見えます。
複雑なデータ構造を時間の経過とともに効率的に表現する上で、言語がより強力になると期待するのは間違っているかもしれません。
c# - 安全でないコードブロックが安全なコードよりも遅いのはなぜですか?
ビデオフレームを適切に処理するコードを書き込もうとしています。フレームをとして受け取っていSystem.Windows.Media.Imaging.WriteableBitmapます。テストの目的で、BGRA形式の画像を処理し、BGRピクセルの平均に基づいて各ピクセルを黒または白に割り当てる単純なしきい値フィルターを適用しています。
これが私の「安全な」バージョンです:
これが、安全でないコードブロックとフォアバッファーの代わりにWriteableBitmapバックバッファーを使用した直接変換であると私が思うものです。
これは、安全でないコードブロックとポインターへの私の最初の進出であるため、ロジックが最適ではない可能性があります。
以下を使用して、同じWriteableBitmapsで両方のコードブロックをテストしました。
だから私は同じ画像を分析しています。ビデオフレームの着信ストリームのテスト実行:
安全でないバージョンが常に遅いのはなぜですか?バックバッファを使用しているためですか?それとも私は何か間違ったことをしていますか?
ありがとう
c# - アンセーフ コードでポインタに代入する場合、null と 0 の間に違いはありますか?
これは奇妙に思えるかもしれませんが、C では (size_t)(void*)0 == 0 は言語仕様によって保証されていません。コンパイラは、null に任意の値を使用できます (ほとんどの場合、0 を使用しますが)。
C# では、アンセーフ コードで null または (T*)0 をポインターに割り当てることができます。
- 違いはありますか?
- (long)(void*)0 == 0 (保証されているかどうか? 別の言い方をすると: IntPtr.Zero.ToInt64() == 0)
MSDN は、IntPtr.Zero について次のように述べています。
「このフィールドの値はヌルと同等ではありません。」C コードとの互換性を維持したい場合、それは非常に理にかなっています。C ヌル ポインターに変換されなければ、相互運用性には意味がありません。しかし、IntPtr.Zero.ToInt64() == 0 が内部的に IntPtr.Zero である場合でも、可能な場合があるかどうかを知りたいです (CLR は、キャスト操作で null を 0 に変換する場合としない場合があります)。
この質問の複製ではありません
c# - Reflector の分解をコンパイル可能なコードに変換するのに役立ちます
だから私はいくつかのフレームワーク2.0コードをReflectorしていますが、次の分解になります
これは ' The right hand side of a fixed statement assignment may not be a cast expression' のためコンパイルされません
Reflector は概算しかできないことを理解しており、通常は明確なパスを確認できますが、これは私の経験から少し外れています。
質問: Reflector は私に何を説明しようとしていますか?
アップデート:
以下も見ています
アップデート:
したがって、Mitch が言うように、これはビット単位の演算子ではなく、addressOf 演算子です。
質問は次のとおりです。
Cannot implicitly convert type 'xxx*' to 'System.IntPtr*'. An explicit conversion exists (are you missing a cast?)' ' コンパイル エラーで失敗します。
だから私はそうするならのろわれ、そうしなければのろわれたように見えました。何か案は?
アップデート:
私はそれを考え出したと思います。たまたま、使用していた式に戻ってvoid*キャストを削除すると、VS は文句を言うのをやめました。この会話の参加者から同等のものを集めたので、void*単純intptr*にそれらを交換した結果、次のようになりました。
そしてVSは不平を言うのをやめました。誰かがそれを確認できますか
と同等です
?
c# - ループ内の New 構造体のアドレスを変更するにはどうすればよいですか?
C# でリンク リストを使用した多項式に関する単純なプログラムを作成しています。私が抱えている問題は、for ループで新しい構造体 (ノード) を作成するたびに、前のノードが指定されたのと同じアドレスを指定することです。どうすれば修正できますか?ここに私の構造体があります:
そして、問題が発生する場所は次のとおりです。
でも&q相変わらず!
アップデート:
さらに明確にするために、完全なコードを次に示します。
私たちの教授は私たちに C でそれを行うように頼んだが、C# で行うことに決めたが、実際に C を使用する人はもう誰もいないので、C の外観を与えることにした。
c# - 0〜65535の最初のメモリアドレスのヌル参照
メモリについてもう少し理解したいのですが、Googleからメモリを見つけることができませんでした。これがばかげた質問である場合は、ご容赦ください。
次のコードで、C#のメモリアドレス0(および最大65535)にアクセスすると、NullReferenceExceptionがスローされるのはなぜですか。
バイト*ポインタ=(バイト*)0;
バイトテスト=*ポインタ;
よろしくお願いします!
c# - 固定サイズのバッファ(配列)が安全でない必要があるのはなぜですか?
7バイト(または3または777)の値型が必要だとします。
私はそれを次のように定義することができます:
それを定義するより簡単な方法は、固定バッファーを使用することです
もちろん、2番目の定義はもっと簡単です。問題は、固定バッファーに提供する必要のある安全でないキーワードにあります。これはポインタを使用して実装されているため、安全ではないことを理解しています。
私の質問は、なぜそれが安全でなくてはならないのかということです。C#が任意の定数長配列を提供し、C#参照型配列または安全でないバッファーにするのではなく、それらを値型として保持できないのはなぜですか?