使用 uint 或 int

发布于 2024-12-06 08:35:40 字数 804 浏览 5 评论 0原文

当然，我知道无符号整数 (uint) 和有符号整数 (int) 之间的基本区别。

我注意到在 .NET 公共类中，名为 Length 的属性始终使用有符号整数。

也许这是因为无符号整数不符合 CLS。

但是，例如，在我的静态函数中：

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

参数tokens和positions中的所有元素不能为负数。如果结果是否定的，那么最后的结果就没有意义。因此，如果我对令牌和位置都使用 int，我必须在每次调用此函数时检查这些值（并返回无意义的值）值或如果发现负值则抛出异常？？？），这很乏味。

好的，那么我们应该对两个参数都使用 uint 。这对我来说确实很有意义。

然而，我发现，正如在许多公共 API 中一样，它们几乎总是使用 int。这是否意味着在他们的实现中，他们总是检查每个值的负数（如果它应该是非负数）？

那么，总而言之，我该怎么办？

我可以提供两种情况：

这个函数只会在我自己的解决方案中被我自己调用；
该函数将被其他团队的其他人用作库。

我们应该针对这两种情况使用不同的方案吗？

Peter

P.S.：我确实做了很多研究，但仍然没有理由说服我不使用 uint :-)

原文

Definitely, I know the basic differences between unsigned integers (uint) and signed integers (int).

I noticed that in .NET public classes, a property called Length is always using signed integers.

Maybe this is because unsigned integers are not CLS compliant.

However, for example, in my static function:

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

The parameter tokens and all elements in positions cannot be negative. If it's negative, the final result is useless. So if I use int both for tokens and positions, I have to check the values every time this function is called (and return non-sense values or throw exceptions if negative values found???), which is tedious.

OK, then we should use uint for both parameters. This really makes sense to me.

I found, however, as in a lot of public APIs, they are almost always using int. Does that mean inside their implementation, they always check the negativeness of each value (if it is supposed to be non-negative)?

So, in a word, what should I do?

I could provide two cases:

This function will only be called by myself in my own solution;
This function will be used as a library by others in other team.

Should we use different schemes for these two cases?

Peter

P.S.: I did do a lot of research, and there is still no reason to convince me not to use uint :-)

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

沙与沫 2024-12-13 08:35:40

我看到三个选项。

使用uint。该框架不这样做，因为它不符合 CLS。但您必须符合 CLS 要求吗？（也有一些不有趣的算术问题突然出现；到处投射并不有趣。出于这个原因，我倾向于 void 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，那么它是有效的。

您有理由要求您的领域具有非消极性。它正在对一些概念进行建模。不妨将该概念提升为领域模型中的真正对象，并封装它附带的所有概念。

I see three options.

Use uint. The framework doesn't because it's not CLS compliant. But do you have to be CLS compliant? (There are also some not-fun issues with arithmetic that crop up; it's not fun to cast all over the place. I tend to void uint for this reason).

Use int but use contracts:

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

Make it explicit it exactly what you require.

Create a custom type that encapsulates the requirement:

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);
    }
}

Then:

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

Ah, nice. We don't have to worry about it in our method. If we're getting a Foo, it's valid.

You have a reason for requiring non-negativity in your domain. It's modeling some concept. Might as well promote that concept to a bonafide object in your domain model and encapsulate all the concepts that come with it.

回复收藏 0 原文