我的容器类中应该允许多少个整数？
我不希望该类因值太多而导致崩溃。我意识到需要 268,435,456 个整数（如果我的数学正确的话）才能占用 1 GB（这是相当极端的）。这个值只是有符号整数最大值的八分之一（这是我当前使用的长度。我应该对此设置上限吗？如果是这样，合理的数字是多少？ unsigned Short 的长度是否合理？您是否曾经需要一个包含超过 65,536 个值的数组？
I don't want the class to cause a crash due to too many values. I realize that it would take 268,435,456 integers (if I did my math correctly) to take up one gigabyte (which is pretty extreme). This value is merely an eighth of a signed integer's maximum value (which is what I am currently using for the length. Should I put a cap on this? If so, what would be a reasonable number? Would an unsigned short be a reasonable length? Have you ever needed an array with more than 65,536 values?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
对课程进行任意限制被认为是不好的做法。
您应该允许用户将任意数量的物品放入您的容器中；如果他们尝试放入太多，他们的工作就是处理将抛出的 std::bad_alloc 异常。
Placing arbitrary limits on your classes is considered bad practice.
You should allow the user to put as many items as they want into your container; if they try to put too many in, it's their job to deal with the
std::bad_allocexception that will be thrown.我的硬盘上有大量比这大得多的文件（我想到了 mp3，以及一些可执行文件）。
我可能想要一次将整个文件存入内存吗？当然。
对整个应用程序的建议
随着时间的推移，计算机只会获得更多的内存，因此不要用深度硬编码的值来限制您的应用程序。
实现此目的的一种方法是使用可变大小的容器，例如
std::vector来包含您的值。然后，您可以留下用户输入验证代码来设置限制。通常，您应该检查用户输入（包括输入文件、字段中传递的值、函数中传递的值等）并对这些值设置人为（但相当大）的上限。然后让您的内部代码根据需要自由增长。这使得测试您的程序变得更加容易，因为您有一个目标“最大”值可供追求。您可以测试并自信地说您支持这些上限，并且可以在用户使用高于这些限制的值时测试错误处理。
稍后，如果您确实需要/想要，您可以进行性能分析/测试来调整应用程序的限制以适应目标内存占用量，或者最好限制数据以保持性能。
针对简单/较低级别类的建议
不要添加任何硬编码值。使用可变大小的容器，并让更高级别的代码处理任何硬限制。
用户必须正确使用您的代码，以免抛出异常。您的类中的代码也不应该尝试捕获此内存不足异常，因为您的代码几乎肯定无法从中恢复。
I have tons of files on my hard drive that are way bigger than this (mp3s come to mind, as well as some executables).
Might I want an entire file in memory at one time? Of course.
Suggestions for a whole application
Computers will only get more memory as time goes on, so don't hamstring your application with deeply hard-coded values.
One way to do this is to use variable-sized containers, such as
std::vectorto contain your values. You can then leave your user input validation code to place the limit.Generally you should check user input (including input files, values passed in fields, values passed in functions, etc) and put artificial (but reasonably large) caps on these values. Then leave your internal code free to grow as necessary. This makes it much easier to test your program, since you have a target "maxed out" value to shoot for. You can test and confidently say you support those upper limits, and you can test error handling when the user uses values above those limits.
Later on, if you really need/want to, you can do performance profiling/testing to adjust your application's limits to fit within a target memory footprint, or best limit the data to remain performant.
Suggestions for simple/lower level classes
Don't add any hard-coded values. Use variable sized containers, and let your higher level code deal with any hard-limiting.
It is up to the user to use your code correctly, lest they have an exception thrown. The code in your class also should not try to catch this out of memory exception, since your code almost assuredly can't recover from it gracefully.
人们普遍期望通用容器不会对客户端强加任意限制。如果您担心节省内存 - 认为您的客户端编码器（容器“库”代码的用户）会担心 - 那么请考虑通过将其设置为模板参数来为他们提供选择。缺点是您最终可能会为单个值类型提供多种类型的容器和模板实例化。一般来说没什么大不了的。更一般地说，客户端不会意外地将太多项推入容器，也不会意外地在某个循环中泄漏内存，或者意外地将其堆分配的大小乘以某个 MB_MULTIPLIER 两次。如果他们担心，就让他们写
if (container.size() > 65535) throw "not likely mate";。您根本无法对抗某些类型的客户端滥用，并且必须让他们在开发和使用过程中得到正确的解决方案。测试。It's generally expected that general purpose containers will not impose arbitrary limits on the client. If you're concerned about saving memory - thinking your client coder (the user of your container "library" code) will be concerned - then consider giving them the choice by making it a template parameter. The downside then is that you can end up with multiple types of containers - and template instantiations - for a single value type. Not a big deal generally. And more generally, it's no more likely that the client will accidentally push too many items into your container than that they'll accidentally leak memory in a loop somewhere or multiply the size for their heap allocation by some MB_MULTIPLIER twice by accident. If they're worried, let them write
if (container.size() > 65535) throw "not likely mate";. You simply can't fight certain kinds of client misuse and have to let them get it right during dev & testing.我使用了容量为20000000的布尔（布尔类型）数组。
至于最大大小，显然您不应该尝试容纳超出内存容量的数据。但是，如果情况需要处理大量数字，则需要更改程序设计。
I have used boolean(bool type) arrays with capaity of 20000000.
As for the max size, clearly you should not try to accommodate more data than that can fit in memory. However, if situation demands handling large quantity of number, you would need to change your program design.