Gene Bushuyev wrote:
>=20
> This opens a floodgate of problems. How do you decide what conversions
> "explicit" should prevent? How about promotions? How about identity
> conversions? Will derived-to-base class conversion be allowed? If you s=
ay
> any conversion is disallowed with "explicit" then it's usefulness is ne=
xt to
> nil.

IMHO 'explicit' for parameters should work like this:

  void func( explicit T arg ) { // ... }
  void funcB( explicit const T& arg ) { // ... }

should be equivilent to

  void func( T& arg_ ) { T arg( arg_ ); // ... }
  void funcB( T& arg_ ) { const T& arg( arg_ ); // ... }

where 'arg_' should be invisible inside the functions bodies '// ...'.
This should yield no surprises and shows that the compiler doesn't need
any new magic for 'explicit' here. It just hides a temporary (or creates
an unnamed temporary depending on your point of view) that can be
optimized away.

Regards, Daniel

----------------------------------------------
 aixigo AG - Financial Research and Education
 Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
 Tel: +49 (0)241 936737-42           Fax: -99
 Daniel.Frey@aixigo.de   http://www.aixigo.de
-------------------- "wir machen Anleger" ----

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

"Christopher Eltschka" <celtschk@physik.tu-muenchen.de> wrote in message
news:3A2F5BF8.B8CFDBED@physik.tu-muenchen.de...
[snip]
> In that case, I'd prefer "explicit" at the parameters, since this would
> - give more fine-grained control (say, for an asymetric operand, you
>   want to disallow automatic conversion only for one operand)
> - allow the use also in ordinary functions
>
> In short: It would be far more flexible.
>
> Example:
>
> void foo(explicit C const& a);
>   // I want a C, not something converted to C

This opens a floodgate of problems. How do you decide what conversions
"explicit" should prevent? How about promotions? How about identity
conversions? Will derived-to-base class conversion be allowed? If you say
any conversion is disallowed with "explicit" then it's usefulness is next to
nil.

Gene Bushuyev

--
--------------------
"I did not invent Internet"(me)

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

"Brian McNamara!" wrote:
...
> >There is quite a history available on deja for this.  The basic result.
> >   explicit operator int () const;
> >is spelled
> >   int as_int () const;
> >or whatever other naming convention you may like.
>
> ...thus making it impossible to write template code that does explicit
> conversions.

template<typename T> T convert_to() const { /* fill in details */ }

Of course, this can only be invoked with explicit template arguments.
The syntax would look much like that of const_cast<>().

---
[ 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 <t2qout2pnv435b@corp.supernews.com>, Gene Bushuyev
<gbush@deja.com> writes
>If you don't want your user-defined operator to be called in implicit
>conversions (as you call it accidentally) then probably you don't need
>operator at all. Create a function for conversion purposes and call it
>explicitly.

That works fine for ordinary classes but not necessarily for template
classes.


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

Daniel Frey wrote:

[...]

> For other operators, 'explicit' could have a different meaning. If I
> declare 'operator<' as explicit, this could mean that it shouldn't
> convert any of the parameters, only promotions are OK. Before you start
> complaining about the different meanings of 'explicit': Think of 'const'
> and all its uses...

In that case, I'd prefer "explicit" at the parameters, since this would
- give more fine-grained control (say, for an asymetric operand, you
  want to disallow automatic conversion only for one operand)
- allow the use also in ordinary functions

In short: It would be far more flexible.

Example:

void foo(explicit C const& a);
  // I want a C, not something converted to C

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

Nicola Musatti wrote:
> convention. Brian and Daniel won me over to their side, now is there an=
y
> technical reason not to allow conversion operators to be declared
> explicit so that some form of explicit cast would be required for the
> conversion to be performed?

The important criterions are:

a) No new keywords are introduced
b) No existing (and legal) code will be broken
c) The new use of 'explicit' should be optional, obvious and
non-ambiguous to 99.9% of the people
d) The new use of 'explicit' makes using the language safer, faster
and/or easier (or we won't need it).
e) The new use of 'explicit' should be 'easy' or 'straigth forward' to
implement for the compiler (no 'magic' should be required)

I think no one doubts a) and b), so the remaining questions are about
c), d) and e). c) and d) can also be said like this: The new use of
'explicit' should add something (safety, readablility, ...) to the
language, but it shouldn't substract something, e.g. it doesn't force
you to use it. These criterions should be considered for every possible
use of 'explicit' seperatly:

1) Using 'explicit' for cast-operators
2) Using 'explicit' for parameters
3) Using 'explicit' for other operators

To 1):

   explicit T::operator U();

should mean that this 'conversion' from type T to type U will not be
used automatically when an U is expected and a T is supplied. This was
usually achived by writing a function

   U T::as_U();

