Hi,
Does rule A5-0-4 apply to range-based `for` loops? Technically, range-based `for` loops are syntactic sugar for iterator-based loops, so technically pointer arithmetic is happening under the hood. Consider this example:
The easy solution is to make `Foo` `final`, of course. But what about classes we don't have control over, like STL classes?
A range-based `for` loop would be performing pointer arithmetic over `std::vector<int>*` and `std::unique_ptr<int>*`. These classes are not `final`. Would that then violate A5-0-4?
Our static analyzer is flagging these use cases as non-compliant, but it feels overly strict. What's your view on this?
Thanks!
Does rule A5-0-4 apply to range-based `for` loops? Technically, range-based `for` loops are syntactic sugar for iterator-based loops, so technically pointer arithmetic is happening under the hood. Consider this example:
Code:
struct Foo /* final */
{
int x;
int y;
};
std::vector<Foo> v;
// Fill v...
for (x : v) // A5-0-4 violated here?
{
...
}The easy solution is to make `Foo` `final`, of course. But what about classes we don't have control over, like STL classes?
Code:
std::vector<std::vector<int>>
std::vector<std::unique_ptr<int>>A range-based `for` loop would be performing pointer arithmetic over `std::vector<int>*` and `std::unique_ptr<int>*`. These classes are not `final`. Would that then violate A5-0-4?
Our static analyzer is flagging these use cases as non-compliant, but it feels overly strict. What's your view on this?
Thanks!