10

uint確かに、符号なし整数 ( ) と符号付き整数 ( ) の基本的な違いは知っていますint。

Length.NET パブリック クラスでは、呼び出されたプロパティが常に符号付き整数を使用していることに気付きました。

おそらくこれは、符号なし整数が CLS に準拠していないためです。

ただし、たとえば、私の静的関数では:

public static double GetDistributionDispersion(int tokens, int[] positions)

のパラメーターtokensとすべての要素をpositions負にすることはできません。負の場合、最終結果は役に立ちません。したがって、 forとのint両方を使用すると、この関数が呼び出されるたびに値をチェックする必要があり (そして、意味のない値を返すか、負の値が見つかった場合は例外をスローする???)、面倒です。tokenspositions

uintでは、両方のパラメーターに使用する必要があります。これは本当に理にかなっています。

しかし、多くのパブリック API と同様に、ほとんど常にint. それは、実装内で、各値の負性を常にチェックすることを意味しますか (負でないことが想定されている場合)?

では、一言で言えば、どうすればよいのでしょうか。

2つのケースを提供できます：

  1. この関数は、私自身のソリューションでのみ呼び出されます。
  2. この関数は、他のチームの他のメンバーによってライブラリとして使用されます。

これら 2 つのケースに異なるスキームを使用する必要がありますか?

ピーター

PS: 私は多くの調査を行いましたが、使用しないように説得する理由はまだありませんuint:-)

4

5 に答える 5

5

3つの選択肢があります。

を使用しuintます。フレームワークはCLSに準拠していないため、そうではありません。しかし、CLSに準拠する必要がありますか？（算術には面白くない問題がいくつかあります。あちこちにキャストするのは面白くありません。uintこのため、私は無効にする傾向があります）。

使用するintが契約を使用する：

Contract.Requires(tokens >= 0);
Contract.Requires(Contract.ForAll(positions, position => position >= 0));

必要なものを正確に明示してください。

要件をカプセル化するカスタムタイプを作成します。

struct Foo {
    public readonly int foo;

    public Foo(int foo) {
        Contract.Requires(foo >= 0);
        this.foo = foo;
    }

    public static implicit operator int(Foo foo) {
        return this.foo;
    }

    public static explicit operator Foo(int foo) {
        return new Foo(foo);
    }
}

それで：

public static double GetDistributionDispersion(Foo tokens, Foo[] positions) { }

良いね。私たちの方法ではそれについて心配する必要はありません。を取得している場合Foo、それは有効です。

ドメインに非否定性を要求する理由があります。それはいくつかの概念をモデル化しています。その概念をドメインモデル内の真正なオブジェクトに昇格させ、それに付随するすべての概念をカプセル化することもできます。

于 2011-09-26T05:59:14.313 に答える
3

私はuintを使用します。

はい、他の答えはすべて正しいです...しかし、私は1つの理由でuintを好みます:

インターフェイスをより明確にします。パラメーター (または戻り値) が符号なしの場合、それは負になることができないためです (負のコレクション数を見たことがありますか?)。それ以外の場合は、パラメーター、ドキュメント パラメーター (および戻り値) をチェックする必要があります。次に、パラメーターと戻り値をチェックするための追加の単体テストを作成する必要があります (うわー、誰かがキャストを行うことに文句を言うでしょうか? int キャストは頻繁に行われますか? いいえ、私の経験では)。

さらに、ユーザーは戻り値の負性をテストする必要があり、これはさらに悪い場合があります。

私は CLS 準拠を気にしません。私の観点からは、質問を逆にする必要があります。値を負にすることはできないのに、なぜ int を使用する必要があるのでしょうか。

追加情報 (エラーなど) に対して負の値を返す点について: 私はCっぽいデザインが好きではありません。これを達成するためのより現代的な設計があると思います（つまり、例外の使用、または出力値とブール値の戻り値の交互の使用）。

于 2011-09-26T13:58:52.377 に答える
2

はい、intに行きます。私はかつて、自分のライブラリに迷惑なキャストを共有するとすぐに、すべてをリファクタリングするためだけに自分自身を使用しようとしました。intを選択するのは、歴史的な理由からだと思います。多くの場合、-1の結果は、ある種のエラーを示します（たとえば、IndexOf）。

于 2011-09-26T05:58:53.830 に答える
1

読んでいると、それは共通言語仕様の規則に違反していますが、その場合、関数はどのくらいの頻度で使用され、他の方法でクラブ化される場合はint、パラメーターとして期待するのが通常であり、キャストの問題に陥ります。値。

ライブラリとして利用できるようにする場合は、従来のintに固執する方がよいでしょう。そうでない場合は、正の値が得られない可能性がある条件を暗黙的に処理する必要があります。これは、ページ全体にチェックを散らかすことを意味します。

興味深い読み物-SOリンク

于 2011-09-26T06:02:46.647 に答える
1

整数。近い将来 API の変更が必要になった場合に、より柔軟に対応できます。負のインデックスなどは、文字列の末尾からの逆カウントを示すために Python でよく使用されます。

値もオーバーフローすると負になり、アサーションはそれをキャッチします。

速度と堅牢性のトレードオフです。

于 2011-09-26T05:52:45.673 に答える