In article <t7wvka2yxp.fsf@calumny.jyacc.com>, Hyman Rosen
<hymie@prolifics.com> writes
>Kevlin Henney <kevlin@curbralan.com> writes:
>> This would be fine if generic programming were not a consideration...
>> but it is, so it is not "unnecessary" :-(
>
>How does generic programming require a conversion operator over an
>explict function name? You know you can do the following, right?
>
>struct Foo
>{
>       template <typename T> T as() { /* ... */ }
>};
>
>int main()
>{
>       Foo joe;
>       return joe.as<int>();
>}

Of course, but what problem does this solve? All you have done is
provide a named conversion function for a user defined type. Now, do it
for a built-in and I will be impressed! The problem is that there is no
way of providing a uniform model for providing conversions in user
defined types: you can have implicit conversions through ctors, explicit
conversions through ctors, implicit conversions through UDCs, and --
errm -- named member functions.

Consider:

        template<typename T, typename U>
        T f(U u)
        {
                return u;
        }

This will only work where an implicit conversion is possible from U to
T. However, if this does not work for all the cases I want it to:

        template<typename T, typename U>
        T f(U u)
        {
                return T(u);
        }

This will now work for all the cases that previously worked (converting
ctors and UDCs, as well as the relevant built-ins) plus explicit ones
(explicit ctors and relevant built-in conversions). So what if I wish to
define a class that works with this function as U? I must provide a UDC.
But what if I wish to avoid all the ambiguity and subtlety that such
implicit conversions offer? I have no choice but to specialise f to use
a named member function. Not very generic :-(
____________________________________________________________

  Kevlin Henney                   phone:  +44 117 942 2990
  Curbralan Ltd                   mobile: +44 7801 073 508
  kevlin@curbralan.com            fax:    +44 870 052 2289
____________________________________________________________

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <WWEwJaAgJlN5EwHP@robinton.demon.co.uk>, Francis Glassborow
<francis@robinton.demon.co.uk> writes
>In article <Ndta7KBvhXN5EwlK@two-sdg.demon.co.uk>, Kevlin Henney
><kevlin@curbralan.com> writes
>>>We considered this but decided it was unnecessary because you do not
>>>need to write a conversion operator if it is to be explicit, and
>>>ordinary member function will do.
>>
>>This would be fine if generic programming were not a consideration...
>>but it is, so it is not "unnecessary" :-(
>
>I did not actually claim we were right, I just gave the reason we made
>that decision.  Now you are free to write a proposal for change in the
>next version of the C++ Standard:)

This is one of those topics that I suspect if I don't write a proposal,
someone else will :-)
____________________________________________________________

  Kevlin Henney                   phone:  +44 117 942 2990
  Curbralan Ltd                   mobile: +44 7801 073 508
  kevlin@curbralan.com            fax:    +44 870 052 2289
____________________________________________________________

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Am 02.06.00, 05:45:31, schrieb Kevlin Henney <kevlin@curbralan.com> zum=20
Thema Re: "explicit" for cast operators:


>         template<typename T, typename U>
>         T f(U u)
>         {
>                 return T(u);
>         }

> This will now work for all the cases that previously worked (converting
> ctors and UDCs, as well as the relevant built-ins) plus explicit ones
> (explicit ctors and relevant built-in conversions). So what if I wish t=
o
> define a class that works with this function as U? I must provide a UDC.
> But what if I wish to avoid all the ambiguity and subtlety that such
> implicit conversions offer? I have no choice but to specialise f to use
> a named member function. Not very generic :-(

And if you are writing a template, you can't even do that. Instead you=20
must provide an overload, which introduces yet another inconsistency.=20

I miss explicit conversion functions too. And I miss FTPS as well ;-0.

-- J=F6rg


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <Jzm7AcACwpN5EwnS@two-sdg.demon.co.uk>,
  Kevlin Henney <kevlin@curbralan.com> wrote:

[...]

> This will now work for all the cases that previously worked
(converting
> ctors and UDCs, as well as the relevant built-ins) plus explicit ones
> (explicit ctors and relevant built-in conversions). So what if I wish
to
> define a class that works with this function as U? I must provide a
UDC.
> But what if I wish to avoid all the ambiguity and subtlety that such
> implicit conversions offer? I have no choice but to specialise f to
use
> a named member function. Not very generic :-(

Hi,

I ran into this problem when I needed to pass a wrapper for a numeric
POD through templatized processing designed for the underlying numeric
type.  Obviously a converting member function wouldn't work since the
POD's wouldn't have it (the templates still had to work for plain
types).  I was able to get it all to work the way I wanted using the
following:

template<class Out, class In>
Out explicit_cast(In& in) {
    return Out(in);
}

struct IntObj {
    int i;
    IntObj(int arg):i(arg){}
private:
     friend int explicit_cast<int,IntObj>(IntObj&);
     operator int(){return i;}
};

void setIt(int i){};

int main()
{
    IntObj I(1);
    double x = 2.0;
    setIt(I);        // error
    int v = I;       // error
    int val = explicit_cast<int>(I); // ok
    int q   = explicit_cast<int>(x); // ok
    setIt(explicit_cast<int>(I));    // ok
}


The private UDC can produce some overload resolution hitches.


--
/\----|---------|
||  __o_________o_____
||  | Ye Olde Coder  |
||  VVVVVVVVVVVVVVVVVV


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8gvu87$2mg$1@pollux.ip-plus.net>, Roland Sch=E4uble
<schaublr@ch.sibt.com> writes
>The keyword explicit is only allowed for constructors.
>I would like to have it for cast operators too. Look at the following
>example of the class

We considered this but decided it was unnecessary because you do not
need to write a conversion operator if it is to be explicit, and
ordinary member function will do.


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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Roland Sch   uble (schaublr@ch.sibt.com) wrote:
) The keyword explicit is only allowed for constructors.
) I would like to have it for cast operators too. Look at the following
) example of the class
) EmptyValue:
)
) class EmptyValue
) {
) public:
)   EmptyValue()
)     : valid_(false), value_(0.0) { }
)   EmptyValue(double value)
)     : valid_(true), value_(value) { }
)   bool isValid()
)     { return valid_; }
)   operator double()
)     { assert(valid_); return value_; }
) private:
)   bool valid_;
)   double value_;
) };


