Use uint or int

Question

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 :-)

I think this this post: [Difference of using int and uint and when to use][1] http://stackoverflow.com/questions/3068474/difference-of-using-int-and-uint-and-when-to-use is answer on your question. — Ankar, Sep 26 '11 at 05:56
@Ankar, I did search before I posted this question, and I also read that post, but it does not provide enough reasons to convince me not to use `uint`. — Peter Lee, Sep 26 '11 at 06:02
possible duplicate of [Should I use uint in C# for values that can't be negative?](http://stackoverflow.com/questions/2013116/should-i-use-uint-in-c-sharp-for-values-that-cant-be-negative) — nawfal, Jul 15 '14 at 15:38
Either you deal with an input which cannot be cast to uint (such as -2 etc), or you deal with checking if the input is > 0. Either way you need to do some work. — David Klempfner, Dec 04 '18 at 01:14

jason · Accepted Answer · 2011-09-26T06:04:29.160

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.

It seems the Code Contract (either Standard or Premium edition) won't work on VS express edition :-) — Peter Lee, Sep 26 '11 at 06:57
@Peter Lee: I think that's probably true. You could use old-fashioned guard clauses too. — jason, Sep 26 '11 at 07:01
you mean something like `if (tokens < 0) throw new ArgumentException("tokens should not be negative", "tokens")`? — Peter Lee, Sep 26 '11 at 07:20

Luca · Answer 2 · 2011-09-26T17:19:38.523

I use uint.

Yes, other answers are all correct... But I prefer then uint for one reason:

Make interface more clear. If a parameter (or a returned value) is unsigned, it is because it cannot be negative (has you seen a negative collection count?). Otherwise, I need to check parameters, document parameters (and returned value) that cannot be negative; then I need to write additional unit tests for checking parameters and returned values (wow, and someone would complain for doing casts? Are int casts so frequent? No, by my experience).

Additionally, users are required to test returned values negativity, which may be worse.

I don't mind about CLS compliace, so why I should be? From my point of view, the question should be reversed: why should I use ints when value cannot be negative?

For the point of returning negative value for additional information (errors, for example...): I don't like so C-ish design. I think there may be a more modern design to accomplish this (i.e. use of Exceptions, or alterntively use of out values and boolean returned values).

What you answered is exactly what I'm concerned. Maybe using `uint` is good for the function/method that will only be used in my own solution. — Peter Lee, Sep 26 '11 at 15:59
Definively it depends mostly on your requirements. I think that CLS compliance is the only sufficient reason to avoid unsigned types. — Luca, Sep 26 '11 at 17:21

score 2 · Answer 3 · answered Sep 26 '11 at 05:58

Yes go for int. I once tried to go uint myself only to refactor everything again as soon as I had my share of annoying casts in my lib. I guess the decision to go for int is for historical reasons where often a result of -1 indicates some sort of error (for example in IndexOf).

score 1 · Answer 4 · answered Sep 26 '11 at 05:52

1

int. it gives more flexibility when you need to do a API change in the near future. such as negative indexes are often used by python to indicate reversed counting from the end of string.

values also turns negative when overflows, assertion will catch it.

its a trade off for speed vs robustness.

answered Sep 26 '11 at 05:52

Bamboo

2,046
2
16
21

I understand this point as I got this from other posts. But then, are they always doing negativeness check in their implementation, if the values should not be negative? – Peter Lee Sep 26 '11 at 05:54
yes they did. It is a tradeoff. If you don't' like this, attribute your assertion method [Conditional("DEBUG")], it will only check on debug build. BTW, uint does not do any check boundary at all at runtime unless you declare check requirement explicitly. – Bamboo Sep 26 '11 at 06:00

score 1 · Answer 5 · edited May 23 '17 at 11:59

As you read it violates the Common Language Specification rules, but then how often will the function be used and in case it going to be clubbed up with other method its normal for them to expect int as parameter which would get you into the trouble of casting the values.

If you are going to make it available as a library then its better sticking to the conventional int else you need to implicitly take care of conditions wherein you might not get a positive value which would mean littering the checks across the pages.

Interesting Read - SO link

Use uint or int

5 Answers5