blocks|key|1216464|text|我怀疑，您观察到的为什么在BCL中不使用uint是主要原因。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1216465|UInt32不兼容日志服务，这意味着它完全不适合用于公共API。如果你打算在你的私有API中使用uint，这就意味着要转换成其他类型--而且保持类型不变通常更容易也更安全。|1216466|我还怀疑这在C#开发中并不常见，即使C#是唯一使用的语言，主要是因为它在BCL中并不常见。一般来说，开发人员试图(谢天谢地)模仿他们正在构建的框架的风格--在C#的例子中，这意味着试图让你的API，无论是公共的还是内部的，看起来尽可能地像.NET框架BCL。这意味着要谨慎地使用uint。|1216467|entityMap^0|K|4|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|K|$]]

Your observation of why <code>uint</code> isn't used in the BCL is the main reason, I suspect. 

UInt32 is not CLS Compliant, which means that it is wholly inappropriate for use in public APIs. If you're going to be using uint in your private API, this will mean doing conversions to other types - and it's typically easier and safer to just keep the type the same.

I also suspect that this is not as common in C# development, even when C# is the only language being used, primarily because it is not common in the BCL. Developers, in general, try to (thankfully) mimic the style of the framework on which they are building - in C#'s case, this means trying to make your APIs, public and internal, look as much like the .NET Framework BCL as possible. This would mean using uint sparingly.

blocks|key|1002014|text|int的类型比uint短。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1002015|entityMap^0|0|3|7|4|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

<code>int</code> is shorter to type than <code>uint</code>.

blocks|key|1002305|text|1)坏习惯。我是认真的。即使在C/C%2B%2B中也是如此。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1002306|想想常见的for模式：|offset|length|style|CODE|1002307|for(+int+i=0;+i<3;+i%2B%2B+)
++++foo(i);|code-block|syntax|javascript|1002308|这里绝对没有理由使用整数。你永远不会有负值。但几乎每个人都会这样做一个简单的循环，即使它包含(至少)另外两个“样式”错误。|1002309|2)+int被认为是机器的本机类型。|1002310|entityMap^0|0|5|3|0|0|0|3|3|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@$D|U|E|V|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|W|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|Y|8|@$D|Z|E|10|F|G]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|R|$]]

1) Bad habit. Seriously. Even in C/C++.

Think of the common <code>for</code> pattern:

<pre><code>for( int i=0; i&lt;3; i++ )
 foo(i);
</code></pre>

There's absolutely no reason to use an integer there. You will never have negative values. But almost everyone will do a simple loop that way, even if it contains (at least) two other "style" errors.

2) <code>int</code> is perceived as the native type of the machine.

blocks|key|1002224|text|我更喜欢uint而不是int，除非负数实际上在可接受的值范围内。特别是，接受int参数，但如果数字小于零就抛出ArgumentException，这是很愚蠢的--使用uint！|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1002225|我同意uint没有得到充分利用，我鼓励其他人多使用它。|1002226|entityMap^0|4|4|B|3|12|3|1J|H|2B|4|0|3|4|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]|$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|X|8|@]|D|@]|E|$]]]|I|$]]

I prefer <code>uint</code> to <code>int</code> unless a negative number is actually in the range of acceptable values. In particular, accepting an <code>int</code> param but throwing an <code>ArgumentException</code> if the number is less than zero is just silly--use a <code>uint</code>!

I agree that <code>uint</code> is underused, and I encourage everyone else to use it more.

blocks|key|1002389|text|我在较低级别的应用层编程，在那里int很少超过100，所以负值不是问题(例如，对于i<+myname.length()类型的东西)，这只是一个旧的C习惯-并且像上面提到的类型更短。然而，在某些情况下，当我在处理来自设备的事件标志的硬件接口时，uint在标志可能使用最左(最高)位的情况下很重要。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1002390|老实说，对于我99.9%25的工作，我可以很容易地使用ushort，但是int，你知道，听起来比ushort好得多。|1002391|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I program at a lower level application layer where ints rarely get above 100, so negative values are not an issue (e.g. for i &lt; myname.length() type stuff) it's just an old C habit - and shorter to type as mentioned above. However, in some cases, when interfacing to hardware where I'm dealing with event flags from devices, the uint is important in cases where a flag may use the left (highest) most bit. 