There is no need for that. Just use a normal function for it an you have
your explicit conversion:

class EmptyValue
{
public:
  EmptyValue()
    : valid_(false), value_(0.0) { }
  EmptyValue(double value)
    : valid_(true), value_(value) { }
  bool isValid()
    { return valid_; }

  double Double()
    { assert(valid_); return value_; }

private:
  bool valid_;
  double value_;
};


Now there is no implicit conversion any more and you have to call:

void my_caller(EmptyValue v)
{
  :
 my_function(v) // <- implicit conversion does not exist
 my_function(v.Double()) // <- explicit conversion from EmptyValue to double
allowed
  :
}


For constructors there is the difference, that you do not have this option
of making it a normal function, since in this case the object needs to be
constructed. But in your case you can.

So there is no need to change the standard.

- Matthias Meixner

--
Matthias Meixner                   meixner@rbg.informatik.tu-darmstadt.de
Technische Universit   t Darmstadt
Rechnerbetriebsgruppe                          Telefon (+49) 6151 16 6670
Wilhelminenstra   e 7, D-64283 Darmstadt, Germany    Fax (+49) 6151 16 4701


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Roland Sch   uble" <schaublr@ch.sibt.com> wrote in message
news:8gvu87$2mg$1@pollux.ip-plus.net...
> The keyword explicit is only allowed for constructors.
> I would like to have it for cast operators too.

The feature might be handy, but there is an easy work around.  It is a
serious pain to rename a constructor, but it is easy to rename a conversion
operator (std::basic_string::c_str).



---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <b2SzhzA4OFN5EwkI@robinton.demon.co.uk>, Francis Glassborow
<francis@robinton.demon.co.uk> writes
>In article <8gvu87$2mg$1@pollux.ip-plus.net>, Roland Sch=E4uble
><schaublr@ch.sibt.com> writes
>>The keyword explicit is only allowed for constructors.
>>I would like to have it for cast operators too. Look at the following
>>example of the class
>
>We considered this but decided it was unnecessary because you do not
>need to write a conversion operator if it is to be explicit, and
>ordinary member function will do.

