blocks|key|1058480|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1058481|将size_t转换为long有什么缺点吗？|blockquote|1058482|1058483|1058484|理论上，long可以比size_t小。而且，long是有符号的。size_t是未签名的。因此，如果你开始在同一个表达式中使用它们，像g%2B%2B这样的编译器就会抱怨这个问题。很多。从理论上讲，由于签名到未签名的赋值，它可能会导致意外的错误。|1058485|1058486|显然会有一些long的转换或添加|1058487|1058488|1058489|我不明白为什么要对long进行一些转换或添加。你可以继续使用size_t进行所有的算术运算。您可以将其定义为"ListIndex“或其他任何形式，并在整个代码中继续使用它。如果你混合了类型(long和size_t)，g%2B%2B/mignw会让你烦得要死。|1058490|或者，您可以选择具有保证大小的特定类型。较新的编译器有cstdint头文件，其中包括像uint64_t这样的类型(例如，您极不可能遇到大于2%5E64的文件)。如果你的编译器没有头文件，它应该在boost中可用。|1058491|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|S|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|T|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|U|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|V|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|W|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|X|7|@]|8|@]|9|$]]|$1|I|3|J|4|C|6|Y|7|@]|8|@]|9|$]]|$1|K|3|-4|4|5|6|Z|7|@]|8|@]|9|$]]|$1|L|3|-4|4|5|6|10|7|@]|8|@]|9|$]]|$1|M|3|N|4|5|6|11|7|@]|8|@]|9|$]]|$1|O|3|P|4|5|6|12|7|@]|8|@]|9|$]]|$1|Q|3|-4|4|5|6|13|7|@]|8|@]|9|$]]]|R|$]]

<blockquote>
 Is there any disadvantage of converting size_t to long?
</blockquote>

Theoretically long can be smaller than size_t. Also, long is signed. size_t is unsigned. So if you start using them both in same expression, compiler like g++ will complain about it. A lot. Theoretically it might lead to unexpected errors due to signed-to-unsigned assignments. 

<blockquote>
 obviously there is going to be some conversion or addition of long
</blockquote>

I don't see why there's supposed to be some conversion or addition to long. You can keep using size_t for all arithmetical operations. You can typedef it as "ListIndex" or whatever and keep using it throughout the code. If you mix types (long and size_t), g++/mignw will nag you to death about it.

Alternatively, you could select specific type which has guaranteed size. Newer compilers have cstdint header which includes types like uint64_t (it is extremely unlikely that you encounter file larger than 2^64, for example). If your compiler doesn't have the header, it should be available in boost.

blocks|key|2074158|text|这现在不是问题，但可能会在未来，这取决于你的应用程序将移植到哪里。这是因为size_t被定义得足够大来存储指针的偏移量，所以如果你有一个64位的指针，size_t也将是64位的。现在，long可能是64位，也可能不是64位，因为C/C%2B%2B中基本类型的大小规则为一些变化留出了空间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2074159|但是，如果要将这些值写入文件，无论如何都必须选择一个特定的大小，因此除了转换为long+(如果需要，也可以转换为long+long+)之外，别无选择。更好的是，使用一种新的特定于大小的类型，如int32_t。|2074160|我的建议是:在文件头的某个位置，存储您将size_t转换为的类型的大小。通过这样做，如果将来您决定使用更大的大小，您仍然可以支持旧的大小。对于当前版本的程序，您可以检查是否支持该大小，如果不支持，则发出错误。|2074161|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|$]]

It's not a problem now, but it may be in the future depending on where you'll port your app. That's because size_t is defined to be large enough to store offsets of pointers, so if you have a 64-bit pointer, size_t will be 64 bits too. Now, long may or may not be 64 bits, because the size rules for fundamental types in C/C++ give room to some variations. 

But if you're to write these values to a file, you have to choose a specific size anyway, so there's no option other than convert to long (or long long, if needed). Better yet, use one of the new size-specific types like int32_t.

My advice: somewhere in the header of your file, store the sizeof for the type you converted the size_t to. By doing that, if in the future you decide to use a larger one, you can still support the old size. And for the current version of the program, you can check if the size is supported or not, and issue an error if not.

blocks|key|1058544|text|不幸的是，"long“类型没有很好的理论基础。最初，它是在32位unix端口上引入的，目的是将它与现有PDP11软件假定的16位“整型”区分开来。后来，"int“在这些平台上被更改为32位(并引入了"short”)，"+long“和"int”成为同义词，它们在很长一段时间内都是同义词。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1058545|现在，在64位的类unix平台上(Linux、BSD、OS、iOS以及人们可能仍然关心的任何专有的unix)，"long“是一个64位的数量。但是，不幸的是，不是在windows上:在现有的头文件中有太多的遗留“代码”，使得(整型)==sizeof(长)假设的大小，所以他们使用了一个叫"LLP64“的令人厌恶的东西，留下了32位的长度。叹一口气。|1058546|但是"size_t“不是这样的。它一直只意味着一件事:它是无符号类型，用于在地址空间中存储本机指针大小。如果你有一个需要整数表示形式的无符号(！--如果你需要有符号算术，使用ssize_t或ptrdiff_t+)指针(即你需要存储一个对象的内存大小)，这就是你要使用的。|1058547|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|$]]

The "long" type, unfortunately, doesn't have a good theoretical basis. Originally it was introduced on 32 bit unix ports to differentiate it from the 16 bit "int" assumed by the existing PDP11 software. Then later "int" was changed to 32 bits on those platforms (and "short" was introduced) and "long" and "int" became synonyms, which they were for a very long time.

Now, on 64 bit unix-like platforms (Linux, the BSDs, OS X, iOS and whatever proprietary unixes people might still care about) "long" is a 64 bit quantity. But, sadly, not on windows: there was too much legacy "code" in the existing headers that made the sizeof(int)==sizeof(long) assumption, so they went with an abomination called "LLP64" and left long as 32 bits. Sigh.

But "size_t" isn't like that. It has always meant precisely one thing: it's the unsigned type that stores the native pointer size in the address space. If you have an unsigned (! -- use ssize_t or ptrdiff_t if you need signed arithmetic) pointer that needs an integer representation (i.e. you need to store the memory size of an object), this is what you use.

Is there any disadvantage of converting size_t to long? Because, I am writing an program that maintains linked_list in a file. So I traverse to another node based on size_t and I also keep track of total number of lists as size_t. Hence, obviously there is going to be some conversion or addition of long and size_t. Is there any disadvantage of this? If there is then I will make everything as long instead of size_t, even the sizes. Please advise.

converting size_t into long, Is there any disadvantage?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

将size_t转换为long有什么缺点吗？因为，我正在编写一个在文件中维护linked_list的程序。因此，我遍历到另一个基于size_t的节点，并且我还记录了列表的总数，如size_t。因此，显然会有一些long和size_t的转换或添加。这样做有什么缺点吗？如果有，那么我会让所有的东西都一样长，而不是size_t...

问将size_t转换为long，有什么缺点吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问将size_t转换为long，有什么缺点吗？EN