Will the ANSI standard C++ require at least a warning when automatic type
conversions are performed. I hope so (see related post in comp.lang.c++:
"C++ is a strongly typed language ???"). I would prefer that such
conversions are not allowed by default (need a flag to allow them), but if a
warning is all I can get, I will be (sort of) satisfied.

Cheers,
Don Petcher                                petcher@wuphys.wustl.edu
Department of Physics
Washington University
Saint Louis, Missouri

petcher@howdy.wustl.edu (Donald N. Petcher) writes:

>Will the ANSI standard C++ require at least a warning when automatic type
>conversions are performed. I hope so (see related post in comp.lang.c++:
>"C++ is a strongly typed language ???"). I would prefer that such
>conversions are not allowed by default (need a flag to allow them), but if a
>warning is all I can get, I will be (sort of) satisfied.

As Dag Br"uck pointed out, there are many occasions where automatic
conversion is exactly what you want.

C++ is "strongly typed" when compared to C, but part of its heritage
is automatic conversions among numerical types.  This would seem to
be necessary in view of the large number of built-in numerical types.
The "necessary" is debateable, but that's what we have in the language.

Automatic conversions are a source of bugs, however.  This is one
reason why the "operator<type>()" member functions are not as
generally useful as they first appear.  You can use explicitly-
named functions instead, such as "int X::to_int()" instead of
"X::operator int()", for example. Those won't ever be invoked implicitly.

Finally, I think it is safe to say that the Standard will not discuss
warnings as such.  There is no practical way to place a requirement
for warnings on processors.  C++ will probably have the same sort of
requirement as C.  A program in violation of certain kinds of language
rules must result in at least one diagnostic, form and content not
specified.  Such a violation is an error so far as the Standard is
concerned.  Precisely what the processor does with it is another subject.

A compiler is always free in C to issue any sort of warning it likes,
for any reason or for no reason.  I believe the same will be (and
should be) true in C++.  You can then demand that vendors supply
helpful warnings, and perhaps equally important, supply ways to
turn off warnings.
--

Steve Clamage, TauMetric Corp, steve@taumet.com

In article <1993Mar5.162621.9559@taumet.com> steve@taumet.com (Steve Clamage) writes:
>petcher@howdy.wustl.edu (Donald N. Petcher) writes:
>
>>Will the ANSI standard C++ require at least a warning when automatic type
>>conversions are performed. I hope so (see related post in comp.lang.c++:
>>"C++ is a strongly typed language ???"). I would prefer that such
>>conversions are not allowed by default (need a flag to allow them), but if a
>>warning is all I can get, I will be (sort of) satisfied.
>
>As Dag Br"uck pointed out, there are many occasions where automatic
>conversion is exactly what you want.

True. This does not preclude the possibility of the compiler warning of such
situations as potentially problematic (at least as an option) though.

>
>C++ is "strongly typed" when compared to C, but part of its heritage
>is automatic conversions among numerical types.  This would seem to
>be necessary in view of the large number of built-in numerical types.
>The "necessary" is debateable, but that's what we have in the language.
>

I can see the problem here. I think if I had my choice I would go for two
different types of constructors - those which can be invoked for automatic
conversion and those that cannot. After all, it is only the programmer who
knows that a conversion should be safe in *ALL* circumstances (even
so-called safe conversions are sometimes not - a fact I learned well from my
fortran days).

I suspect the idea of two types of constructors doesn't have a ghost of a
chance of making it into ansi discussions though. It is also inelegant from
another perspective.

>Automatic conversions are a source of bugs, however.  This is one
>reason why the "operator<type>()" member functions are not as
>generally useful as they first appear.  You can use explicitly-
>named functions instead, such as "int X::to_int()" instead of
>"X::operator int()", for example. Those won't ever be invoked implicitly.

The problem with this is one of uniformity. I would expect that the ideal
situation would have all type conversions with the same form: <type>(arg).
Though a case could be argued for the undesirability of allowing this when a
type is not really equivalent to another I suppose.

>
>Finally, I think it is safe to say that the Standard will not discuss
>warnings as such.  There is no practical way to place a requirement
>for warnings on processors.  C++ will probably have the same sort of
>requirement as C.  A program in violation of certain kinds of language
>rules must result in at least one diagnostic, form and content not
>specified.  Such a violation is an error so far as the Standard is
>concerned.  Precisely what the processor does with it is another subject.
>

A pity.

>A compiler is always free in C to issue any sort of warning it likes,
>for any reason or for no reason.  I believe the same will be (and
>should be) true in C++.  You can then demand that vendors supply
>helpful warnings, and perhaps equally important, supply ways to
>turn off warnings.
>--

The compiler in question here is gnu g++. I would LOVE to see the ability to
turn on warnings for any type conversion that is not explicitly declared. I
am not really advocating that automatic conversions never be allowed as that
can require a lot of extra work in overloading, but I do want some help in
catching the bugs that are caused by this.  It is only reasonable.

>
>Steve Clamage, TauMetric Corp, steve@taumet.com

Don Petcher, petcher@wuphys.wustl.edu
Physics Department, Washington University, St. Louis