This would be fine if generic programming were not a consideration...
but it is, so it is not "unnecessary" :-(
____________________________________________________________

  Kevlin Henney                   phone:  +44 117 942 2990
  Curbralan Ltd                   mobile: +44 7801 073 508
  kevlin@curbralan.com            fax:    +44 870 052 2289
____________________________________________________________

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <Ndta7KBvhXN5EwlK@two-sdg.demon.co.uk>, Kevlin Henney
<kevlin@curbralan.com> writes
>>We considered this but decided it was unnecessary because you do not
>>need to write a conversion operator if it is to be explicit, and
>>ordinary member function will do.
>
>This would be fine if generic programming were not a consideration...
>but it is, so it is not "unnecessary" :-(

I did not actually claim we were right, I just gave the reason we made
that decision.  Now you are free to write a proposal for change in the
next version of the C++ Standard:)


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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Kevlin Henney <kevlin@curbralan.com> writes:
> This would be fine if generic programming were not a consideration...
> but it is, so it is not "unnecessary" :-(

How does generic programming require a conversion operator over an
explict function name? You know you can do the following, right?

struct Foo
{
 template <typename T> T as() { /* ... */ }
};

int main()
{
 Foo joe;
 return joe.as<int>();
}

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8gvu87$2mg$1@pollux.ip-plus.net>, Roland Sch=E4uble
<schaublr@ch.sibt.com> writes
>The keyword explicit is only allowed for constructors.
>I would like to have it for cast operators too.=20
[...]
>Any Comments?

Yup, I strongly agree and would like to see it in the next standard. I
understand that it was proposed (or at the very least discussed) last
time round, and have vague recollections of why it was not adopted.
____________________________________________________________

  Kevlin Henney                   phone:  +44 117 942 2990
  Curbralan Ltd                   mobile: +44 7801 073 508
  kevlin@curbralan.com            fax:    +44 870 052 2289
____________________________________________________________

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

The keyword explicit is only allowed for constructors.
I would like to have it for cast operators too. Look at the following
example of the class
EmptyValue:

class EmptyValue
{
public:
  EmptyValue()
    : valid_(false), value_(0.0) { }
  EmptyValue(double value)
    : valid_(true), value_(value) { }
  bool isValid()
    { return valid_; }
  operator double()
    { assert(valid_); return value_; }
private:
  bool valid_;
  double value_;
};

Objects of this class represent double values, which can be empty (invalid).
Conversion to
double is not possible, if the value is empty. This is catched by an
assertion. So, the
following function-call may raise an assertion since the compiler inserts a
implicit cast in
calling the function my_function:

extern void my_function(double d);

void my_caller(EmptyValue v)
{
  :
 my_function(v) // <- implicit conversion from EmptyValue to double
  :
}

I would like to see the keyword explicit also valid for cast operators like
this:

class EmptyValue
{
  :
  explicit operator double()
    { assert(valid_); return value_; }
  :
};

This should prevent the compiler inserting an implicit cast operator:

void my_caller(EmptyValue v)
{
  :
 my_function(v) // <- implicit conversion emits a compiler error-message
 my_function((double)v) // <- explicit conversion from EmptyValue to double
allowed
  :
}

If the programmer is sure, the value v should always be defined, when
entering the function
"my_caller", he can use the explicit conversion. The constraint, to use the
explicit cast-operator
makes the programmer aware, using a possibly dangerous operation.

It is obvious, that one could also use a member-function doing the explicit
conversion like this:
class EmptyValue
{
  :
  double DangerousConversionToDouble()
    { assert(valid_); return value_; }
  :
};

but this seems somewhat strange to me, because it is really just a
conversion, and
for conversions, the cast-operator should be the way to do it.

Any Comments?


with kind regards


Roland Sch   uble
-----------------------------------
Siemens Building Technologies AG
Roland Schaeuble, F-BM-S1
Laubisruetistrasse 50
CH-8712 Staefa
Switzerland

Phone: +41  1 928 65 06
Fax: +41  1 928 67 11
Email: schaublr@ch.sibt.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]