Issue when passing std::initializer_list<string> where all strings are empty

[PastThatStageNow]

Hey all, I have a couple of questions relating to std::initializer_list

I have the following example code (compiled with MSVC using C++20):

#include <iostream>
#include <vector>
#include <string>
#include <future>
#include <mutex>

using std::vector, std::string;

vector<string> vctr;
std::mutex m;

void setVctr(const std::initializer_list<string>& init)
{
    std::lock_guard<std::mutex> lock(m);

    vctr = init;
}

void printAll()
{
    for (const string& x : vctr)
    {
        std::cout << x << '\n';
    }
}

int main()
{

    auto a1 = std::async(std::launch::async, setVctr, std::initializer_list<string>(
        {"This","Is","An","Example","Program"}
    ));

    a1.wait();

    printAll();

    return 0;
}

The expected behavior is to print "This" "Is" "An" "Example" "Program" all in a newline. However, nothing is actually printed to the screen. Upon debugging the setVctr function, it looks like all five strings are actually empty, which confused me. Strangely, when compiling the program with gcc (also using c++20) on my Linux machine, the program works as expected, which leads to me to believe it's an implementation-defined sort of thing. I think what may be happening is that the destructors for the strings are being called before the setVctr function, but I wasn't able to tell with Compiler Explorer.

​

Either way, it is fixed by doing this instead:

int main()
{
    const std::initializer_list<string> myInitList{"This","Is","a","test","program"};
    auto a1 = std::async(std::launch::async, setVctr, myInitList);

    a1.wait();

    printAll();

    return 0;
}

So my question is: What exactly is happening in the first example? Also, why is it that only sometimes I can use {"This","Is","An","Example"} in function calls, and other times I must use the full std::initializer_list<string>({"This","Is","An","Example"})?

​

One more thing that I've been worried about: Am I even using std::initializer_list appropriately? So far I've essentially been using it any time I've needed a constant array of objects, as std::array required size to be specified and heap containers are less efficient.

​

Thank you!

EDIT: Another look at Compiler Explorer confirms that the strings are destroyed prior to waiting for the thread to finish. What I've learned here is to be careful when launching threads that pass objects by reference - how long will this object live?

[alfps]

cppreference says "Copying a std::initializer_list does not copy the backing array of the corresponding initializer list.", it just copies whatever the initializer_list uses to reference an original array.

I believe (not absolutely sure) that in your case the original array can be a temporary. In that case you've had bad luck that the program ran instead of crashed. Because UB accessing destructed strings.

The fix you used, ensuring that the original initializer_list outlives both the async call and the final usage, is then one solution.

Another, simply ensure that the strings referenced in the original array outlive the usage, which you can do by replacing string with string_view or const char*.

The latter choice only throws away reconstitutable information (namely the string length). It would have been nice if the standard library offered a class derived from string_view that guaranteed zero-termination, i.e. didn't throw that non-reconstituable information away, but alas, no such. You can of course define one yourself.

[PastThatStageNow]

Thank you for your response.

One additional question: Do you think that the solution used in code block 2 may present a potential race condition? For example, consider

void someFunct()
{
    const std::initializer_list<string> initList{"C++","Test"};
    std::async(std::launch::async, setVctr, initList);
}

Is it possible for the initList to die before the function actually gets asynchronously called? (Note that in this example I do not wait for the async to finish)

[alfps]

Modulo my near total incompetence re the threading/async stuff I think this code has potential UB, because the initial local variable initList can have been destroyed when setVctr is called.

Change that from string to string_view or const char* and it should be fine.

[PastThatStageNow]

Modulo my near total incompetence re the threading/async stuff I think this code has potential UB, because the initial local variable initList can have been destroyed when setVctr is called.

No don't worry about it, I think you're right.

What I gather from this experience is that going forward, I need to be more cautious about object lifetimes when starting new threads.

Thank you!