but the naming is not a standard, in fact every library / company has
it's own style. Some even prefer templates like "T::as<U>" or
"T::convertTo<U>" (like my company). Also, the return type is not
nessessarily clear. The new use of explicit will help to write templates
using these conversion by raising a standard for converions. It will
also help people not to write 'T::operator U()' (without explicit) and
therefore run into trouble later (or makeing the use of their code
harder for other people).

To 2):

   void someFunction( explicit double d );

should mean that someFunction( 2 ) is not allowed, only 'promotions' are
OK (for 'explicit const T& arg' it's OK to pass a T as instead of an
const T&). Again, this should help to make functions safer in some cases
and I think it will be easier to specialize templates or overload
functions with this.

To 3):

for member-operators is may be nessessary to allow 'explicit' for the
operator itself (like const), because 2) can not be supplied another way
to the object (which is an "argument" of this function). I hope you get
the idea of what I mean. Just have a look at this:

class A
{
public:
_   friend bool operator>=3D( int i, explicit const A& a );

    bool operator>=3D( int i ) const explicit; // <- Use 'explicit' here
for this third case!
}_;



Now what does the group think? Is this worth being considered? Have I
left out any important criterion f) or is there another possible use for
'explicit'? Are c) - e) true for 1) - 3)?  (Note: I'm not *sure* about
this, but I think (feel?) that it's mostly true. That's why I ask, so
feel free to argue against it :)


Best regards, Daniel

--
Daniel Frey

aixigo AG - Financial Research and Education
Schlo=DF-Rahe-Str. 15, 52072 Aachen, Germany
Tel: +49 (0)241 936737-00, Fax: +49 (0)241 936737-99
EMail: D.Frey@aixigo.de

"Operator.. give me the number for 911" (Homer Simpson)

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

Daniel Frey wrote:
...
> The important criterions are:

That's "criteria", please.

> ... obvious and
> non-ambiguous to 99.9% of the people ...

That criterion alone prohibits every possible solution (to virtually any
problem, not just this one). It would still prohibit every possible
solution if you dropped it to 90%. 80% might be feasible, but don't
count on it.

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

"Daniel Frey" <d.frey@aixigo.de> wrote...
> Hi,
>
> sorry if this was suggested / discussed before, but would it make
sense
> to allow declaring a cast-operator as 'explicit'? I guess the normal
way
> would be to declare an explicit constructor in the other class but
when
> you don't have access to it (e.g. in a library), it would help to add
> 'explicit' to the operator. Maybe it also makes sense to think of
other
> operators to be declared 'explicit', to make sure they are not called
> accidentially... what do you think?

I think that the operator <othertype>() was made so that there WERE
an implicit conversion between the class and the 'othertype'.  Making
it optionally explicit defeats the purpose.

Victor
--
Please remove capital A's from my address when replying by mail



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

If you don't want your user-defined operator to be called in implicit
conversions (as you call it accidentally) then probably you don't need
operator at all. Create a function for conversion purposes and call it
explicitly.

-------------------------
Gene Bushuyev                         Sr. R&D Eng.
Organ transplants are best left to the professionals (Bart Simpson)

"Daniel Frey" <d.frey@aixigo.de> wrote in message
news:3A2D10EE.35544D0A@aixigo.de...
Hi,

sorry if this was suggested / discussed before, but would it make sense
to allow declaring a cast-operator as 'explicit'? I guess the normal way
would be to declare an explicit constructor in the other class but when
you don't have access to it (e.g. in a library), it would help to add
'explicit' to the operator. Maybe it also makes sense to think of other
operators to be declared 'explicit', to make sure they are not called
accidentially... what do you think?

Regards, Daniel

--
Daniel Frey

aixigo AG - Financial Research and Education
Schlo   -Rahe-Str. 15, 52072 Aachen, Germany
Tel: +49 (0)241 936737-00, Fax: +49 (0)241 936737-99
EMail: D.Frey@aixigo.de

"Operator.. give me the number for 911" (Homer Simpson)

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

On Tue,  5 Dec 2000 19:13:54 GMT, Daniel Frey <d.frey@aixigo.de> wrote:

> Hi,
>
> sorry if this was suggested / discussed before, but would it make sense
> to allow declaring a cast-operator as 'explicit'?

There is quite a history available on deja for this.  The basic result.

   explicit operator int () const;

is spelled

   int as_int () const;

or whatever other naming convention you may like.

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

Gene Bushuyev wrote:
>=20
> If you don't want your user-defined operator to be called in implicit
> conversions (as you call it accidentally) then probably you don't need
> operator at all. Create a function for conversion purposes and call it
> explicitly.

