如果我需要c++字符串内容的可变原始副本，那么我会这样做:

std::string str = "string";
char* chr = strdup(str.c_str());

后来:

free(chr); 

So why don't I fiddle with std::vector or new[] like anyone else? Because when I need a mutable C-style raw char* string, then because I want to call C code which changes the string and C code deallocates stuff with free() and allocates with malloc() (strdup uses malloc). So if I pass my raw string to some function X written in C it might have a constraint on it's argument that it has to allocated on the heap (for example if the function might want to call realloc on the parameter). But it is highly unlikely that it would expect an argument allocated with (some user-redefined) new[]!

为了完整起见，不要忘记std::string::copy()。

std::string str = "string";
const size_t MAX = 80;
char chrs[MAX];

str.copy(chrs, MAX);

std::string::copy()不终止NUL。如果你需要确保在C字符串函数中使用NUL终止符:

std::string str = "string";
const size_t MAX = 80;
char chrs[MAX];

memset(chrs, '\0', MAX);
str.copy(chrs, MAX-1);

OOP风格的转换

converter.hpp

class StringConverter {
    public: static char * strToChar(std::string str);
};

converter.cpp

char * StringConverter::strToChar(std::string str)
{
    return (char*)str.c_str();
}

使用

StringConverter::strToChar("converted string")

更多细节在这里，还有这里，但你可以用

string str = "some string" ;
char *cstr = &str[0];

从c++ 11开始，还可以使用str.data()成员函数，该函数返回char *

string str = "some string" ;
char *cstr = str.data();

char* result = strcpy((char*)malloc(str.length()+1), str.c_str());

如果我需要c++字符串内容的可变原始副本，那么我会这样做:

std::string str = "string";
char* chr = strdup(str.c_str());

后来:

free(chr); 

So why don't I fiddle with std::vector or new[] like anyone else? Because when I need a mutable C-style raw char* string, then because I want to call C code which changes the string and C code deallocates stuff with free() and allocates with malloc() (strdup uses malloc). So if I pass my raw string to some function X written in C it might have a constraint on it's argument that it has to allocated on the heap (for example if the function might want to call realloc on the parameter). But it is highly unlikely that it would expect an argument allocated with (some user-redefined) new[]!