Honestly, for 99.9% of my work I could easily use ushort, but int, you know, sounds sounds a lot better than ushort.

blocks|key|1216799|text|我用C#做了一个Direct3D+10包装器，如果我想创建非常大的顶点缓冲区，就需要使用uint。显卡中的大缓冲区不能用带符号的int表示。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1216800|UINT是非常有用的&否则说它是愚蠢的。如果任何人仅仅因为他们从来没有需要使用uint就认为没有其他人会使用uint，那么你就错了。|1216801|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I have made a Direct3D 10 wrapper in C# &amp; need to use uint if I want to create very large vertex buffers. Large buffers in the video card can not be represented with a signed int.

UINT is very useful &amp; is silly to say otherwise. If anyone thinks just because they have never needed to use uint no one else will, you are wrong.

blocks|key|1002283|text|我认为这只是懒惰。C#本质上是在桌面和其他资源相对较多的机器上进行开发的选择。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1002284|然而，C和C%2B%2B在内存稀缺的旧系统和嵌入式系统中有着深厚的根基，因此程序员习惯于仔细考虑使用哪种数据类型。C#程序员是懒惰的，而且由于通常有足够的资源，没有人真正优化内存使用(通常，当然不总是)。如果一个字节就足够了，很多C#程序员，包括我在内，为了简单起见只使用了int。此外，许多API函数都接受it，因此它阻止了强制转换。|1002285|我同意选择正确的数据类型是很好的实践，但我认为主要的动机是懒惰。|1002286|最后，选择一个整数在数学上更加正确。数学中不存在无符号整数(只有自然数)。由于大多数程序员都有数学背景，所以使用整数更自然。|1002287|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I think it is just laziness. C# is inherently a choice for development on desktops and other machines with relatively much resources.

C and C++, however, has deep roots in old systems and embedded systems where memory is sparse, so programmers are used to think carefully what datatype to use.
C# programmers are lazy, and since there are enough resources in general, nobody really optimizes memory usage (in general, not always of course). Event if a byte would be sufficient, a lot of C# programmers, including me, just use int for simplicity. Moreover, a lot of API functions accept ints, so it prevents casting.

I agree that choosing the correct datatype is good practice, but I think the main motivation is laziness. 

Finally, choosing an integer is more mathematically correct. Unsigned ints don't exist in math (only natural numbers). And since most programmers have a mathematical background, using an integer is more natural.

blocks|key|1216706|text|我认为很大一部分原因是，当C语言第一次出现时，为了简洁起见，大多数示例都使用了int。我们很高兴不必像使用Fortran和Pascal那样编写integer，在那些日子里，我们经常将它们用于诸如数组索引和循环计数器之类的日常工作。无符号整数是需要最后一个额外位的大数的特殊情况。我认为C习惯继续进入C#和其他新语言是一个很自然的过程。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1216707|entityMap^0|13|3|1Z|7|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

I think a big part of the reason is that when C first came out most of the examples used <code>int</code> for brevity's sake. We rejoiced at not having to write <code>integer</code> like we did with Fortran and Pascal, and in those days we routinely used them for mundane things like array indices and loop counters. Unsigned integers were special cases for large numbers that needed that last extra bit. I think it's a natural progression that C habits continued into C# and other new languages like Python.

blocks|key|1216900|text|一些语言(例如，Pascal的许多版本)将无符号类型视为表示数值的类型；在相同大小的无符号类型和有符号类型之间的操作通常将被执行，就好像操作数被提升为下一个更大的类型(在某些这样的语言中，最大的类型没有无符号的等价物，因此这种提升总是可能的)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1216901|其他语言(例如C)将N位无符号类型视为一个模数为2%5EN的组。请注意，从这样一个组的成员中减去N并不代表数值减法，而是得到组成员，当N加到它上面时，就会得到原始成员。可以说，某些涉及有符号和无符号混合的操作并不真正有意义，也许应该被禁止，但即使是对数字文字等东西的草率规范的代码通常也会起作用，并且已经编写了混合有符号和无符号类型的代码，尽管很草率，但确实可以工作，规范不会很快改变。|1216902|专门处理有符号类型要比解决有符号类型和无符号类型之间的所有错综复杂的交互容易得多。无符号类型在将较大的数字分解成较小的片段(例如，用于序列化)或重新构造这些数字时很有用，但通常情况下，对于实际表示数量的事物，使用有符号的类型更好|1216903|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Some languages (e.g. many versions of Pascal) regard unsigned types as representing numeric quantities; an operation between an unsigned type and a signed type of the same size will generally be performed as though the operands were promoted to the next larger type (in some such languages, the largest type has no unsigned equivalent, so such promotion will always be possible).

