False positive warning PVS Studio: V808 object of type was created but was not utilized

Question

PVS Studio 6.17 (Windows 7, 64Bit, VS2015) seems to give a wrong warning on the code below. Warning "V808 'statuses' object of 'unordered_map' type was created but was not utilized". Original code with unordered_map initialized with several QStringLiteral key values. Simplified version using only STL looks like this:

#include <string>
#include <unordered_map>
#include <iostream>

// Simplified analogue of QStringLiteral
#define StringLiteral(str) ([]() { return std::string{str}; }())

int main()
{
    const std::unordered_map<std::string, int> statuses{
        { StringLiteral("aaa"), 1 },
        { StringLiteral("bbb"), 2 },
        { StringLiteral("ccc"), 3 }
    };

    auto iter = statuses.find("aaa");
    if (iter != statuses.cend())
        std::cout << iter->first << " has status: " << iter->second << std::endl;
    return 0;
}

Curiously is that V808 produced when universal initialization of the return value in lambda is used. If use the constructor function syntax, the warning is not displayed.

Another false case producing V808 is here:

const std::unordered_map<int, std::function<void(int, int)>> functions{
    { 0, [](int a, int b) {} },
    { 1, [](int a, int b) {} },
};

const auto it = functions.find(0);
if (it != functions.cend() && it->second)
    it->second(1, 2);

Here if create map with one argument lambdas - no V808, with 2 or more agruments it presents.

Reference:

• https://www.viva64.com/en/w/v808/

Is that issue known?

Answer 1

Please, don't create questions of such types. Stackoverflow users have repeatedly commented on similar issues.

1. There is actually nothing to answer. It is simply a description of underworking, rather than a question. Bug reports and feature requests are not on-topic here on Stack Overflow. I’d like to ask you to just write on our support in similar situations.
2. Please, check that for written synthetic examples the analyzer generates a warning. I haven't been able to reproduce the false positive by checking published code. I guess the code contains something that confuses the analyzer. Or the analyzer might be right, if, for example, the usage is inside the inactive construction #if...#endif.