Pete Becker <petebecker@acm.org> writes:

|>  Francis Glassborow wrote:

|>  > Possibly as we are tending towards being more tolerant of pure
|>  > extensions (ones that cannot break existing code)

|>  Perhaps some of us are, but others of us will still resist extensions=
 in
|>  the guise of defect reports.

Agreed.  For better or for worse, ISO has established a certain way of
doing things.  If we don't agree, and want a new version of the language
every couple of months, we should consider the Java model.  Having
suffered with it with Java, I certainly don't want to go this route with
C++.

Let's give the implementers time to implement what we've got before we
go adding things.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A551174.D1A3560A@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Francis Glassborow wrote:
>>
>> Possibly as we are tending towards being more tolerant of pure
>> extensions (ones that cannot break existing code)
>>
>
>Perhaps some of us are, but others of us will still resist extensions in
>the guise of defect reports.

How much more tentative should I have been 'possibly', 'tending'
'tolerant'. And for the record those who were at the Dublin meeting will
remember that I was one of the strongest opposers of any attempt to
bring in any kind of extension in the guise of a defect report.


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

sirwillard@my-deja.com writes:

|>  > Maybe the fact that std::basic_string<> has c_str is an indication
|>  > that it was not considered a useful concept.

|>  No, it's not an indication.  It could be considered an example of
|>  why some think the idea not worth adding to the language, but that's
|>  not the same as an indication that it was considered at all, whether
|>  considered useful or otherwise.  Another post on this thread
|>  indicates that the feelings were (understandably) mixed, but that
|>  thorough discussion and evaluation was never made.

In fact, std::string had c_str before explicit was even proposed.

With regards to this question, it would seem that the committee actually
did discuss the issue, although apparantly, the original proposal did
not include it.  How deeply the issue was discussed, of course, I don't
know, but the fact that it was considered and rejected means that its
absense cannot be considered as an oversight or a defect.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

jpotter@falcon.lhup.edu (John Potter) writes:

|>  > I tried to locate discussions on this topic before posting and
|>  > failed to find anything.  What seach criteria did you use?

I prefer c_str in code that I write as well (or asCString, or any named
function).  On the other hand, it is a bit more awkward in templates.
Conversion of std::string to char const* probably isn't an issue; it's a
special case, and so probably won't come up in templates other than
those which explicitly use std::basic_string anyway, but what's the
standard name I should use in my BigFloat class to convert to double?

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Matthew Austern" <austern@research.att.com> wrote in message news:dilu27d6e8g.fsf@isolde.research.att.com...
> It would certainly come in handy for people who want to write
> "smart pointers".  If D inherits from B, then, for ordinary
> pointers, you have the property that there is an implicit
> conversion from D* to B*, there is no explicit conversion
> from from B* to D*, but users can explicitly convert from B*
> to D* by writing static_cast<D*>(pB).  I don't think there's
> any way to write a smart pointer class that has all of those
> properties.

That's a good example.  It works ok because you are dealing with
pointers, and pointers have no userdefined conversions that can play
tricks on you.

But in general using static_cast with template parameter types is not
such a good idea. static_cast is a very unsafe conversion if you don't
know the exact types you are dealing with. See my other post entitled
``static_cast<ofstream>("Hello world.txt");''.  (If it hasn't arrived
at your server yet, don't worry.  You don't need to actually read that
post.  Just think about the title and my point should be obviuous ;-))

Below follows an example of how a seemingly plausible static_cast can
go bad and cause a conversion between classes that are supposed to be
unrelated. This code compiles and is to the best of my knowledge
legal.

template<class T>
class smart_pointer
{
    T* m_ptr;
    char const * m_debug_info;
public:
    explicit smart_pointer(char const* debug_info, T* ptr = 0)
 : m_ptr(ptr), m_debug_info(debug_info) {}

    template<class U>
    operator U*() { return static_cast<U*>(m_ptr); }
};

class A {};

int main(int argc, char* argv[])
{
    smart_pointer<char> sp("'sp' in main()", new char);

    // Converting from smart_pointer<char> to smart_pointer<A>
    // using static_cast shouldn't be possible, but it is:
    smart_pointer<A> u = static_cast<smart_pointer<A> >(sp);
}


This is just an illustration, this specific code is not hard to fix.
Adding more constructors and conversion operators will quickly make
the offending conversion ambiguous, and perhaps also adding the
proposed "explicit" to the templated conversion operator would be
enough to make the unfortunate conversion illegal, I'm not sure.  Can
a single static_cast perform two explicit conversions?

