Topic: Removing troublesom implicit conversions
Author: daryl.vandenbrink@maptek.com.au
Date: Wed, 24 Sep 2014 18:35:00 -0700 (PDT)
Raw View
------=_Part_10207_1561393124.1411608900596
Content-Type: text/plain; charset=UTF-8
With refactoring work I have been doing over the past few months, I have
come to the conclusion that the following implicit conversions are evil and
shouldn't be allowed:
- from numeric types to bool
- from pointer types to bool
- from "false" and "0" compile-time constant expressions to null
pointers (I believe the particularly strange conversion of "false" to a
null pointer is being fixed in an upcoming standard)
These conversions cause many bugs and refactoring pain with incorrect
overloads getting called, etc. I can't think of one good reason why these
conversions should be implicit, except for compatibility.
PLEASE consider deprecating these conversions in an upcoming revision of
the C++ standard.
(And if compatibility with C is quoted as a reason for not doing so - then
C should also deprecate these conversions. C should also adopt C++'s
nullptr.)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_10207_1561393124.1411608900596
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">With refactoring work I have been doing over the past few =
months, I have come to the conclusion that the following implicit conversio=
ns are evil and shouldn't be allowed:<br><ul><li>from numeric types to bool=
</li><li>from pointer types to bool</li><li>from "false" and "0" compile-ti=
me constant expressions to null pointers (I believe the particularly strang=
e conversion of "false" to a null pointer is being fixed in an upcoming sta=
ndard)</li></ul><p>These conversions cause many bugs and refactoring pain w=
ith incorrect overloads getting called, etc. I can't think of one good reas=
on why these conversions should be implicit, except for compatibility.</p><=
p>PLEASE consider deprecating these conversions in an upcoming revision of =
the C++ standard.</p><p>(And if compatibility with C is quoted as a reason =
for not doing so - then C should also deprecate these conversions. C should=
also adopt C++'s nullptr.)<br></p></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_10207_1561393124.1411608900596--
.
Author: Pablo Oliva <pabloliva87@gmail.com>
Date: Wed, 24 Sep 2014 22:40:36 -0300
Raw View
--089e013d1a44165e670503d9e32b
Content-Type: text/plain; charset=UTF-8
Why wouldn't you ask your compiler manufacturer for a flag or an option to
avoid implicit conversions, instead of modifying the whole standard?
There are many lines of code that rely on these conversions and what seems
to be your goal (i.e., ease of debugging) can be achieved with just a
compiler option.
Or can you elaborate on the notion of conversion evilness?
2014-09-24 22:35 GMT-03:00 <daryl.vandenbrink@maptek.com.au>:
> With refactoring work I have been doing over the past few months, I have
> come to the conclusion that the following implicit conversions are evil and
> shouldn't be allowed:
>
> - from numeric types to bool
> - from pointer types to bool
> - from "false" and "0" compile-time constant expressions to null
> pointers (I believe the particularly strange conversion of "false" to a
> null pointer is being fixed in an upcoming standard)
>
> These conversions cause many bugs and refactoring pain with incorrect
> overloads getting called, etc. I can't think of one good reason why these
> conversions should be implicit, except for compatibility.
>
> PLEASE consider deprecating these conversions in an upcoming revision of
> the C++ standard.
>
> (And if compatibility with C is quoted as a reason for not doing so - then
> C should also deprecate these conversions. C should also adopt C++'s
> nullptr.)
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e013d1a44165e670503d9e32b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Why wouldn't you ask your compiler manufacturer for a =
flag or an option to avoid implicit conversions, instead of modifying the w=
hole standard?<div><br></div><div>There are many lines of code that rely on=
these conversions and what seems to be your goal (i.e., ease of debugging)=
can be achieved with just a compiler option.</div><div><br></div><div>Or c=
an you elaborate on the notion of conversion evilness?</div></div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">2014-09-24 22:35 GMT-03:00=
<span dir=3D"ltr"><<a href=3D"mailto:daryl.vandenbrink@maptek.com.au" =
target=3D"_blank">daryl.vandenbrink@maptek.com.au</a>></span>:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr">With refactoring work I have been=
doing over the past few months, I have come to the conclusion that the fol=
lowing implicit conversions are evil and shouldn't be allowed:<br><ul><=
li>from numeric types to bool</li><li>from pointer types to bool</li><li>fr=
om "false" and "0" compile-time constant expressions to=
null pointers (I believe the particularly strange conversion of "fals=
e" to a null pointer is being fixed in an upcoming standard)</li></ul>=
<p>These conversions cause many bugs and refactoring pain with incorrect ov=
erloads getting called, etc. I can't think of one good reason why these=
conversions should be implicit, except for compatibility.</p><p>PLEASE con=
sider deprecating these conversions in an upcoming revision of the C++ stan=
dard.</p><p>(And if compatibility with C is quoted as a reason for not doin=
g so - then C should also deprecate these conversions. C should also adopt =
C++'s nullptr.)<span class=3D"HOEnZb"><font color=3D"#888888"><br></fon=
t></span></p></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e013d1a44165e670503d9e32b--
.
Author: daryl.vandenbrink@maptek.com.au
Date: Wed, 24 Sep 2014 18:55:54 -0700 (PDT)
Raw View
------=_Part_10491_2124786037.1411610155219
Content-Type: text/plain; charset=UTF-8
By evil I mean, say I have two overloads of a function:
void foo(int* IntPointer);
void foo(int IntValue);
.... and I rename or remove the second overload.
Now, code the behaviour of this code silently changes:
foo(0);
.... and there is no way of finding out where such changes have taken place.
I am not aware of any compiler that will warn in these cases.
Unfortunately, the NULL constant is still widely used and relies on this
behaviour.
I guess the idea of asking compiler vendors to offer a warning has merit.
But I would also like to see the language itself move in the direction of
more type safety.
If you want a null pointer, use "nullptr".
If you want to convert an integer to a bool, use " != 0".
If you want to convert a pointer to a bool, use " != nullptr".
If you want to convert a bool to an integer, use static_cast.
Seems simple to me, and I'm already in the habit of doing this for code I
write.
On Thursday, 25 September 2014 11:10:39 UTC+9:30, Pablo Oliva wrote:
>
> Why wouldn't you ask your compiler manufacturer for a flag or an option to
> avoid implicit conversions, instead of modifying the whole standard?
>
> There are many lines of code that rely on these conversions and what seems
> to be your goal (i.e., ease of debugging) can be achieved with just a
> compiler option.
>
> Or can you elaborate on the notion of conversion evilness?
>
> 2014-09-24 22:35 GMT-03:00 <daryl.va...@maptek.com.au <javascript:>>:
>
>> With refactoring work I have been doing over the past few months, I have
>> come to the conclusion that the following implicit conversions are evil and
>> shouldn't be allowed:
>>
>> - from numeric types to bool
>> - from pointer types to bool
>> - from "false" and "0" compile-time constant expressions to null
>> pointers (I believe the particularly strange conversion of "false" to a
>> null pointer is being fixed in an upcoming standard)
>>
>> These conversions cause many bugs and refactoring pain with incorrect
>> overloads getting called, etc. I can't think of one good reason why these
>> conversions should be implicit, except for compatibility.
>>
>> PLEASE consider deprecating these conversions in an upcoming revision of
>> the C++ standard.
>>
>> (And if compatibility with C is quoted as a reason for not doing so -
>> then C should also deprecate these conversions. C should also adopt C++'s
>> nullptr.)
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_10491_2124786037.1411610155219
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">By evil I mean, say I have two overloads of a function:<br=
><br>void foo(int* IntPointer);<br>void foo(int IntValue);<br><br>... and I=
rename or remove the second overload.<br>Now, code the behaviour of this c=
ode silently changes:<br><br>foo(0);<br><br>... and there is no way of find=
ing out where such changes have taken place.<br><br>I am not aware of any c=
ompiler that will warn in these cases. Unfortunately, the NULL constant is =
still widely used and relies on this behaviour.<br><br>I guess the idea of =
asking compiler vendors to offer a warning has merit. But I would also like=
to see the language itself move in the direction of more type safety.<br><=
br>If you want a null pointer, use "nullptr".<br>If you want to convert an =
integer to a bool, use " !=3D 0".<br>If you want to convert a pointer to a =
bool, use " !=3D nullptr".<br>If you want to convert a bool to an integer, =
use static_cast.<br><br>Seems simple to me, and I'm already in the habit of=
doing this for code I write.<br><br>On Thursday, 25 September 2014 11:10:3=
9 UTC+9:30, Pablo Oliva wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr">Why wouldn't you ask your compiler manufacturer for a fla=
g or an option to avoid implicit conversions, instead of modifying the whol=
e standard?<div><br></div><div>There are many lines of code that rely on th=
ese conversions and what seems to be your goal (i.e., ease of debugging) ca=
n be achieved with just a compiler option.</div><div><br></div><div>Or can =
you elaborate on the notion of conversion evilness?</div></div><div><br><di=
v class=3D"gmail_quote">2014-09-24 22:35 GMT-03:00 <span dir=3D"ltr"><<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"rG3-ipds4=
8YJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">daryl.va...@maptek.com.<wbr>au</a>><=
/span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">With refactoring=
work I have been doing over the past few months, I have come to the conclu=
sion that the following implicit conversions are evil and shouldn't be allo=
wed:<br><ul><li>from numeric types to bool</li><li>from pointer types to bo=
ol</li><li>from "false" and "0" compile-time constant expressions to null p=
ointers (I believe the particularly strange conversion of "false" to a null=
pointer is being fixed in an upcoming standard)</li></ul><p>These conversi=
ons cause many bugs and refactoring pain with incorrect overloads getting c=
alled, etc. I can't think of one good reason why these conversions should b=
e implicit, except for compatibility.</p><p>PLEASE consider deprecating the=
se conversions in an upcoming revision of the C++ standard.</p><p>(And if c=
ompatibility with C is quoted as a reason for not doing so - then C should =
also deprecate these conversions. C should also adopt C++'s nullptr.)<span>=
<font color=3D"#888888"><br></font></span></p></div><span><font color=3D"#8=
88888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
rG3-ipds48YJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"rG3-ipds48YJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</font></span></blockquote></div><br></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_10491_2124786037.1411610155219--
.
Author: daryl.vandenbrink@maptek.com.au
Date: Wed, 24 Sep 2014 19:05:50 -0700 (PDT)
Raw View
------=_Part_9807_669503453.1411610750739
Content-Type: text/plain; charset=UTF-8
.... and I forgot to specify that the conversion in the other direction,
from bool to int, should also not be implicit.
On Thursday, 25 September 2014 11:05:00 UTC+9:30, daryl.va...@maptek.com.au
wrote:
>
> With refactoring work I have been doing over the past few months, I have
> come to the conclusion that the following implicit conversions are evil and
> shouldn't be allowed:
>
> - from numeric types to bool
> - from pointer types to bool
> - from "false" and "0" compile-time constant expressions to null
> pointers (I believe the particularly strange conversion of "false" to a
> null pointer is being fixed in an upcoming standard)
>
> These conversions cause many bugs and refactoring pain with incorrect
> overloads getting called, etc. I can't think of one good reason why these
> conversions should be implicit, except for compatibility.
>
> PLEASE consider deprecating these conversions in an upcoming revision of
> the C++ standard.
>
> (And if compatibility with C is quoted as a reason for not doing so - then
> C should also deprecate these conversions. C should also adopt C++'s
> nullptr.)
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_9807_669503453.1411610750739
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">... and I forgot to specify that the conversion in the oth=
er direction, from bool to int, should also not be implicit.<br><br>On Thur=
sday, 25 September 2014 11:05:00 UTC+9:30, daryl.va...@maptek.com.au wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">With refacto=
ring work I have been doing over the past few months, I have come to the co=
nclusion that the following implicit conversions are evil and shouldn't be =
allowed:<br><ul><li>from numeric types to bool</li><li>from pointer types t=
o bool</li><li>from "false" and "0" compile-time constant expressions to nu=
ll pointers (I believe the particularly strange conversion of "false" to a =
null pointer is being fixed in an upcoming standard)</li></ul><p>These conv=
ersions cause many bugs and refactoring pain with incorrect overloads getti=
ng called, etc. I can't think of one good reason why these conversions shou=
ld be implicit, except for compatibility.</p><p>PLEASE consider deprecating=
these conversions in an upcoming revision of the C++ standard.</p><p>(And =
if compatibility with C is quoted as a reason for not doing so - then C sho=
uld also deprecate these conversions. C should also adopt C++'s nullptr.)<b=
r></p></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_9807_669503453.1411610750739--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 24 Sep 2014 19:45:39 -0700
Raw View
On Wednesday 24 September 2014 18:35:00 daryl.vandenbrink@maptek.com.au wrote:
> (And if compatibility with C is quoted as a reason for not doing so - then
> C should also deprecate these conversions. C should also adopt C++'s
> nullptr.)
Two problems with that: first, the reason is probably compatibility with the
hundreds of millions of lines of code that expect that to work. It's extremely
common to write:
if (p)
with p being a pointer or an integer. Conversion of those to bool is required.
Conversion from literal zero to pointers is also required due to the millions
of lines of code that don't use nullptr yet.
The second problem is that C requires them for a different reason: booleans in
C are actually int, not the C99 type _Bool.
Anyway, as a QoI, your compiler should be able to warn of those uses,
especially the use of literal zero for a null pointer.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Myriachan <myriachan@gmail.com>
Date: Thu, 25 Sep 2014 00:46:45 -0700 (PDT)
Raw View
------=_Part_10629_683511131.1411631206272
Content-Type: text/plain; charset=UTF-8
On Wednesday, September 24, 2014 7:45:46 PM UTC-7, Thiago Macieira wrote:
> On Wednesday, September 24, 2014 6:35:00 PM UTC-7,
> daryl.va...@maptek.com.au wrote:
>
(And if compatibility with C is quoted as a reason for not doing so - then
>> C should also deprecate these conversions. C should also adopt C++'s
>> nullptr.)
>
>
>>
> Two problems with that: first, the reason is probably compatibility with
> the
> hundreds of millions of lines of code that expect that to work. It's
> extremely
> common to write:
>
> if (p)
>
>
I've always written C/C++ this way, and even get annoyed at how "!= null"
is required in Java and C#.
As for C adopting C++'s nullptr, why? With void * casting implicitly to
any pointer type, C's NULL is semantically almost equivalent to C++'s
nullptr already.
Anyway, as a QoI, your compiler should be able to warn of those uses,
> especially the use of literal zero for a null pointer.
>
>
I will say, though, that it is a little silly that false and other integral
literal expressions that evaluate to zero will implicitly convert to
pointers:
#include <sys/socket.h> // SHUT_WR is an enum whose value is 1
int main()
{
char *purr = false;
static_cast<void>(purr);
char *meow = ((4059079107ULL * 653022955U) & 4294967295U) - SHUT_WR;
static_cast<void>(meow);
return 0;
}
At least C++ doesn't allow the below nonsense, despite betraying the
"literal" part of "user-defined literal":
#include <cstdint>
template <char...>
constexpr std::uint32_t operator "" _u32()
{
return UINT32_C(0);
}
int main()
{
char *meow = 0_u32;
static_cast<void>(meow);
return 0;
}
Melissa
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_10629_683511131.1411631206272
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, September 24, 2014 7:45:46 PM UTC-7, Thiago =
Macieira wrote:<br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-l=
eft: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote=
">On Wednesday, September 24, 2014 6:35:00 PM UTC-7, daryl.va...@maptek.com=
..au wrote:<br></blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8ex; =
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">(And if compatibilit=
y with C is quoted as a reason for not=20
doing so - then C should also deprecate these conversions. C should also
adopt C++'s nullptr.) </blockquote></blockquote><blockquote style=3D"=
margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); paddi=
ng-left: 1ex;" class=3D"gmail_quote"><blockquote style=3D"margin: 0px 0px 0=
px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" cl=
ass=3D"gmail_quote"><div> </div></blockquote></blockquote><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">Two problems with that: first, the reason =
is probably compatibility with the=20
<br>hundreds of millions of lines of code that expect that to work. It's ex=
tremely=20
<br>common to write:
<br>
<br> if (p)
<br>
<br></blockquote><div><br>I've always written C/C++ this way, and even get =
annoyed at how "!=3D null" is required in Java and C#.<br><br>As for C adop=
ting C++'s nullptr, why? With void * casting implicitly to any pointe=
r type, C's NULL is semantically almost equivalent to C++'s nullptr already=
.. <br></div><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Anyway, as a Q=
oI, your compiler should be able to warn of those uses,=20
<br>especially the use of literal zero for a null pointer.
<br><br></blockquote><div><br>I will say, though, that it is a little silly=
that <span style=3D"font-family: courier new,monospace;">false</span> and =
other integral literal expressions that evaluate to zero will implicitly co=
nvert to pointers:<br><br><br><div class=3D"prettyprint" style=3D"backgroun=
d-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style=
: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypr=
int"><div class=3D"subprettyprint"><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">#include</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify"><sys/socket.h></span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled=
-by-prettify">// SHUT_WR is an enum whose value is 1</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> main</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br> </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">char</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">purr </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">false</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br> </span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">static_cast</span><span style=3D"color=
: #080;" class=3D"styled-by-prettify"><void></span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">purr</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">char</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>meow </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">((</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">4059079107ULL</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">653022955U</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">42949672=
95U</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">-</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> SHUT_WR</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">static_cast</span><span style=3D"colo=
r: #080;" class=3D"styled-by-prettify"><void></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">meow</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div><=
/code></div><br><br>At least C++ doesn't allow the below nonsense, despite =
betraying the "literal" part of "user-defined literal":<br><br><br><div cla=
ss=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-co=
lor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap:=
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">#include</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #080;" class=3D"styled-by-prettify"><cstdint></span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">char</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">...></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">constexpr</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">uint32_t </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">operator</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #080;" class=3D"styled-by-prettify">""</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> _u32</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> UINT32_C</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;" cla=
ss=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> main</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">char</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">meow </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">_u32</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">static_cast</span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify"><void></span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">meow</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;"=
class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span></div></code></div><br>Melissa<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_10629_683511131.1411631206272--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 25 Sep 2014 12:31:23 -0400
Raw View
On 2014-09-24 21:35, daryl.vandenbrink@maptek.com.au wrote:
> With refactoring work I have been doing over the past few months, I have
> come to the conclusion that the following implicit conversions are evil and
> shouldn't be allowed:
>
> - from numeric types to bool
> - from pointer types to bool
I too am strongly opposed to breaking code like 'if(p)', 'if(!p)' (where
'p' is a pointer type). Hmm... and I'll extend that to numbers, also.
> - from "false" and "0" compile-time constant expressions to null
> pointers (I believe the particularly strange conversion of "false" to a
> null pointer is being fixed in an upcoming standard)
You'll break *MASSIVE* amounts of legacy code if '0' can no longer be
used as 'nullptr'.
That said, compilers can be encouraged to provide a warning for that
(and at least GCC already does). This should include the case you
mentioned of 'void foo(int*); foo(0);'. If not, I suggest you file a bug
report with the compiler.
Implicit conversion of things other than literal '0' to nullptr (and
I'll include '0U', '0L', 'static_cast<int>(0)', etc. in that) is the
only point I agree with. And that one seems to have general agreement
and, as you mention, will hopefully be fixed "soon".
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: John Bytheway <jbytheway@gmail.com>
Date: Thu, 25 Sep 2014 18:58:55 -0400
Raw View
On 2014-09-25 03:46, Myriachan wrote:
> On Wednesday, September 24, 2014 7:45:46 PM UTC-7, Thiago Macieira wrote:
>
> On Wednesday, September 24, 2014 6:35:00 PM UTC-7,
> daryl.va...@maptek.com.au wrote:
>
> (And if compatibility with C is quoted as a reason for not doing
> so - then C should also deprecate these conversions. C should
> also adopt C++'s nullptr.)
>
>
>
> Two problems with that: first, the reason is probably compatibility
> with the
> hundreds of millions of lines of code that expect that to work. It's
> extremely
> common to write:
>
> if (p)
>
>
> I've always written C/C++ this way, and even get annoyed at how "!=
> null" is required in Java and C#.
>
> As for C adopting C++'s nullptr, why? With void * casting implicitly to
> any pointer type, C's NULL is semantically almost equivalent to C++'s
> nullptr already.
One reason would be supporting clean and safe code in headers used for
both languages.
John Bytheway
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Thu, 25 Sep 2014 17:20:54 -0700
Raw View
--047d7b342f4eeb3bac0503ece3cb
Content-Type: text/plain; charset=UTF-8
On Thu, Sep 25, 2014 at 3:58 PM, John Bytheway <jbytheway@gmail.com> wrote:
> On 2014-09-25 03:46, Myriachan wrote:
> > On Wednesday, September 24, 2014 7:45:46 PM UTC-7, Thiago Macieira wrote:
> >
> > On Wednesday, September 24, 2014 6:35:00 PM UTC-7,
> > daryl.va...@maptek.com.au wrote:
> >
> > (And if compatibility with C is quoted as a reason for not doing
> > so - then C should also deprecate these conversions. C should
> > also adopt C++'s nullptr.)
> >
> >
> >
> > Two problems with that: first, the reason is probably compatibility
> > with the
> > hundreds of millions of lines of code that expect that to work. It's
> > extremely
> > common to write:
> >
> > if (p)
> >
> >
> > I've always written C/C++ this way, and even get annoyed at how "!=
> > null" is required in Java and C#.
> >
> > As for C adopting C++'s nullptr, why? With void * casting implicitly to
> > any pointer type, C's NULL is semantically almost equivalent to C++'s
> > nullptr already.
>
> One reason would be supporting clean and safe code in headers used for
> both languages.
The C++ standard already allows the definition of NULL to be nullptr.
Another way to achieve the same goal would be to start requiring that
definition; then in code that you want to share between C and C++, use NULL.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b342f4eeb3bac0503ece3cb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Sep 25, 2014 at 3:58 PM, John Bytheway <span dir=3D"ltr"><<a href=3D=
"mailto:jbytheway@gmail.com" target=3D"_blank">jbytheway@gmail.com</a>><=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 2014-09=
-25 03:46, Myriachan wrote:<br>
> On Wednesday, September 24, 2014 7:45:46 PM UTC-7, Thiago Macieira wro=
te:<br>
><br>
>=C2=A0 =C2=A0 =C2=A0On Wednesday, September 24, 2014 6:35:00 PM UTC-7,<=
br>
>=C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:daryl.va...@maptek.com.au">daryl.=
va...@maptek.com.au</a> wrote:<br>
><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(And if compatibility with C is quote=
d as a reason for not doing<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0so - then C should also deprecate the=
se conversions. C should<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0also adopt C++'s nullptr.)<br>
><br>
><br>
><br>
>=C2=A0 =C2=A0 =C2=A0Two problems with that: first, the reason is probab=
ly compatibility<br>
>=C2=A0 =C2=A0 =C2=A0with the<br>
>=C2=A0 =C2=A0 =C2=A0hundreds of millions of lines of code that expect t=
hat to work. It's<br>
>=C2=A0 =C2=A0 =C2=A0extremely<br>
>=C2=A0 =C2=A0 =C2=A0common to write:<br>
><br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (p)<br>
><br>
><br>
> I've always written C/C++ this way, and even get annoyed at how &q=
uot;!=3D<br>
> null" is required in Java and C#.<br>
><br>
> As for C adopting C++'s nullptr, why?=C2=A0 With void * casting im=
plicitly to<br>
> any pointer type, C's NULL is semantically almost equivalent to C+=
+'s<br>
> nullptr already.<br>
<br>
</span>One reason would be supporting clean and safe code in headers used f=
or<br>
both languages.</blockquote><div><br></div><div>The C++ standard already al=
lows the definition of NULL to be nullptr. Another way to achieve the same =
goal would be to start requiring that definition; then in code that you wan=
t to share between C and C++, use NULL.</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b342f4eeb3bac0503ece3cb--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 25 Sep 2014 21:45:27 -0700
Raw View
On Thursday 25 September 2014 12:31:23 Matthew Woehlke wrote:
> Implicit conversion of things other than literal '0' to nullptr (and
> I'll include '0U', '0L', 'static_cast<int>(0)', etc. in that) is the
> only point I agree with. And that one seems to have general agreement
> and, as you mention, will hopefully be fixed "soon".
I've seen plenty of code using 0L as the null pointer, whether for stylistic
reasons (stands out) or because of an erroneous assumption that 0 wouldn't
work on 64-bit platforms. (That was old KDE code)
So, no literal zero whether unsigned, long or long long still still need to
cast to the null pointer for a while, albeit the compiler can produce a
warning.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Jim Porter <jvp4846@g.rit.edu>
Date: Fri, 26 Sep 2014 02:12:08 -0500
Raw View
On 9/24/2014 8:35 PM, daryl.vandenbrink@maptek.com.au wrote:
> With refactoring work I have been doing over the past few months, I have
> come to the conclusion that the following implicit conversions are evil
> and shouldn't be allowed:
>
> * from numeric types to bool
> * from pointer types to bool
I could see an argument for these being *explicit* conversions (pointer
types especially so), although I imagine that would still break a fair
amount of existing code. However, I agree with others that we absolutely
*shouldn't* break this:
int *p = something;
if(p) { /* ... */ }
A good first step would be to get compilers to optionally warn on
implicit conversion to bool from arithmetic or pointer types.
- Jim
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: daryl.vandenbrink@maptek.com.au
Date: Fri, 26 Sep 2014 22:45:50 -0700 (PDT)
Raw View
------=_Part_1625_610636546.1411796751096
Content-Type: text/plain; charset=UTF-8
It's interesting to note that shared_ptr has an explicit conversion
operator for conversion to bool, specifically to avoid the problems that
are encountered with raw pointers that are implicitly convertable to bool.
Yet it is still possible to use a shared_ptr in an if condition like this:
shared_ptr sp;
....
if (sp) {...}
This works because the standard specifies that in contexts where a bool is
expected, such as in if and while conditions, and arguments to logical
operators ||, && and !, an explicit conversion to bool can be implicitly
invoked. So, there's nothing to fear by making the conversion of raw
pointers to bool explicit. The same would apply for conversion of integer
types to bool.
I wasn't asking for these conversion operators to be removed completely,
only for them to be made explicit. So it seems like we can come to some
kind of agreement, at least on that issue.
If conversions of pointer and integer types to bool were made explicit, and
conversion of bool to integer types were made explicit, then I would be
happy.
As for conversion of "0", "0L" and "0UL" (but not false or other constant
expressions) to null pointers, I'd be happy if C++ continues supporting
that implicitly for the time being.
Would anyone object to this proposal?
On Friday, 26 September 2014 16:42:40 UTC+9:30, Jim Porter wrote:
>
> On 9/24/2014 8:35 PM, daryl.va...@maptek.com.au <javascript:> wrote:
> > With refactoring work I have been doing over the past few months, I have
> > come to the conclusion that the following implicit conversions are evil
> > and shouldn't be allowed:
> >
> > * from numeric types to bool
> > * from pointer types to bool
>
> I could see an argument for these being *explicit* conversions (pointer
> types especially so), although I imagine that would still break a fair
> amount of existing code. However, I agree with others that we absolutely
> *shouldn't* break this:
>
> int *p = something;
> if(p) { /* ... */ }
>
> A good first step would be to get compilers to optionally warn on
> implicit conversion to bool from arithmetic or pointer types.
>
> - Jim
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1625_610636546.1411796751096
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It's interesting to note that shared_ptr has an explicit c=
onversion operator for conversion to bool, specifically to avoid the proble=
ms that are encountered with raw pointers that are implicitly convertable t=
o bool. Yet it is still possible to use a shared_ptr in an if condition lik=
e this:<br><br>shared_ptr sp;<br>...<br>if (sp) {...}<br><br>This works bec=
ause the standard specifies that in contexts where a bool is expected, such=
as in if and while conditions, and arguments to logical operators ||, &=
;& and !, an explicit conversion to bool can be implicitly invoked. So,=
there's nothing to fear by making the conversion of raw pointers to bool e=
xplicit. The same would apply for conversion of integer types to bool.<br><=
br>I wasn't asking for these conversion operators to be removed completely,=
only for them to be made explicit. So it seems like we can come to some ki=
nd of agreement, at least on that issue.<br><br>If conversions of pointer a=
nd integer types to bool were made explicit, and conversion of bool to inte=
ger types were made explicit, then I would be happy.<br><br>As for conversi=
on of "0", "0L" and "0UL" (but not false or other constant expressions) to =
null pointers, I'd be happy if C++ continues supporting that implicitly for=
the time being.<br><br>Would anyone object to this proposal?<br><br>On Fri=
day, 26 September 2014 16:42:40 UTC+9:30, Jim Porter wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">On 9/24/2014 8:35 PM, <a href=3D"javascript:"=
target=3D"_blank" gdf-obfuscated-mailto=3D"yxbKskMiSRkJ" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';=
return true;">daryl.va...@maptek.com.<wbr>au</a> wrote:
<br>> With refactoring work I have been doing over the past few months, =
I have
<br>> come to the conclusion that the following implicit conversions are=
evil
<br>> and shouldn't be allowed:
<br>>
<br>> * from numeric types to bool
<br>> * from pointer types to bool
<br>
<br>I could see an argument for these being *explicit* conversions (pointer=
=20
<br>types especially so), although I imagine that would still break a fair=
=20
<br>amount of existing code. However, I agree with others that we absolutel=
y=20
<br>*shouldn't* break this:
<br>
<br> int *p =3D something;
<br> if(p) { /* ... */ }
<br>
<br>A good first step would be to get compilers to optionally warn on=20
<br>implicit conversion to bool from arithmetic or pointer types.
<br>
<br>- Jim
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1625_610636546.1411796751096--
.
Author: daryl.vandenbrink@maptek.com.au
Date: Fri, 26 Sep 2014 22:55:33 -0700 (PDT)
Raw View
------=_Part_1615_1465335541.1411797334397
Content-Type: text/plain; charset=UTF-8
It's interesting to note that shared_ptr has an explicit conversion
operator for conversion to bool, specifically to avoid the problems that
are encountered with raw pointers that are implicitly convertable to bool.
Yet it is still possible to use a shared_ptr in an if condition like this:
shared_ptr ptr;
....
if (ptr) {...}
So, there's nothing to fear by making the conversion of raw pointers to
bool explicit. The same would apply for conversion of integer types to bool.
I wasn't asking for these conversion operators to be removed completely,
only for them to be made explicit. So it seems like we can come to some
kind of agreement, at least on that issue.
If conversions of pointer and integer types to bool were made explicit, and
conversion of bool to integer types were made explicit, then I would be
happy.
As for conversion of "0", "0L" and "0UL" (but not false or other constant
expressions) to null pointers, I'd be happy if C++ continues supporting
that implicitly for the time being.
On Friday, 26 September 2014 16:42:40 UTC+9:30, Jim Porter wrote:
>
> On 9/24/2014 8:35 PM, daryl.va...@maptek.com.au <javascript:> wrote:
> > With refactoring work I have been doing over the past few months, I have
> > come to the conclusion that the following implicit conversions are evil
> > and shouldn't be allowed:
> >
> > * from numeric types to bool
> > * from pointer types to bool
>
> I could see an argument for these being *explicit* conversions (pointer
> types especially so), although I imagine that would still break a fair
> amount of existing code. However, I agree with others that we absolutely
> *shouldn't* break this:
>
> int *p = something;
> if(p) { /* ... */ }
>
> A good first step would be to get compilers to optionally warn on
> implicit conversion to bool from arithmetic or pointer types.
>
> - Jim
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1615_1465335541.1411797334397
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It's interesting to note that shared_ptr has an explicit c=
onversion=20
operator for conversion to bool, specifically to avoid the problems that
are encountered with raw pointers that are implicitly convertable to=20
bool. Yet it is still possible to use a shared_ptr in an if condition=20
like this:<br><br>shared_ptr ptr;<br>...<br>if (ptr) {...}<br><br>So, there=
's nothing to fear by making the conversion
of raw pointers to bool explicit. The same would apply for conversion=20
of integer types to bool.<br><br>I wasn't asking for these conversion=20
operators to be removed completely, only for them to be made explicit.=20
So it seems like we can come to some kind of agreement, at least on that
issue.<br><br>If conversions of pointer and integer types to bool were=20
made explicit, and conversion of bool to integer types were made=20
explicit, then I would be happy.<br><br>As for conversion of "0", "0L"=20
and "0UL" (but not false or other constant expressions) to null=20
pointers, I'd be happy if C++ continues supporting that implicitly for=20
the time being.<br><br>On Friday, 26 September 2014 16:42:40 UTC+9:30, Jim =
Porter wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 9/24/2014 8:3=
5 PM, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"yx=
bKskMiSRkJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">daryl.va...@maptek.com.<wbr>au<=
/a> wrote:
<br>> With refactoring work I have been doing over the past few months, =
I have
<br>> come to the conclusion that the following implicit conversions are=
evil
<br>> and shouldn't be allowed:
<br>>
<br>> * from numeric types to bool
<br>> * from pointer types to bool
<br>
<br>I could see an argument for these being *explicit* conversions (pointer=
=20
<br>types especially so), although I imagine that would still break a fair=
=20
<br>amount of existing code. However, I agree with others that we absolutel=
y=20
<br>*shouldn't* break this:
<br>
<br> int *p =3D something;
<br> if(p) { /* ... */ }
<br>
<br>A good first step would be to get compilers to optionally warn on=20
<br>implicit conversion to bool from arithmetic or pointer types.
<br>
<br>- Jim
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1615_1465335541.1411797334397--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 26 Sep 2014 23:51:51 -0700
Raw View
On Friday 26 September 2014 22:55:33 daryl.vandenbrink@maptek.com.au wrote:
> I wasn't asking for these conversion operators to be removed completely,
> only for them to be made explicit. So it seems like we can come to some
> kind of agreement, at least on that issue.
In other words, what did you exclude?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Peter Koch Larsen <peter.koch.larsen@gmail.com>
Date: Sat, 27 Sep 2014 13:07:16 +0200
Raw View
On Thu, Sep 25, 2014 at 3:55 AM, <daryl.vandenbrink@maptek.com.au> wrote:
> By evil I mean, say I have two overloads of a function:
>
> void foo(int* IntPointer);
> void foo(int IntValue);
>
> ... and I rename or remove the second overload.
> Now, code the behaviour of this code silently changes:
>
> foo(0);
>
> ... and there is no way of finding out where such changes have taken place.
>
[snip]
As others have said, this is not likely to happen - for many good reasons.
In hindsight, you might have saved yourself a lot of trouble by
deleting the function instead of removing it: void foo(int IntValue) =
delete;
/Peter
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: daryl.vandenbrink@maptek.com.au
Date: Sun, 28 Sep 2014 17:56:11 -0700 (PDT)
Raw View
------=_Part_2144_1384544197.1411952172109
Content-Type: text/plain; charset=UTF-8
On Saturday, 27 September 2014 20:37:18 UTC+9:30, Peter Koch Larsen wrote:
>
> As others have said, this is not likely to happen - for many good reasons.
> In hindsight, you might have saved yourself a lot of trouble by
> deleting the function instead of removing it: void foo(int IntValue) =
> delete;
>
That would've worked, if I had a compiler that supported defaulted/deleted
functions. But this problem doesn't just come up when deleting functions;
it can come up when you least expect it. So I thought that more type safety
in the language would go a long way towards preventing it, but obviously
not everyone agrees, but I haven't yet seen many of those reasons why.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2144_1384544197.1411952172109
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, 27 September 2014 20:37:18 UTC+9:30, Peter Ko=
ch Larsen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">As others hav=
e said, this is not likely to happen - for many good reasons.
<br>In hindsight, you might have saved yourself a lot of trouble by
<br>deleting the function instead of removing it: void foo(int IntValue) =
=3D
<br>delete;<br></blockquote><div><br>That would've worked, if I had a compi=
ler that supported defaulted/deleted functions. But this problem doesn't ju=
st come up when deleting functions; it can come up when you least expect it=
.. So I thought that more type safety in the language would go a long way to=
wards preventing it, but obviously not everyone agrees, but I haven't yet s=
een many of those reasons why.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2144_1384544197.1411952172109--
.