This usually ends up in function called "asString", "toString",
"convertToString", "convert2String", "toStr" and whatever comes to
peoples mind. The return type of these functions is not always that
clear (string, const char*, RWCString, ...) as you might think in the
first moment.  Allowing explicit cast-operators would create a kind of
"standard" for this kind of functions and the name no longer depends on
the colleague who implemented the function.

You could also say that explicit ctors can be written as static member
functions ("createStringFromDouble()", ...) calling private ctors, so I
don't need explicit at all. I think that if we already have such a nice
keyword like 'explicit', we should try to use it where it can help to
make the code safer and easier.

For other operators, 'explicit' could have a different meaning. If I
declare 'operator<' as explicit, this could mean that it shouldn't
convert any of the parameters, only promotions are OK. Before you start
complaining about the different meanings of 'explicit': Think of 'const'
and all its uses...

Regards, Daniel

--
Daniel Frey

aixigo AG - Financial Research and Education
Schlo=DF-Rahe-Str. 15, 52072 Aachen, Germany
Tel: +49 (0)241 936737-00, Fax: +49 (0)241 936737-99
EMail: D.Frey@aixigo.de

"Operator.. give me the number for 911" (Homer Simpson)

---
[ 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) once said:
>On Tue,  5 Dec 2000 19:13:54 GMT, Daniel Frey <d.frey@aixigo.de> wrote:
>> sorry if this was suggested / discussed before, but would it make sense
>> to allow declaring a cast-operator as 'explicit'?

>There is quite a history available on deja for this.  The basic result.
>   explicit operator int () const;
>is spelled
>   int as_int () const;
>or whatever other naming convention you may like.

...thus making it impossible to write template code that does explicit
conversions.

For genericity's sake, cast-operators should be able to be "explicit",
just like constructors.

--
Brian McNamara

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

"Brian McNamara!" wrote:

>
> >There is quite a history available on deja for this.  The basic result.
> >   explicit operator int () const;
> >is spelled
> >   int as_int () const;
> >or whatever other naming convention you may like.
>
> ...thus making it impossible to write template code that does explicit
> conversions.
>

Not impossible at all.

You don't need the typename in template.

 T convert() const;

works just fine and is less cumbersome that C++ style cast notation on
the callers part.

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

Ron Natalie wrote:
>=20
> "Brian McNamara!" wrote:
>=20
> >
> > >There is quite a history available on deja for this.  The basic resu=
lt.
> > >   explicit operator int () const;
> > >is spelled
> > >   int as_int () const;
> > >or whatever other naming convention you may like.
> >
> > ...thus making it impossible to write template code that does explici=
t
> > conversions.
>=20
> Not impossible at all.
>=20
> You don't need the typename in template.
>=20
>         T convert() const;
>=20
> works just fine and is less cumbersome that C++ style cast notation on
> the callers part.

You just found two additional names for such a function I didn't thought
of when replying to Gene's posting. Also, your last function has another
problem: What if I need two of them? You can't overload by return type
and partial specialization or a helper class if far more complex and
results in more errors and problems than a simple 'explicit' before a
cast-operator. Brian's point is also very good: Only a "standard" for
these functions will allow you to write good template-code. As long as
every library, company, ... has it's own style we won't be able to write
libraries that benefit from that.

Regards, Daniel

--
Daniel Frey

aixigo AG - Financial Research and Education
Schlo=DF-Rahe-Str. 15, 52072 Aachen, Germany
Tel: +49 (0)241 936737-00, Fax: +49 (0)241 936737-99
EMail: D.Frey@aixigo.de

"Operator.. give me the number for 911" (Homer Simpson)

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

Ron Natalie wrote:
[...]
> You don't need the typename in template.
>
>         T convert() const;
>
> works just fine and is less cumbersome that C++ style cast notation on
> the callers part.

But this requires that all the libraries you may ever use adhere to this
convention. Brian and Daniel won me over to their side, now is there any
technical reason not to allow conversion operators to be declared
explicit so that some form of explicit cast would be required for the
conversion to be performed?

Best regards,
Nicola Musatti

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

Hi,

sorry if this was suggested / discussed before, but would it make sense
to allow declaring a cast-operator as 'explicit'? I guess the normal way
would be to declare an explicit constructor in the other class but when
you don't have access to it (e.g. in a library), it would help to add
'explicit' to the operator. Maybe it also makes sense to think of other
operators to be declared 'explicit', to make sure they are not called
accidentially... what do you think?

Regards, Daniel

--
Daniel Frey

aixigo AG - Financial Research and Education
Schlo=DF-Rahe-Str. 15, 52072 Aachen, Germany
Tel: +49 (0)241 936737-00, Fax: +49 (0)241 936737-99
EMail: D.Frey@aixigo.de

"Operator.. give me the number for 911" (Homer Simpson)

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