I don't think we need to make unsafe conversions more convenient.

--
Anders Munch, software engineer, Dancontrol A/S, Denmark
Still confused but at a higher level.  Remove  from my email address.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote:
>
> In article <3A551174.D1A3560A@acm.org>, Pete Becker <petebecker@acm.org>
> writes
> >Francis Glassborow wrote:
> >>
> >> Possibly as we are tending towards being more tolerant of pure
> >> extensions (ones that cannot break existing code)
> >>
> >
> >Perhaps some of us are, but others of us will still resist extensions in
> >the guise of defect reports.
>
> How much more tentative should I have been 'possibly', 'tending'
> 'tolerant'. And for the record those who were at the Dublin meeting will
> remember that I was one of the strongest opposers of any attempt to
> bring in any kind of extension in the guise of a defect report.
>

The words that prompted your comment were:

>if enough people think this idea appropriate and given the assumptions you
>claim, maybe the stretch should be made?

In that context, it wasn't clear to me that you were saying that this
stretch would be unacceptable. Thank you for clarifying.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Just curious...

Did the explicit keyword get considered for use with cast operators?
It would be nice to be able to delcare a cast operator but prevent
implicit casts using this operator.  On the surface this sounds simple
and is in line with explicit construction so I wonder why the explicit
key word is restricted to constructors.  Is there some syntactic
nightmare that would result from allowing explicit cast operators?

Example:

class foo
{
public:
   explicit operator bar();
};

void use_bar(bar b)
{
}

int main()
{
   foo f;
   use_bar(f);  // diagnostic
   use_bar(static_cast<bar>(f)); // compiles
}

This construct could have been used in place of
std::basic_string<>::c_str() for an example of why this could be
considered a good concept.

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com
http://www.deja.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

That's really a wonderful idea. I wish I'd thought of it.

-Dave

<sirwillard@my-deja.com> wrote in message
news:93076q$rdl$1@nnrp1.deja.com...
> Just curious...
>
> Did the explicit keyword get considered for use with cast operators?
> It would be nice to be able to delcare a cast operator but prevent
> implicit casts using this operator.  On the surface this sounds simple
> and is in line with explicit construction so I wonder why the explicit
> key word is restricted to constructors.  Is there some syntactic
> nightmare that would result from allowing explicit cast operators?
>
> Example:
>
> class foo
> {
> public:
>    explicit operator bar();
> };
>
> void use_bar(bar b)
> {
> }
>
> int main()
> {
>    foo f;
>    use_bar(f);  // diagnostic
>    use_bar(static_cast<bar>(f)); // compiles
> }
>
> This construct could have been used in place of
> std::basic_string<>::c_str() for an example of why this could be
> considered a good concept.
>
> --
> William E. Kempf
> Software Engineer, MS Windows Programmer
>
>
> Sent via Deja.com
> http://www.deja.com/
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
> [ Note that the FAQ URL has changed!  Please update your bookmarks.     ]
>



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

sirwillard@my-deja.com wrote:
>
> Did the explicit keyword get considered for use with cast operators?

I don't know. But I know why I wouldn't like it to be used:

The purpose of conversion operators is to allow *implicit* conversions. If
you want an explicit conversion, why not write a regular member function:

use_bar(f.as_bar());

?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <06e001c07605$b822b410$0500a8c0@dragonsys.com>,
  "David Abrahams" <abrahams@mediaone.net> wrote:
> That's really a wonderful idea. I wish I'd thought of it.

*laughs*  I take it from that remark that it was never even considered
by the Standards Committee?  Surprising, considering how obvious
an "extension" to explicit constructors that it is.

So, should the next revision add such an extension?  Are any compiler
writers who read this interested in adding it as an extension to get us
some "prior art"?  I *really* think this sort of extension would be
useful.

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com
http://www.deja.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

sirwillard@my-deja.com wrote:
>
> Just curious...
>
> Did the explicit keyword get considered for use with cast operators?
> It would be nice to be able to delcare a cast operator but prevent
> implicit casts using this operator.

The history of "explicit" is a concatenation of implicit :-) assumptions.

The proposer of "explicit", and a few other people on the C++ committee,
assumed the proposal applied to type conversion operators as well as to
constructors, but the proposal didn't mention operators.

Most other people, since the proposal did not mention operators, assumed
it was intended to apply only to constructors.

The subject of operators came up during some discussions, but it was
pointed out that you never need "explicit" for operators.  If you
don't want implicit conversions, you can write a named function instead
of an operator.  Example:

