3

What are the dangers of using an implicit string conversion operator in a custom string class?

class MyString
{
public:

   ...

   inline operator string() const { return str; }

private:
   std::string str;
};
Marc A.
  • 148
  • 11
  • What are you trying to do? It seems like all you are doing here is incurring extra overhead since you are just returning the same string. – Lawrence Aiello May 29 '15 at 14:07
  • 2
    You should figure out if you really want the conversion to make a copy of the string. – juanchopanza May 29 '15 at 14:23
  • MyString is essentially a wrapper to std::string however it deletes the char* operator to protect it against non-null terminated char arrays. I'd like to be able to change std::string to MyString and get that protection while maintaning backwards compatibility. This means that assignments to std::string need to work. – Marc A. May 29 '15 at 14:25
  • whaaaat.... well how are you going to construct your objects if not from string literals (char *) (maybe c++14 UDL). second, why not just inherit the damn class and prohibit that operator and constructor. third don't do that. Don't reinvent the whole standard library. Work with `std::string` as it is. Your reason is not a good one to cook your own string implementation. Just be a little careful how you use `std::string` – bolov May 29 '15 at 14:30
  • String literals is a null-terminated array of constant char so you can create a constructor for `const char*`. std::string should NOT be inherited. basic_string was not designed to be derived from. It doesn't have any virtual functions. – Marc A. May 29 '15 at 14:36
  • @MarcA. Just because a class doesn't have virtual functions doesn't mean it shouldn't be derived from. Yes there can possibly be nasty side effects if you decide to change the implementation of something and refer to your strings via `std::string`, but your implicit conversion is no better. – miguel.martin May 29 '15 at 14:38
  • @miguel.martin std::string doesn't have a virtual destructor. See http://stackoverflow.com/questions/6006860/why-should-one-not-derive-from-c-std-string-class – Marc A. May 29 '15 at 14:40
  • @MarcA. So what? Private inheritance is effectively what you're doing (in your quite abstract example), assuming you're only using `MyString` as a simple wrapper over `std::string` and don't want the object to be used polymorphically. And before you bring up slicing. Slicing on an object using inheritance is basically what your conversion operator is doing. An obvious pitfall of private inheritance is you can't change how conversion is done from `MyString` to `std::string`, which you might want in the future. In which case the way you've implemented things is better. – miguel.martin May 29 '15 at 15:17
  • @MarcA. And by not used polymorphically, I mean avoiding ```std::string* str = new MyString; delete str;```. However, this is *not* possible with private inheritance. – miguel.martin May 29 '15 at 15:19

1 Answers1

3

The main "danger" of implicit conversion is mostly: You might get an unexpected conversion.

If your string class can logically be used as a std::string, I do not think there is a problem.

RedAgito
  • 405
  • 2
  • 8