Introduction

In normal use, std::to_string is considered thread-safe when multiple threads call it independently. Each call returns a new std::string object and does not rely on a shared static output buffer in the way some older C conversion functions do. The real thread-safety risks are usually elsewhere: shared destination objects, shared streams, or global locale changes.

What std::to_string Actually Does

std::to_string converts a numeric value into a std::string.

1#include <iostream>
2#include <string>
3
4int main() {
5    std::string s = std::to_string(42);
6    std::cout << s << "\n";
7}

Each call produces a new string value. That is the key reason concurrent independent calls are usually fine.

Why Independent Calls Are Usually Safe

If two threads do this:

std::string a = std::to_string(123);
std::string b = std::to_string(456);

there is no shared std::string object being mutated. Each thread gets its own return value.

That is very different from using APIs that return pointers to shared static buffers. In that older style, a second call can overwrite data from the first call. std::to_string does not have that design.

What Is Not Automatically Safe

Thread-safe function calls do not make surrounding code automatically thread-safe.

For example, this is unsafe if multiple threads write to the same string without synchronization:

1#include <string>
2
3std::string shared;
4
5void worker(int value) {
6    shared = std::to_string(value);
7}

The problem is not std::to_string. The problem is concurrent writes to shared.

Similarly, writing the result to a shared stream or data structure may require a mutex even if the conversion itself is harmless.

Locale and Global State Caveat

A subtle edge case is global C locale manipulation. If code elsewhere is calling setlocale concurrently, you have a broader program-level thread-safety problem. That is not unique to std::to_string, but it can affect library behavior in unpleasant ways.

In ordinary application code where the locale is not being mutated concurrently, this is usually not the practical concern.

Example with Threads

1#include <iostream>
2#include <string>
3#include <thread>
4#include <vector>
5
6void worker(int value) {
7    std::string s = std::to_string(value);
8    std::cout << s << "\n";
9}
10
11int main() {
12    std::vector<std::thread> threads;
13    for (int i = 0; i < 5; ++i) {
14        threads.emplace_back(worker, i * 10);
15    }
16
17    for (auto& t : threads) {
18        t.join();
19    }
20}

The conversions themselves are independent. The output order may interleave because std::cout is shared, but that is a stream-coordination issue, not a std::to_string issue.

Common Pitfalls

The biggest mistake is blaming std::to_string for races caused by concurrent access to shared strings, containers, or streams.

Another mistake is assuming that because the conversion is safe, every surrounding operation is also safe.

A third issue is ignoring global locale mutation or other unrelated shared state that can affect overall program correctness.

Summary

• Independent calls to std::to_string are generally safe across threads
• Each call returns a new std::string rather than using a shared static output buffer
• The real risks are usually shared destination objects, shared streams, or other global state
• If multiple threads write to the same object, you still need synchronization
• Distinguish function-level safety from whole-program thread safety