Actually I just encountered this and it does work but I don't prefer to do it. The main reason is because from the code or from a header one could not deduce that a const char * could be passed in or should be passed in.
Caller:
Code:
...
const char *pText = "test";
Foo(pText);
...
...
void Foo(const std::string &text)
{
std::cout << text.c_str() << std::endl;
}
Believe it or not but due to conversion operators in std::string this code actually works and compiles. It's extremely ugly but it is one way to get around DLL issues with using STL strings in interface functions. If you just pass in const char * from the client of the DLL it works. It also works correctly since the conversion is done in the DLL and uses the STL version in the DLL. In fact there is no way to get an STL version mistmatch.
However, as I said, this is not clearly communicated from the interface (IE: Foo() at first glance seems to require const std::string& - it isn't clear that const char * will work).
I just tested this code in 2005 in a single project console app and it worked fine. I did not test it with Foo() being in a DLL but I know it works b/c I ran into at my job.
So yes it does work but I do not recommend doing it this way unless you have to....like if you would have to modify many many DLL interfaces to use const char * instead of const std::string& then it might be useful but only if it was well documented.