class T {
public:
 operator int(); // allows implicit conversion to int
 long to_long(); // for explicit conversion to long
};

(The named-function approach is not always as convenient, however.)

Even though the wording as voted on and adopted did not mention
operators, some people on the C++ committee still assumed that
"explicit" could be used on operators.

Only after the final approved standard was published were the
implicit assumptions revealed explicitly. :-)

--
Steve Clamage, stephen.clamage@sun.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

On Thu,  4 Jan 2001 18:30:09 GMT, "David Abrahams"
<abrahams@mediaone.net> wrote:

> That's really a wonderful idea. I wish I'd thought of it.

You're joking?  Try a power search on deja.  It comes up about every
six months for many years.  This is the shortest time span since it
was just discussed in December.

> <sirwillard@my-deja.com> wrote in message
> news:93076q$rdl$1@nnrp1.deja.com...
> >
> > Did the explicit keyword get considered for use with cast operators?

> > This construct could have been used in place of
> > std::basic_string<>::c_str() for an example of why this could be
> > considered a good concept.

Maybe the fact that std::basic_string<> has c_str is an indication
that it was not considered a useful concept.

The usual arguement is that you can call it anything you like and it
will be explicit.  If you want explicit, don't call it operator X.
You can't change the name of a ctor which justifies it there.

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A54B1AD.48D5BBFF@sun.com>,
  Steve Clamage <stephen.clamage@sun.com> wrote:
> sirwillard@my-deja.com wrote:
> >
> > Just curious...
> >
> > Did the explicit keyword get considered for use with cast operators?
> > It would be nice to be able to delcare a cast operator but prevent
> > implicit casts using this operator.
>
> The history of "explicit" is a concatenation of implicit :-)
assumptions.
>
> The proposer of "explicit", and a few other people on the C++
committee,
> assumed the proposal applied to type conversion operators as well as
to
> constructors, but the proposal didn't mention operators.
>
> Most other people, since the proposal did not mention operators,
assumed
> it was intended to apply only to constructors.
>
> The subject of operators came up during some discussions, but it was
> pointed out that you never need "explicit" for operators.  If you
> don't want implicit conversions, you can write a named function
instead
> of an operator.  Example:
>
> class T {
> public:
>  operator int(); // allows implicit conversion to int
>  long to_long(); // for explicit conversion to long
> };
>
> (The named-function approach is not always as convenient, however.)
>
> Even though the wording as voted on and adopted did not mention
> operators, some people on the C++ committee still assumed that
> "explicit" could be used on operators.
>
> Only after the final approved standard was published were the
> implicit assumptions revealed explicitly. :-)

