如果你有QT，如果你懒得实现一个函数和东西，你可以使用

std::string str;
QString(str).toStdWString()

你的问题不明确。严格来说，这个例子是一个语法错误。然而，std::mbstowcs可能是您正在寻找的。

它是一个c库函数，操作缓冲区，但这里有一个易于使用的习语，由Mooing Duck提供:

std::wstring ws(s.size(), L' '); // Overestimate number of code points.
ws.resize(std::mbstowcs(&ws[0], s.c_str(), s.size())); // Shrink to fit.

int StringToWString(std::wstring &ws, const std::string &s)
{
    std::wstring wsTmp(s.begin(), s.end());

    ws = wsTmp;

    return 0;
}

您可以使用boost路径或std路径;这样就简单多了。 Boost路径更容易用于跨平台应用程序

#include <boost/filesystem/path.hpp>

namespace fs = boost::filesystem;

//s to w
std::string s = "xxx";
auto w = fs::path(s).wstring();

//w to s
std::wstring w = L"xxx";
auto s = fs::path(w).string();

如果你喜欢使用std:

#include <filesystem>
namespace fs = std::filesystem;

//The same

c++旧版本

#include <experimental/filesystem>
namespace fs = std::experimental::filesystem;

//The same

代码内仍然实现了一个转换器，你不必解开细节。

这是一种将字符串，wstring和混合字符串常量组合到wstring的方法。使用wstringstream类。

这并不适用于多字节字符编码。这只是一种抛弃类型安全并将std::string中的7位字符扩展到std:wstring中每个字符的下7位的愚蠢方法。只有当你有一个7位ASCII字符串并且你需要调用一个需要宽字符串的API时，这才有用。

#include <sstream>

std::string narrow = "narrow";
std::wstring wide = L"wide";

std::wstringstream cls;
cls << " abc " << narrow.c_str() << L" def " << wide.c_str();
std::wstring total= cls.str();

假设您的示例(おはよう)中的输入字符串是UTF-8编码的(从表面上看，它不是，但为了解释起见，让我们假设它是您感兴趣的Unicode字符串的表示形式:-)，那么您的问题可以仅通过标准库(c++ 11或更新版本)完全解决。

TL;DR版本:

#include <locale>
#include <codecvt>
#include <string>

std::wstring_convert<std::codecvt_utf8_utf16<wchar_t>> converter;
std::string narrow = converter.to_bytes(wide_utf16_source_string);
std::wstring wide = converter.from_bytes(narrow_utf8_source_string);

更长的在线可编译和可运行的示例:

(它们都展示了相同的例子。只是有很多冗余……)

http://ideone.com/KA1oty http://ide.geeksforgeeks.org/5pRLSh http://rextester.com/DIJZK52174

备注(旧):

正如评论中指出并在https://stackoverflow.com/a/17106065/6345中解释的那样，在使用标准库在UTF-8和UTF-16之间进行转换时，在不同的平台上可能会产生意想不到的结果差异。为了更好的转换，请考虑http://en.cppreference.com/w/cpp/locale/codecvt_utf8上描述的std::codecvt_utf8

备注(新):

由于codecvt头文件在c++ 17中已弃用，因此有人对这个答案中提出的解决方案提出了一些担忧。然而，c++标准委员会在http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0618r0.html中增加了一项重要声明

这个库组件应该退役到附件D中，直到一个合适的替换被标准化。

所以在可预见的未来，这个答案中的codecvt解决方案是安全的和可移植的。