当前位置：文江博客话题详情

何时使用 int 以外的数据类型？

发布于 2024-11-06 06:06:41 字数 250 浏览 6 评论 0原文

我有一个项目，其中有许多具有许多属性的对象，这些对象的值始终小于 60、100 和 255 等小数字。

我知道，在对 byte 进行数学计算时，它是需要投射结果。但除此之外，对所有这些属性使用 byte 或 short 是否有任何缺点？或者换个角度来看，使用 byte 或 short 代替 int 有什么优势吗？

原文

分享到QQ

分享到微博

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

发布评论

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

救星 2024-11-13 06:06:41

byte 和 short 在互操作场景中非常有用，在互操作场景中，您需要与本机代码期望大小相同的数据类型。

在处理非常大数据集时，它们还可以节省内存。

回复收藏 0 原文

失与倦＂ 2024-11-13 06:06:41

一般来说，使用有意义的类型。从数据验证、完整性和持久性的角度来看，这可能很有帮助。

例如，通常情况下，由于填充和对齐问题，bool 在 32 位架构上实际上会消耗 4 个字节，在 64 位架构上可能会消耗 8 个字节。默认情况下，大多数编译器都会针对速度进行优化，而不是针对代码大小或内存使用情况进行优化。对齐访问通常比未对齐访问更快。在.Net 中，其中一些可以通过属性来控制。据我所知，JIT 编译器不努力将多个布尔类型压缩到一个整数位字段中。

对于byte类型也是如此。 JIT 编译器可以压缩多个字节类型（甚至重新排列存储顺序）以共享同一个单词（假设您不使用 StructLayout 和 FieldOffset 等属性覆盖此类行为））。

例如：

struct Foo
{
    string A;
    short B;
    string C;
    short D;
}

将引用类型视为指针，上面的大小可能为 16（可能是 14，但与 16 对齐）。

Foo 可以重新排列，使得顺序实际上是：

struct Foo
{
   string A;
   string C;
   short B;
   short D;
}

上面的大小可能为 12，对齐方式为 12 或 16（可能是 16）。

...在这个人为的示例中，由于重新排列，您可能可以节省 4 个字节。请注意，.Net 在重新调整成员方面比典型的 C++ 编译器更加积极。

（顺便说一句，我最近在我维护的一个 C++ 库上做了一些努力。纯粹通过优化成员布局，我能够实现 55% 的内存使用量减少）。

In general, use the type that makes sense. This can be helpful from data validation, integrity and persistence standpoints.

Typically, for instance, a bool will actually consume 4-bytes on a 32-bit architecture, perhaps 8-bytes on a 64-bit architecture due to padding and alignment issues. Most compilers will, by default, optimize for speed and not code size or memory usage. Aligned access is typically faster than unaligned access. In .Net, some of this can be controlled via attributes. To my knowledge, the JIT compiler makes no effort to compact multiple boolean types into an integer bit field.

The same would hold true for byte types. The JIT compiler could compact multiple byte types (and even rearrange storage order) to share the same word (assuming you don't override such behavior with attributes such as StructLayout and FieldOffset).

For instance:

struct Foo
{
    string A;
    short B;
    string C;
    short D;
}

Treating reference types as pointers, the above would likely have a size of 16 (maybe 14, but aligned to 16).

Foo could be rearranged such that the order would actually be:

struct Foo
{
   string A;
   string C;
   short B;
   short D;
}

The above would likely have a size of 12, and an alignment of 12 or 16 (probably 16).

...potentially, in this contrived example, you could save 4 bytes due to rearrangement. And do note that .Net is more aggressive about realigning members than a typical C++ compiler is.

(On an aside, I recently spent some effort in a C++ library I maintain. I was able to achieve a 55% reduction in memory usage purely by optimizing member layout).

回复收藏 0 原文