c++ - 权威的 “correct”方法，用于针对size_t测试循环变量时避免有符号/无符号警告

Question

下面的代码生成一个编译器警告:

private void test()
{
    byte buffer[100];
    for (int i = 0; i < sizeof(buffer); ++i)
    {
        buffer[i] = 0;
    }
}

warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

这是因为sizeof()返回一个size_t，它是无符号的。

我已经看到了许多有关如何处理此问题的建议，但是没有一个建议有很多的支持，也没有一个有任何令人信服的逻辑，也没有任何支持一个方法明显“更好”的引用。最常见的建议似乎是:

忽略警告

关闭警告

使用类型为size_t的循环变量

使用带有技巧的size_t类型的循环变量来避免递减超过

零

将size_of(buffer)转换为int

我没有耐心的一些极其复杂的建议，因为它们涉及不可读的代码，通常涉及 vector 和/或迭代器

在经常使用的AVR/ARM嵌入式环境中无法加载的

库。

自由函数返回一个有效的int或long表示T

的字节数

不要使用循环(该喜欢这个建议)

有没有一种“正确”的方法来解决这个问题？

-开始编辑-

我给出的示例当然很简单，并且仅用于说明在索引编制情况下可能发生的类型不匹配警告。

＃3 不一定是正确答案，因为size_t在递减循环中具有特殊风险，例如 for (size_t i = myArray.size; i > 0; --i)(该数组有一天的大小可能为零)。

＃4 是建议通过包括适当和必要的检查来避免size_t索引递减来避免递减到零以上。由于这会使代码更难阅读，因此有些可爱的快捷方式并不是特别可读，因此我将它们称为“技巧”。

＃7 是建议使用不能泛化的库，因为它们可能在每种情况下都不可用或不合适。

＃8 是建议使检查保持可读性，但以非成员方法(有时称为“自由功能”)将其隐藏。

＃9 是建议使用算法而不是循环。多次提供此方法作为解决size_t索引问题的方法，并且有很多支持。即使我在大多数环境中都无法使用STL库，但仍必须自己编写代码，我还是将其包括在内。

-结束编辑-

我希望获得有关处理此类问题的最佳做法的循证指南或引用。是否有解决该问题的“标准文本”或样式指南？一家大型科技公司已在内部采用/认可的明确方法？在新的语言版本中即将出现可仿真的解决方案？如有必要，我会满意一位公认的专家提出的不受支持的公开建议。

提供的选项似乎都不吸引人。这些警告淹没了我想看到的其他东西。我不想在可能重要的地方错过带符号/无符号的比较。通过比较> = 0减小 size_t类型的循环变量会导致无符号整数环绕的无限循环，即使我们使用 for (size_t i = sizeof(buffer); i-->0 ;)这样的方法来防止这种循环，也存在与size_t变量递增/递减/比较的其他问题。当size_t意外为零时(例如 size_t - 1)，对 strlen(myEmptyString)进行测试将产生一个较大的正“oops”数。将无符号的size_t强制转换为整数是容器大小的问题(不能保证有一个值)，当然size_t可能大于int。

考虑到我的数组的已知大小远低于Int_Max，在我看来，将size_t转换为有符号整数是最好的选择，但这让我有些畏缩。特别是如果它必须是 static_cast<int>。如果通过某种大小测试将其隐藏在函数调用中，则更容易采取，但仍然...

或者也许有一种方法可以关闭警告，但是 只是用于循环比较？

Answer 1

最合适的解决方案将完全取决于上下文。在您的问题的代码片段的上下文中，最合适的操作可能是达成类型协议(protocol)-项目符号列表中的第三个选项。在这种情况下，这是适当的，因为在整个代码中使用i仅是对数组建立索引-在这种情况下，使用int是不合适的-或至少是不必要的。

另一方面，如果i是某个算术表达式中涉及的算术对象，该算术表达式本身已签名，则int可能是适当的，并且将进行强制转换。

我建议作为指导原则，使用最少数量的必要类型强制转换(显式隐式)的解决方案是合适的，或者换一种方式来看，即最大可能的类型一致性。没有一个“权威”规则，因为所涉及变量的目的和用法在语义上而不是句法上是相关的。在这种情况下，正如其他答案中指出的那样，支持迭代的较新语言功能也可以完全避免该特定问题。

要讨论您说的建议，您将得到以下具体建议:

• ignore the warnings

绝不是一个好主意-有些将是真正的语义错误或维护问题，并且到您有数百条您正在忽略的警告时，您将如何发现一个警告并发出？

• turn off the warnings

一个更糟的主意；编译器正在帮助您提高代码质量和可靠性。你为什么要禁用它？

• use a loop variable of type size_t

在这个精确的示例中，这正是您应该这样做的原因。确切的类型协议(protocol)应始终是目标。

• use a loop variable of type size_t with tricks to avoid decrementing past zero

该建议与给出的简单示例无关。此外，我认为，通过“欺骗”，顾问实际上意味着检查或只是正确的代码。无需“技巧”，该词完全模棱两可-谁知道顾问的意思？当不需要具有这种属性的任何解决方案时，它表明有些不合常规且有点“肮脏”。

• cast size_of(buffer) to an int

如果使用 i可以保证使用 int来确保代码中其他位置的正确语义，则这可能是必要的。问题中的示例没有，因此在这种情况下，这不是合适的解决方案。本质上，如果在此处将 i设置为 size_t会导致其他地方的类型协议(protocol)警告，而这些自身不能通过通用类型协议(protocol)来解决表达式中的所有操作数，那么强制转换可能是合适的。目的应该是实现最小类型强制转换的零警告。

• some extremely convoluted suggestions that I did not have the patience to follow, generally involving vectors and/or iterators

如果您不准备详细阐述甚至不考虑此类建议，则最好省略问题中的“建议”。无论如何，在任何情况下都不总是使用STL容器来适应大部分嵌入式目标，在许多平台和应用程序上，都应避免使用过多的代码大小以及不确定的堆管理。

• libraries that I cannot load in an embedded environment.

并非所有嵌入式环境都有相同的约束。限制是对您的嵌入式环境的限制，而不是对所有嵌入式环境的限制。但是，解决或避免类型协议(protocol)问题的“库的加载”似乎像是一把大锤，难以捉摸。

• free functions returning a valid int or long representing the byte count of T

目前尚不清楚这意味着什么。什么是“免费功能”？那只是一个非成员函数吗？这样的函数在内部必然具有类型大小写，因此除了隐藏类型强制转换之外，您还实现了什么？

• Don't use loops (gotta love that advice).

我怀疑您是否需要在列表中包含该建议。在任何情况下，问题都不限于循环。不是因为您正在使用循环而发出警告，而是因为您使用了类型不匹配的 <。