C++/STL Wankery

In C++, can I define a typecast operator for converting (both ways) between std::string and const char *?

In the end, I just want to avoid having to declare every function twice:


   void func1(const char *x) { func1(std::string(x)); }
   void func1(std::string x);

   void func2(const char *x) { func2(std::string(x)); }
   void func2(std::string x);

   void func3(const char *x) { func3(std::string(x)); }
   void func3(std::string x);

>>1

fuck you faggot

>>2
Yes, I'm totally a homo and not even worth being shit on by the /pork/ elite, I know.  But I googled and googled and found nothing.  All I find are millions of messageboard posts about "how do I convert from string to char*".  Call c_str(), I know.  But I just want it to happen automatically.

>>1
suck dick faggot

Conforming std::string implementations have an implicit constructor that accepts a char const*, so all you have to do is write functions that accept std::string, and you can pass char*'s and string literals to it.

As for the other way around, it should be up to the programmer to call std::string::c_str explicitly when a char* is needed. If you don't like it, then that means you've probably got autism/obsessive-compulsive disorder.

The following code should work. If it does not, your compiler/standard library is probably old-ass fucking shit and it's time to upgrade.


void func_sepples(std::string x) {
// abstract bullshite
}

void func_holy_shit(char const* x) {
// abstract bullshite
}

int main() {
    std::string s("faggot");
    func_sepples("fuck you");
    func_holy_shit(s.c_str());
    return 0;
}

>>5
Also, I forgot, you should always pass std::string by const reference when you can, to avoid new copies from being constructed.

Should be:

void func_sepples(std::string const& x) {
// abstract bullshite
}

>>1
If your corefunction that uses the string is supposed to work with std::string, like so:


void stuff(const std::string& str)
{
    std::string::iterator iter;
    for(iter=str.begin(); iter!=str.end(); iter++)
    {
        // ...
    }
}

Then you should declare the function that takes const char* like so:

void stuff(const char* str, unsigned int length)
{
    stuff(std::string(str, length));
}

>>1
No, there's no way to do that. The best you can do is an implicit cast operator, which can be quite dangerous. Consider the following valid code:

void func(const std::string &test) {
    // cod
}

void func(int test) {
    // cod
}

void func_call() {
    func(0);
}

Because std::string has an implicit cast operator from char *, passing the integer value of 0 (which doubles as a null pointer value) will compile fine. Even worse, this confuses the function overloading.

I think I accidentally ran into this once and MSVC chose the string overload even though it made no sense to me at the time to choose that one. I'm not sure if the standard defines how this should work (I don't think it does, maybe Sepplesoxa does because it has nullptr - but then again, lol no because it still supports 0 to maintain backward compatibility), so you can bet your ass that if any two implementations perform the same way, it's a freak accident.

In short, you're much better off setting yourself up for success by not using Sepples.

>>8
It calls func(int).

You're really bad at trolling.

>>9
So it does. I wasn't actively trying to troll. Seems I remembered the issue incorrectly. The issue is that you can return 0 from a function that is supposed to return std::string. Consider:

std::string func(bool val) {
    if (val) return 0;
    std::string str = "a";
    return str;
}

int main(int argc, char *argv[]) {
    std::cout << func(false) << std::endl;
    std::cout << func(true) << std::endl;
    getchar();
    return 0;
}

It gives you an access violation and in a debug build, it sends you into the black pits of their standard libraries, but at least with the proper call stack state.

I remember it not faring so well on VS2008. I think that I ended up with an access violation when attempting to use the string instead. I also think I hit this when I changed a function signature and it was compiling fine so I didn't notice until it fucked up.

Not nearly as bad as confusing function overloading, but still costly if you have no idea what the fuck.

>>10
So? In most C++ stdlibs, NULL is a macro that expands to 0, so ending up with an access violation is expected behaviour, since it equals a nullpointer.

>>11
Yeah, in C++98, 0 is the null pointer constant, and the NULL macro was deprecated.

Pretty retarded. Thank god C++0x brings us the nullptr keyword.

>>11
So? That's not relevant in the slightest to what I said. You're supposed to get an access violation with a null pointer. The point clearly has very little to do with there being an access violation.  The point is that you can't catch an error of that sort until runtime.

>>12
I suspect you could do the same thing with nullptr because it's implicitly convertible to any pointer type too. Yep. I just tried it out. The only difference is that it's far harder to fuck up and use nullptr than it is to fuck up and use 0. Which is a good thing.. I guess.