"James Kuyper" <kuyper@wizard.net> wrote in message news:3A5A54C9.D09FB6D5@wizard.net...
> Anders Munch wrote:
> >
> > What is the rationale behind having static_cast invoke constructors
> > even if marked "explicit"?
>
> What "explicit" means is that the constructor should not be used unless
> it is explicitly  invoked. static_cast IS an explicit invocation of the
> constructor.

Well, linguistically it can go both ways: on one hand the programmer
is explicitly asking for a conversion to take place, on the other hand
the programmer is not explicitly stating the name of the operation
which is to do the conversion.  I'd say t = T(v) is a more explicit
way of calling the T constructor than is t = static_cast<T>(v), which
again is more explicit than T t; t = v.

So it comes down to which behaviour is more useful.  I'm having a hard
time seeing how invoking an "explicit" constructor with static_cast
can be useful.  If you know the constructor will be called anyway, you
could invoke it directly using actual constructor syntax T(v).  If you
don't know that the constructor will be called, then you don't have
enough information to be able to use static_cast safely.

- Anders

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

On Wed, 10 Jan 2001 00:11:01 GMT, "Anders Munch" <andersjm@post.tele.dk>
wrote:

> So it comes down to which behaviour is more useful.  I'm having a hard
> time seeing how invoking an "explicit" constructor with static_cast
> can be useful.  If you know the constructor will be called anyway, you
> could invoke it directly using actual constructor syntax T(v).

No.  That is a function style cast which will become static_cast which
may call a constructor.  There is no explicit constructor call with one
arguement because of the ambiguity.

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

Anders Munch wrote:
>
> "James Kuyper" <kuyper@wizard.net> wrote in message news:3A5A54C9.D09FB6D5@wizard.net...
> > Anders Munch wrote:
> > >
> > > What is the rationale behind having static_cast invoke constructors
> > > even if marked "explicit"?
> >
> > What "explicit" means is that the constructor should not be used unless
> > it is explicitly  invoked. static_cast IS an explicit invocation of the
> > constructor.
>
> Well, linguistically it can go both ways: on one hand the programmer
> is explicitly asking for a conversion to take place, on the other hand
> the programmer is not explicitly stating the name of the operation
> which is to do the conversion.  I'd say t = T(v) is a more explicit
> way of calling the T constructor than is t = static_cast<T>(v),

"Linguistically" is irrelevant. The standard is a technical document
that is laden with jargon whose meaning is defined by the document,
independent of any more general definition. "explicit" is a keyword;
keywords are the ultimate in jargon. The standard is very clear on this
- section 5.4p2 says "An explicit type conversion can be expressed using
functional notation (5.2.3), a type conversion operator (dynamic_cast,
static_cast, reinterpret_cast, const_cast) or the _cast_ notation."

The basic reason for this is that constructors are functions with no
names. You might think that a constructor for an object of type "T" is a
function with the name "T", but the standard has been very carefully
written to make that not the case. "T" is the type name, and only the
type name; constructors are defined and invoked using special grammar
rules that allow a type name to occur in contexts that ordinarily
require a function name. Therefore, there's no way to invoke
constructors directly. All that we have implicit invocation, and casts.
It is the fact that cast expressions use the type name which makes the
constructor invocation explicit.

> ... which
> again is more explicit than T t; t = v.

That is indeed an implicit construction. The assignment expression
contains no reference to the type name, yet ends up converting 'v' to
that type - that's what makes it implicit.

> So it comes down to which behaviour is more useful.  I'm having a hard
> time seeing how invoking an "explicit" constructor with static_cast
> can be useful.  If you know the constructor will be called anyway, you
> could invoke it directly using actual constructor syntax T(v). ...

I think you're misinterpreting what you call "constructor syntax". It
doesn't guarantee invocation of the constructor. "T(v)" is what the
standard calls "Explicit type conversion (functional notation)", and
according to  5.2.3p1, "... If the expression list is a single
expression, the type conversion expression is equivalent ... to the
corresponding cast expression (5.4). ...". Whether the cast is done
using functional notation or C-style cast notation is irrelevant. In
both cases, the conversion can be done either by a constructor or by a
conversion operator, and the rules used to decide which to use are the
same with either notation. Use of the constructor is forced only when
you use functional notation with multiple arguments.

> ...  If you
> don't know that the constructor will be called, then you don't have
> enough information to be able to use static_cast safely.

If you don't have enough information to use static_cast<> safely, you
certainly don't have enough information to use the functional notation
safely. The functional notation (when used with only one argument) is
equivalent to the C-style cast, and can therefore implicitly invoke
static_cast<>! It will invoke any one of the named casts needed to
perform the conversion (except dynamic_cast<>), which means it has every
danger associated with any of those named casts. The C-style cast will
even perform three types of casts that can't be performed using any of
the the named casts (see 5.4p7), which makes it even more dangerous.

---
[ 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 <93fv74$kqj$1@news.inet.tele.dk>, Anders Munch
<andersjm@post.tele.dk> writes
>Well, linguistically it can go both ways: on one hand the programmer
>is explicitly asking for a conversion to take place, on the other hand
>the programmer is not explicitly stating the name of the operation
>which is to do the conversion.  I'd say t = T(v) is a more explicit
>way of calling the T constructor than is t = static_cast<T>(v), which
>again is more explicit than T t; t = v.
>
>So it comes down to which behaviour is more useful.  I'm having a hard
>time seeing how invoking an "explicit" constructor with static_cast
>can be useful.  If you know the constructor will be called anyway, you
>could invoke it directly using actual constructor syntax T(v).  If you
>don't know that the constructor will be called, then you don't have
>enough information to be able to use static_cast safely.

But the use of static_cast has advantages in both visibility and
documenting intent and is certainly considered 'explicit' enough within
the terms of the 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

What is the rationale behind having static_cast invoke constructors
even if marked "explicit"?

I thought "explicit" was intended to say that a constructor does not
make sense as a conversion. But static_cast (or C style cast) is a
conversion that will use such a constructor anyway.

This makes static_cast extremely dangerous.  In particular, this makes
it entirely unsound to use static_cast to convert values to any type
that is not well-known, such as a template parameter type.

The subject line goes to show just how much damage an unwanted
"conversion" can do.

Does anyone have an example to show how this behaviour can be useful?

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

Anders Munch wrote:
>
> What is the rationale behind having static_cast invoke constructors
> even if marked "explicit"?
>
> I thought "explicit" was intended to say that a constructor does not
> make sense as a conversion. But static_cast (or C style cast) is a
> conversion that will use such a constructor anyway.

What "explicit" means is that the constructor should not be used unless
it is explicitly  invoked. static_cast IS an explicit invocation of the
constructor.

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