Other languages (e.g. C) regard N-bit unsigned types as a group which wraps around modulo 2^N. Note that subtracting N from a member of such a group doesn't represent numerical subtraction, but rather yields the group member which, when N is added to it, would yield the original. Arguably, certain operations involving mixtures of signed and unsigned values don't really make sense and should perhaps have been forbidden, but even code which is sloppy with its specifications of things like numeric literals will usually work, and code has been written which mixes signed and unsigned types and, despite being sloppy, does work, that the spec isn't apt to change any time soon.

It's a lot easier to work exclusively with signed types than to work out all the intricacies of interactions between signed and unsigned types. Unsigned types are useful when decomposing large numbers out of smaller pieces (e.g. for serialization) or for reconstituting such numbers, but in general it's better to simply use signed numbers for things that actually represent quantities

blocks|key|1002578|text|我知道这可能是一个古老的主题，但我想给出一些澄清。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1002579|让我们以一个可以存储-128到127的int8为例，它使用了1个字节，总共有127个正数。|1002580|当您使用int8时，其中一位用于负数-128。|1002581|当您使用Uint8时，您将负数赋给正数，因此这允许您使用255个正数，并具有相同的存储量1个字节。|1002582|唯一的缺点是你现在已经失去了使用负值的能力。|1002583|另一个问题是，并不是所有的编程语言和数据库都支持它。|1002584|在我看来，你使用它的唯一原因是当你需要像游戏编程一样高效的时候，你必须存储大量的非负数。这就是为什么很少有程序使用它的原因。|1002585|主要原因是存储不是问题，你不能在其他软件、插件、数据库或Api中灵活地使用它，例如，银行需要负数来存储货币等。|1002586|我希望这能对某些人有所帮助。|1002587|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|Y|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|Z|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|10|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|11|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|S|$]]

I know this is probably an old thread but I wanted to give some clarification. 

Lets take an int8 you can store –128 to 127 and it uses 1 byte that is a total of 127 positive numbers. 
When you use an int8 one of the bits is used for the negative numbers -128. 
When you use a Uint8 you give the negative numbers to the positive so this allows you to use 255 positive numbers with the same amount of storage 1 byte. 
The only draw back is the you have now lost the capability to use negative values. 
Another problem with this is not all programming languages and databases support this. 
The only reason you would use this in my opinion is when you need to be efficient in like gaming programming and you have to store large non negative numbers. 
This is why not many programs use this it. 

The main reason is storage is not a problem and you can't use it flexibly with other software, plugins, Database, or Api's. Also for example a bank would need negative numbers to store money etc.

I hope this will help someone.

I have observed for a while that C# programmers tend to use int everywhere, and rarely resort to uint. But I have never discovered a satisfactory answer as to why.

If interoperability is your goal, uint shouldn't appear in public APIs because not all CLI languages support unsigned integers. But that doesn't explain why int is so prevalent, even in internal classes. I suspect this is the reason uint is used sparingly in the BCL.

In C++, if you have an integer for which negative values make no sense, you choose an unsigned integer.

This clearly signifies that negative numbers are not allowed or expected, and the compiler will do some checking for you. I also suspect in the case of array indices, that the JIT can easily drop the lower bounds check.

However, when mixing int and unit types, extra care and casts will be needed.

Should uint be used more? Why?

using uint vs int

嵌入式系统

日志服务

数据库

编译器

我观察了一段时间，C#程序员倾向于在任何地方使用int，而很少求助于uint。但是我从来没有找到一个令人满意的答案。如果互操作性是您的目标，uint不应该出现在公共API中，因为并不是所有的CLI语言都支持无符号整数。但这并不能解释为什么int如此流行，甚至在内部类中也是如此。我怀疑这就是为什么uint在BCL中使用得很少的原因。在C++中，如果有一个负值没有意义的整数，则选择一个无符号整数。这清

问使用uint与int
EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问使用uint与intEN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问使用uint与int
EN