------=_Part_959_18129842.1391638487648
Content-Type: text/plain; charset=UTF-8

Basically, my idea is like this: When using any raw pointer, the compiler
should force an error when any new statement is used without a
corresponding delete (or delete[], as the case may be,) statement.  This
would fix a number of programs with memory leaks and bring a sigh of relief
to programmers everywhere, as I understand it.

--

---
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_959_18129842.1391638487648
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Basically, my idea is like this: When using any raw pointe=
r, the compiler should force an error when any new statement is used withou=
t a corresponding delete (or delete[], as the case may be,) statement.&nbsp=
; This would fix a number of programs with memory leaks and bring a sigh of=
 relief to programmers everywhere, as I understand it.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_959_18129842.1391638487648--

.

On 6 February 2014 00:14,  <zijifayd@gmail.com> wrote:
> Basically, my idea is like this: When using any raw pointer, the compiler
> should force an error when any new statement is used without a corresponding
> delete (or delete[], as the case may be,) statement.  This would fix a
> number of programs with memory leaks and bring a sigh of relief to
> programmers everywhere, as I understand it.

Please see http://en.wikipedia.org/wiki/Halting_problem and reconsider
whether we've advanced sufficiently to be able to solve the problem.

--

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

.

--089e01494602c2e01304f1b03eeb
Content-Type: text/plain; charset=ISO-8859-1

On 5 February 2014 16:14, <zijifayd@gmail.com> wrote:

> Basically, my idea is like this: When using any raw pointer, the compiler
> should force an error when any new statement is used without a
> corresponding delete (or delete[], as the case may be,) statement.  This
> would fix a number of programs with memory leaks and bring a sigh of relief
> to programmers everywhere, as I understand it.
>

How do you do this in general at compile time?  new/delete pairing is a run
time property (which I think makes it equivalent to the halting problem).

One of the two reasons to use new in the first place is that the lifetime
of the object is not bound to a scope.

You are far better off with guidelines dissuading usage of raw new in the
first place (make_shared and make_unique eliminate most of the need) and
use things like valgrind when you can afford the significant run time hit.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

--089e01494602c2e01304f1b03eeb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 5 February 2014 16:14,  <span dir=3D"ltr">&lt;<a href=
=3D"mailto:zijifayd@gmail.com" target=3D"_blank">zijifayd@gmail.com</a>&gt;=
</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">

<div dir=3D"ltr">Basically, my idea is like this: When using any raw pointe=
r, the compiler should force an error when any new statement is used withou=
t a corresponding delete (or delete[], as the case may be,) statement.=A0 T=
his would fix a number of programs with memory leaks and bring a sigh of re=
lief to programmers everywhere, as I understand it.<span class=3D"HOEnZb"><=
font color=3D"#888888"><br>

</font></span></div></blockquote><div><br></div><div>How do you do this in =
general at compile time?=A0 new/delete pairing is a run time property (whic=
h I think makes it equivalent to the halting problem).<br><br>One of the tw=
o reasons to use new in the first place is that the lifetime of the object =
is not bound to a scope.<br>

<br></div><div>You are far better off with guidelines dissuading usage of r=
aw new in the first place (make_shared and make_unique eliminate most of th=
e need) and use things like valgrind when you can afford the significant ru=
n time hit.<br>

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--089e01494602c2e01304f1b03eeb--

.