問題タブ [unboxing]

私は参照型にのみ適用できる拡張メソッドに取り組んでいます。ただし、現在は値のボックス化とボックス化解除を行っていると思います。どうすればこれを回避できますか？

使用例：

いくつかの方法で：

Haskell のベクトル ライブラリを使用して行列 (完全または疎) を効率的に操作したいと考えています。

ここにマトリックスタイプがあります

ご覧のとおり、行列はボックス化されていないベクトルのベクトルです。今、ベクトルと行列の間で内積をしたいと思います。sum、zip、および map を組み合わせることで、かなり簡単に実行できます。

しかし、これを行うと、行列の行を介してマッピングしているため、ボックス化されていない場合でも、結果はボックス化されたベクトルになります。

ボックス化されていないベクトルを結果として効率的に取得するにはどうすればよいですか?

I'm trying to figure out syntax that supports unboxing an integral type (short/int/long) to its intrinsic type, when the type itself is unknown.

Here is a completely contrived example that demonstrates the concept:

In each case, the integral types are consistent, so there should be some form of syntax that says "the object contains a simple type of X, return that as X (even though I don't know what X is)". Because the objects ultimately come from the same source, there really can't be a mismatch (short != long).

I apologize for the contrived example, it seemed like the best way to demonstrate the syntax.

Thanks.

参照: http://java.sun.com/j2se/1.5.0/docs/guide/language/autoboxing.html

「あなたのプログラムが null を autounbox しようとすると、NullPointerException がスローされます。」

ブール値に null を代入しようとすると、javac はコンパイル時エラーを出します。理にかなっています。ただし、ブール値に null を割り当てることは問題ありません。も意味があると思います。

しかし、null を autounbox しようとすると NPE が発生するという事実について考えてみましょう。これが意味することは、null チェックまたは例外処理なしでは、ブール値に対してブール演算を安全に実行できないということです。整数に対して数学演算を行う場合も同様です。

長い間、私は Java1.5+ のオートボクシングのファンでした。なぜなら、Java が真のオブジェクト指向に近づいたと思ったからです。しかし、昨夜この問題に遭遇した後、私はこれがひどいと思うと言わざるを得ません. 初期化されていないプリミティブを使用しようとすると、コンパイラがエラーを出すのは良いことです。それを失った場合、オートボクシングを使用したくありません。

オートボクシングのポイントを誤解している可能性があると思いますが、同時に、ブール値が 3 つの値を持つことができるべきであることを決して受け入れません。誰でもこれを説明できますか？私は何を得ていないのですか？

私は2つのオブジェクトを持っています。オブジェクト A とオブジェクト B。

オブジェクト A は、いくつかの XSD ファイルから生成されたクラスのインスタンスです。xsd.exe /c を使用してコンパイルしました。これで、新しいオブジェクトができました。

また、オブジェクト A に非常によく似たものを返す Web サービスもあります。したがって、現在、次のようなものがあります。

やりたいことはこれ

しかし、これはあまり好きではありません。「暗黙的に MyFramework.foo[] を WebService.foo[] に変換できません」と言う

これを解決する方法についてのアイデアはありますか? オブジェクトは非常に大きく、基本的に同じです。

私の ASP.Net アプリのデータ層は、ストアド プロシージャを呼び出して、ログイン時に訪問者に関する少量 (1 レコード) の情報を取得します。電話番号を渡すと、sproc は単純な SELECT を使用して 5 つのフィールドを返します。最初のフィールドは主キーである BIGINT です。私のデータ層は DataRow を取得し、それを使用してデータ オブジェクトを作成しようとします。データ オブジェクトで、主キーを表すプロパティは Int64 です。それは次のようになります。

私が見つけたのは、88698 などの大きな主キー値がある場合、すべてがうまく機能することです。ただし、999 などの小さな値を取得すると、セットアップしようとすると「指定されたキャストは無効です」というエラーが表示されます。その主キー プロパティ。イミディエイト ウィンドウで試してみると、次のようになります。

型指定されたデータセットに頼らずに、ここで何が間違っているのでしょうか?

私はこのMSDNMagazineの記事で、著者は次のように述べています（私の強調）：

ボックス化は常に新しいオブジェクトを作成し、ボックス化されていない値のビットをオブジェクトにコピーすることに注意してください。一方、ボックス化を解除すると、ボックス化されたオブジェクト内のデータへのポインタが返されます。メモリコピーは発生しません。ただし、通常、コードによって、ボックス化されていない参照が指すデータがコピーされます。

太字にした文とそれに続く文に戸惑います。このMSDNページを含め、私が読んだ他のすべてのことから、ボックス化解除がヒープ上の値へのポインターを返すだけだと聞いたことはありません。開梱すると、最初と同じように、スタック上の値のコピーを含む変数が作成されるという印象を受けました。結局のところ、変数に「ヒープ上の値へのポインター」が含まれている場合は、値の型がなく、ポインターがあります。

誰かがこれが何を意味するのか説明できますか？作者はひび割れていましたか？（記事には他に少なくとも1つの明白なエラーがあります）。そして、これが真実である場合、「コードによって、ボックス化されていない参照が指すデータがとにかくコピーされる」場合はどうなりますか？

この記事は10年近く前のものであることに気づきました。おそらく、これは.Netの初期の段階で変更されたものかもしれません。

私は次のコードを取得しました：

出力は次のとおりです。

なぜ両方ではないのSystem.Objectですか？

私は次の拡張メソッドを作成しました...

...たとえば、次のようにデータを読み取るために使用します：

しかし、ボックス化された値からnull許容列挙型にキャストしたい場合は機能しません。私が思いつくことができた最高のものはこれでした（うまくいかない乱雑なWIPコード）：

使用法：

Int32 を null 許容列挙型にキャストしようとすると、現在のエラーは InvalidCastException になります。どちらがいいと思いますが、他にどのようにできるかわかりませんか? nullable enum T のインスタンスを作成してそれに値を割り当てようとしましたが、これをどのように正確に行うことができるかについて行き詰まっています。

これを解決するためのアイデアやより良い方法はありますか? それを一般的な方法で解決することさえ可能ですか？私はそれについてかなり多くの検索を行いましたが、有用なものは何も見つかりませんでした。

Brainfuck コードを解析して実行する小さなスクリプトを作成しようとしています。最適化の GHC オプションを理解するために、コードを最適化して、少し高速化し、そこで何が起こっているのかを理解しようとしています。

パーツの 1 つは BF コードの内部表現です。これには特別なデータ型を使用します。ソースコードは次のとおりです。変換を行う 2 つの関数が含まれています。

アイデアは、コードが何らかの入力 (文字列) から読み取られ、上記のコードによって事前に解析および単純化されてから、他の関数によって実行されるというものです。(入力が有効であると仮定します)。

この例を最適化するために、次のような domething を実行して、コンストラクターMovePointerとコンストラクターの Int パラメーターをアンボックスしようとしました。AdjustValue

これにより、ボックス化された型が、GHcの実装の詳細であるボックス化Intされていない生の型に変わります。Int#私が読んだように、このオプションはいくつかの場合にのみ有効です。そのため、この種の最適化を実行する場合、どの点に注意する必要があるかを尋ねたいと思います。私の目標は、Haskell の利点を利用して BF コードを実行できるようにすることです。