🚀 go-pugleaf

Distribution:
David Vandevoorde (vandevod@cs.rpi.edu) wrote:
: >>>>> "OB" == Oren Ben-Kiki <oren@melissa.schema.co.il> writes:
: In article <MATT.95Aug16093212@physics2.Berkeley.EDU>
: oren@melissa.schema.co.il (Oren Ben-Kiki) writes:
: Rick Hollinbeck (rickh@csn.net) wrote:

: Rick> From what I understand, the const char* conversion operator
: Rick> would trigger : too many implicit type conversions in certain
: Rick> situations, leading to many : unpleasant surprises. the c_str()
: Rick> member is a way to control this. (See : Plauger's recent article
: Rick> in the C/C++ Users Journal which discusses this.)

: OB> But now that we have the 'explicit' keyword, shouldn't this
: OB> decision be reconsidered? This seems like just the situation for
: OB> which it was intended.

: The `explicit' keyword is currently only applicable to constructors,
: not conversion operators.

Hmmm. At first I felt foolish for missing that, but on a second thought, why
is it so? Sometimes the choice between a constructor for one class and a
conversion operator for another is pretty arbitrary - and when the target
type is a built-in type, as in this case, the choice is made for you by the
compiler.

: Do you think:

:       f(static_cast<char*>(s))

: is more convenient than:

:       f(s.c_str())    ?

Point taken. I was thinking more of:

        f((char *)s)

But I guess that's just a bad habit left over from my C days.

                                                Oren.


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]