David Vandevoorde (vandevod@cs.rpi.edu) wrote:
> Do you think:
>
>       f(static_cast<char*>(s))
>
> is more convenient than:
>
>       f(s.c_str())    ?

Yes.  The first one makes writing general template functions easier.
The second one hinders it.

Atman Binstock
ajb@panix.com
---
[ 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. ]

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. ]

Distribution:
Oren Ben-Kiki (oren@melissa.schema.co.il) wrote:

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

I don't think this will work, since 'const char *' is not a class, and
therefore cannot have its constructor declared as explicit.
As far as I understand, the explicit keyword can only be applied to type
conversion constructors (not operator functions like 'operator const char *').


---
[ 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. ]

Don & (bashford@toad.scripps.edu) wrote:
: According to Plauger's book on the Draft Standard C++ library,
: there is no "operator const char *" for the string class.
: This means that you cannot do things like,

:   string filename;
:   // ...
:   ofstream ofile(filename);

: Alot of my code has things like this (I have been using the
: String class of libg++) and I suspect this is rather common
: apparently we will all have to change to:

:   ofstream ofile(filename.c_str());

: which will be incompatable with any other string class that
: does not have a c_str function (String of libg++ does not).

: Is there any compelling reason for not having the conversion
: to const char* as part of the standard?

: Don Bashford
: bashford@scripps.edu

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

In article <MATT.95Aug13161131@physics2.Berkeley.EDU>,
rickh@csn.net (Rick Hollinbeck) wrote:
>Don & (bashford@toad.scripps.edu) wrote:
>: According to Plauger's book on the Draft Standard C++ library,
>: there is no "operator const char *" for the string class.
<snip>
>: Is there any compelling reason for not having the conversion
>: to const char* as part of the standard?
>
>>From what I understand, the const char* conversion operator would trigger
>too many implicit type conversions in certain situations, leading to many
>unpleasant surprises. the c_str() member is a way to control this. (See
>Plauger's recent article in the C/C++ Users Journal which discusses this.)

Implicit conversions are indeed the major bugaboo.  See also Scott Meyers'
article in the August CUJ.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter                 2228 Urwin, Ste 102         voice (416) 618-0184
Connected Object Solutions  Oakville ON Canada L6L 2T2    fax (905) 847-6019
---
[ 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. ]

Distribution:
Rick Hollinbeck (rickh@csn.net) wrote:
: Don & (bashford@toad.scripps.edu) wrote:
: : According to Plauger's book on the Draft Standard C++ library,
: : there is no "operator const char *" for the string class.
: : [snip]

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

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

---
[ 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. ]

In article <VANDEVOD.95Aug16144504@avs.cs.rpi.edu>, vandevod@cs.rpi.edu=
 (David Vandevoorde) writes:
[..]
|> The `explicit' keyword is currently only applicable to constructors,
|> not conversion operators. Do you think:
|>=20
|>  f(static_cast<char*>(s))
|>=20
|> is more convenient than:
|>=20
|>  f(s.c_str()) ?

Yes. I know, I want the string represented as something of type const c=
har*,
so I call static_cast<const char*>. IMHO it's inconvienent to look up t=
he
class to find that I need to call a method called c_str() to get a cons=
t char*.
Using methods for conversions results in _globally_ inconsistent naming=
 schemes:
string uses c_str() other classes/libraries (eg myVector, mySet) may us=
e
toString() or toCharptr() and other classes call it stringify() etc.


Ulf Schuenemann

--------------------------------------------------------------------
Ulf Sch=FCnemann
Fakult=E4t f=FCr Informatik, Technische Universit=E4t M=FCnchen, German=
y.
email: schuenem@informatik.tu-muenchen.de
WWW:   http://www.informatik.tu-muenchen.de/cgi-bin/nph-gateway/hphalle=
2/~schuenem/index.html

[ 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. ]

According to Plauger's book on the Draft Standard C++ library,
there is no "operator const char *" for the string class.
This means that you cannot do things like,

  string filename;
  // ...
  ofstream ofile(filename);

Alot of my code has things like this (I have been using the
String class of libg++) and I suspect this is rather common
apparently we will all have to change to:

  ofstream ofile(filename.c_str());

which will be incompatable with any other string class that
does not have a c_str function (String of libg++ does not).

Is there any compelling reason for not having the conversion
to const char* as part of the standard?

Don Bashford
bashford@scripps.edu