Re: Why string's c_str()? [Overloading const char *()]

Discussion in 'C++' started by Alf P. Steinbach, Oct 31, 2013.

  1. On 30.10.2013 21:34, Paavo Helde wrote:
    >
    > Now let's say somebody comes along and cleans up some code to use your
    > string class instead of const char* in h():
    >
    > void h(const MyString& s) {
    > x.f(s);
    > }
    >
    > int main() {
    > h("foo");
    > x.g(); // BOOM!
    > }
    >
    > Everything compiles fine and may even run sometimes as expected, but
    > nevertheless the pointer which is stored is temporary and turns invalid
    > immediately after h() returns. Some innocent-looking code cleanup has
    > just created a dormant bug.


    Well that doesn't happen with MY string class. And so, lacking
    information about the OP's string class, it does not necessarily happen
    with that class either (although I suspect it would). In short, while
    the failure mode idea is in the right direction, you're making some
    assumptions here that do not necessarily hold, leading to an invalid
    conclusion about inherent danger of implicit conversion.

    In other words, a little fallacy. ;-)

    Equally important for discussing goodness and badness of something like
    this conversion, one must consider advantages and problems. The above
    scenario, when it happens, shows that implicit conversion can expose
    problems in bad code. This can be considered an advantage -- on top of
    the sheer convenience of the implicit conversion, when done properly.


    Cheers & hth.,

    - Alf
     
    Alf P. Steinbach, Oct 31, 2013
    #1
    1. Advertising

  2. On 02.11.2013 23:40, DSF wrote:
    >
    > What I would like to ask you, Mr. Steinbach, is how did you get around
    > the problem? The string doesn't know it's a temporary


    Well that's what it does. ;-)

    For the main string class this isn't a problem at all since every
    literal for that class is wrapped in a `Literal_string_<T, n>` object.

    But for each platform's derived class it's desirable to give the same
    treatment to plain `char` or (depending on the class) `wchar_t` string
    literals, and although they could be distinguished as literals in C++03,
    that involved passing them through a macro[1]. For C++11 a macro can't
    detect, since there's no distinguishing feature of a literal in C++11,
    but it can enforce[2]. However, I decided that convenience was important
    so instead of that enforcement macro I use a convention where any array
    of `char const` or `wchar_t const` is regarded as a literal.

    My convenience choice isn't quite as 100% safe as the enforcement macro
    route would be, but when one is aware of that convention then there's no
    real problem, since such arrays[3] simply do not occur naturally.


    Cheers & hth.,

    - Alf

    Notes:
    [1] In C++03 and C++98 a special rule allowed a string literal to decay
    to pointer to non-const, which constituted a distinguishing feature of
    string literals.
    [2] E.g. the expression `"" middle ""` is fine when `middle` is a
    literal narrow string, and otherwise it's generally a syntax error.
    [3] An array is not a pointer.
     
    Alf P. Steinbach, Nov 3, 2013
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,214
    Smokey Grindel
    Dec 2, 2006
  2. lovecreatesbeauty
    Replies:
    1
    Views:
    1,149
    Ian Collins
    May 9, 2006
  3. grishin
    Replies:
    1
    Views:
    756
    gwowen
    Nov 22, 2010
  4. Öö Tiib
    Replies:
    6
    Views:
    191
    Öö Tiib
    Nov 3, 2013
  5. Tobias Müller
    Replies:
    4
    Views:
    191
    Öö Tiib
    Nov 2, 2013
Loading...

Share This Page