This would indicate that the intent, at least to some members minds,
was to include explicit cast operators.  If that's so, and since the
standard definatively excludes this, could this be considered for a
DR?  That seems to be stretching things a bit, especially since there
are some that think named casts are better here (I don't agree), but if
enough people think this idea appropriate and given the assumptions you
claim, maybe the stretch should be made?

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com
http://www.deja.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3a54d7e8.34289133@news.csrlink.net>,
  jpotter@falcon.lhup.edu (John Potter) wrote:
> On Thu,  4 Jan 2001 18:30:09 GMT, "David Abrahams"
> <abrahams@mediaone.net> wrote:
>
> > That's really a wonderful idea. I wish I'd thought of it.
>
> You're joking?  Try a power search on deja.  It comes up about every
> six months for many years.  This is the shortest time span since it
> was just discussed in December.

Sorry.  I tried to locate discussions on this topic before posting and
failed to find anything.  What seach criteria did you use?

> > <sirwillard@my-deja.com> wrote in message
> > news:93076q$rdl$1@nnrp1.deja.com...
> > >
> > > Did the explicit keyword get considered for use with cast
operators?
>
> > > This construct could have been used in place of
> > > std::basic_string<>::c_str() for an example of why this could be
> > > considered a good concept.
>
> Maybe the fact that std::basic_string<> has c_str is an indication
> that it was not considered a useful concept.

No, it's not an indication.  It could be considered an example of why
some think the idea not worth adding to the language, but that's not
the same as an indication that it was considered at all, whether
considered useful or otherwise.  Another post on this thread indicates
that the feelings were (understandably) mixed, but that thorough
discussion and evaluation was never made.

> The usual arguement is that you can call it anything you like and it
> will be explicit.  If you want explicit, don't call it operator X.
> You can't change the name of a ctor which justifies it there.

This ignores the completeness of the concepts.  I find the concepts to
be mirror images of each other (constructors allow casting TO and
conversion operators allow casting FROM), and so keeping them as
similar as possible would be a good thing.  Unless problems arise in
implementing this I see no compelling reason to exclude it from the
language and several compelling reasons to include it.  The fact that
you can use named conversions ala c_str does not change this in any way.

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com
http://www.deja.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <932md3$u0k$1@nnrp1.deja.com>, sirwillard@my-deja.com writes
>This would indicate that the intent, at least to some members minds,
>was to include explicit cast operators.  If that's so, and since the
>standard definatively excludes this, could this be considered for a
>DR?  That seems to be stretching things a bit, especially since there
>are some that think named casts are better here (I don't agree), but if
>enough people think this idea appropriate and given the assumptions you
>claim, maybe the stretch should be made?

Possibly as we are tending towards being more tolerant of pure
extensions (ones that cannot break existing code)


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <932imc$qee$1@nnrp1.deja.com>, sirwillard@my-deja.com writes
>*laughs*  I take it from that remark that it was never even considered
>by the Standards Committee?  Surprising, considering how obvious
>an "extension" to explicit constructors that it is.

It was considered, but as conversion operators are not held in high
regard and it was thought that using a converting function would meet
the needs we decided not to support explicit qualification of conversion
operators. Since then reasons have arisen to revisit the decision
(largely because it impacts on templates, where explicit conversion
operators could be useful)



Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow wrote:
>
> Possibly as we are tending towards being more tolerant of pure
> extensions (ones that cannot break existing code)
>

Perhaps some of us are, but others of us will still resist extensions in
the guise of defect reports.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

sirwillard@my-deja.com wrote:
>=20
> Just curious...
>=20
> Did the explicit keyword get considered for use with cast operators?

I discussed it a while ago here. The original message was "explicit
operator T()" from 5 Dec 2000. I got some answers but no real result.
Probably because I don't know how to continue (I mean who I can ask to
implement it :). It showed that it would also be extremly useful for
templates. Another idea was to add 'explicit' for function arguments,
which also sounds very promising to me. See the older discussion, if you
can't find it, just mail I as I have a copy of it.

Regards, Daniel

--
Daniel Frey               wir machen anleger

aixigo AG - financial research and education
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
phone: +49 (0)241 93 67 37 - 42    fax: - 99
daniel.frey@aixigo.de   http://www.aixigo.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A54CBFC.D1A97EE8@glue.ch>,
  Thomas Maeder <maeder@glue.ch> wrote:
> sirwillard@my-deja.com wrote:
> >
> > Did the explicit keyword get considered for use with cast operators?
>
> I don't know. But I know why I wouldn't like it to be used:
>
> The purpose of conversion operators is to allow *implicit*
conversions. If
> you want an explicit conversion, why not write a regular member
function:
>
> use_bar(f.as_bar());
>
> ?

What name do you use? You chose as_bar here, the standard chose c_str
for std::basic_string.  Both are explicit casts, and I'd much prefer to
always know that the name of the cast was static_cast<type>(obj).  The
results are the same, but the uniformity of the latter is a big benefit
in my mind.  Not to mention that this is the flip-side of explicit
constructors which allow explicit casts TO your type but not FROM your
type.  The completeness of this idiom should appear appealing to you,
though obviously opinions will differ.

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com
http://www.deja.com/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

sirwillard@my-deja.com wrote:
>
> This would indicate that the intent, at least to some members minds,
> was to include explicit cast operators.  If that's so, and since the
> standard definatively excludes this, could this be considered for a
> DR?  That seems to be stretching things a bit, especially since there
> are some that think named casts are better here (I don't agree), but if
> enough people think this idea appropriate and given the assumptions you
> claim, maybe the stretch should be made?
>

No. At this point it's clearly an extension.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

On Thu,  4 Jan 2001 20:45:26 GMT, sirwillard@my-deja.com wrote:

> I tried to locate discussions on this topic before posting and
> failed to find anything.  What seach criteria did you use?

Power Search:
Forum: comp.std.c++
Subject: explicit

The archives were not available, but the current list shows 6/99 and
12/99 threads.  When the archives come back, you should be able to
find threads all the way back to when explicit was introduced.

> > The usual arguement is that you can call it anything you like and it
> > will be explicit.  If you want explicit, don't call it operator X.
> > You can't change the name of a ctor which justifies it there.
>
> This ignores the completeness of the concepts.

Yep.  I happen to prefer s.c_str() to static_cast<char const*>(s), but
have no strong feelings on the subject.  Did you notice the comment on
that line in the header in the standard?  ;-)

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]