2

If I instantiate a lambda somewhere (and the compiler doesn't inline it), I can find a string showing where the lambda is located in my c++ code like this:

... ?AV<lambda_1>@?0??MyFunction@MyScopedClass@MyNamespace@@SAXXZ@ ...

I don't want this information in the executable, as it could give away important names of classes and functions.

All kinds of output debug information are turned off. If I use a normal function instead, the final executable doesn't have this information, so manually converting all lambdas into normal functions would "fix it". But what's the best way to handle this? Can we tell the compiler to transform lambdas into normal functions?

UPDATE: I tested with other compilers: g++ and clang. They both leave the same references. I also found another unanswered question about this Gcc - why are lambdas not stripped during release build Please don't come with the "why do you care about a few symbols anyway".

Here's some code you can test with:

#include <iostream>
#include <functional>

class MyUnscopedClass
{
public:
    MyUnscopedClass(const std::function<void(int x)>& f) :
        f(f)
    {

    }
    std::function<void(int x)> f;
};

namespace MyNamespace
{
    class MyScopedClass
    {
    public:
        static void temp1(int x)
        {
            std::cout << x * (x + 1);
        }

        static void MyFunction()
        {
            //MyUnscopedClass obj(temp1); // no symbols
            MyUnscopedClass obj([](int x) // ?AV<lambda_1>@?0??MyFunction@MyScopedClass@MyNamespace@@SAXXZ@
                {
                    std::cout << x;
                });

            obj.f(23);
        }
    };
}

int main()
{
    MyNamespace::MyScopedClass::MyFunction();
}
user1000
  • 79
  • 2
  • 9
  • What version of VC++? The automatic lambda name is a mangled guid since at least VS [2017](https://stackoverflow.com/questions/52218665/change-compiler-generated-c-lambda-name-to-human-readable-one). – dxiv Oct 10 '20 at 02:11
  • _MSC_VER is defined to 1927 – user1000 Oct 10 '20 at 02:29
  • That would be VS 2019 16.7 but it does not duplicate for me. Pasting your code into a default wizard generated C++ console app, the release mode EXE only contains `?AV@@` in both x86 and x64 builds with VS 16.7.5. – dxiv Oct 10 '20 at 02:38
  • That's strange. Maybe I tweaked some setting wrong in the compiler settings? – user1000 Oct 10 '20 at 02:39
  • Quite strange, indeed. Not sure what setting that could be. – dxiv Oct 10 '20 at 02:42
  • Wow! That's so weird. I found the setting. Configuration Properties > General > C++ Language Standard. Apparently the setting "Preview - Features from the Latest C++ Working Draft (std:c++latest)" causes this issue – user1000 Oct 10 '20 at 02:45
  • By the way, any idea what the identifier f65614ace4683bbc78b79ad57f781b7f means? – user1000 Oct 10 '20 at 02:48
  • Funny, +1 if you post it as a self-answer. Don't know that the id has any particular significance, except probably being unique in some context. – dxiv Oct 10 '20 at 02:51
  • It's sad that my code used some c++20 features like std::set::contains, so I will have to refactor :( – user1000 Oct 10 '20 at 02:55

1 Answers1

1

With the help of @dxiv in the comments, I found the problematic setting.

Configuration Properties > General > C++ Language Standard

can't be, for some reason,

Preview - Features from the Latest C++ Working Draft (std:c++latest)

So I set it to the second most recent one

ISO C++17 Standard (std:c++17)

and I get a random identifier instead.

AV<lambda_f65614ace4683bbc78b79ad57f781b7f>@@

I'm still curious how this identifier is chosen though.

user1000
  • 79
  • 2
  • 9
  • I find it hard to believe that this is intended behavior for whatever reasons, so I suggest you file an official report at https://developercommunity.visualstudio.com/spaces/62/index.html. – dxiv Oct 10 '20 at 03:07
  • 2
    I did, let's see. – user1000 Oct 10 '20 at 03:31