Topic: Templated malloc, calloc and realloc - remove all
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 3 Aug 2015 01:21:26 +0300
Raw View
On 3 August 2015 at 01:15, <robbepop@web.de> wrote:
> Since recent standards banned operator new's usage for modern C++ programs,
No C++ standard has done anything of the sort.
> The only places where one actually uses 'new' in modern C++ is, when writing
> an allocater and even there one could just use plain old C malloc.
Placement forms and class-specific overloads continue to be useful, and we're
very likely to continue improving new, like making it alignment-aware.
--
---
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: Tue, 4 Aug 2015 14:18:23 -0700 (PDT)
Raw View
------=_Part_3623_342577963.1438723104099
Content-Type: multipart/alternative;
boundary="----=_Part_3624_1200402199.1438723104099"
------=_Part_3624_1200402199.1438723104099
Content-Type: text/plain; charset=UTF-8
On Sunday, August 2, 2015 at 3:21:28 PM UTC-7, Ville Voutilainen wrote:
>
> Placement forms and class-specific overloads continue to be useful, and
> we're
> very likely to continue improving new, like making it alignment-aware.
>
This is where my admittedly-radical suggestion earlier came from: it
explicitly defines what happens when you do new/delete/new[]/delete[]. It
would permit overriding compiler-default behavior, like where to store the
array length. It also defines issues such as alignment.
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_3624_1200402199.1438723104099
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, August 2, 2015 at 3:21:28 PM UTC-7, Ville Vouti=
lainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Placement forms a=
nd class-specific overloads continue to be useful, and we're
<br>very likely to continue improving new, like making it alignment-aware.
<br></blockquote><div><br>This is where my admittedly-radical suggestion ea=
rlier came from: it explicitly defines what happens when you do new/delete/=
new[]/delete[].=C2=A0 It would permit overriding compiler-default behavior,=
like where to store the array length.=C2=A0 It also defines issues such as=
alignment.<br><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_3624_1200402199.1438723104099--
------=_Part_3623_342577963.1438723104099--
.
Author: Jim Porter <jvp4846@g.rit.edu>
Date: Tue, 4 Aug 2015 18:11:14 -0500
Raw View
On 8/2/2015 5:21 PM, Ville Voutilainen wrote:
> On 3 August 2015 at 01:15, <robbepop@web.de> wrote:
>> Since recent standards banned operator new's usage for modern C++ programs,
>
> No C++ standard has done anything of the sort.
I read this as "coding standards" (e.g. those provided by a specific
employer), not the C++ standard.
>> The only places where one actually uses 'new' in modern C++ is, when writing
>> an allocater and even there one could just use plain old C malloc.
>
> Placement forms and class-specific overloads continue to be useful, and we're
> very likely to continue improving new, like making it alignment-aware.
I could see an argument for providing a new placement-new syntax and
retiring the new/delete keywords, but perhaps that's water under the
bridge now.
- 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: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Wed, 5 Aug 2015 13:24:34 +0100
Raw View
--089e0158b6c04aed55051c8f7cdb
Content-Type: text/plain; charset=UTF-8
Quick question: How many of the coding standards that aim at minimizing
'new' allow 'malloc'?
I have the feeling that you are mistaking the wording with the intention.
Coding standards recommending "avoid raw new", are not recommending the
use of 'malloc', but rather to avoid memory management altogether and leave
memory management to libraries. There is nothing in 'new' that is not as
bad or worse with 'malloc', not only you need to still manage memory but
also the creation of the object with placement new over the allocated
memory.
Not to mention 'realloc'... which may shift the position of the objects
from one location to another, leave dangling references, violate object
lifetimes...
David
On Sun, Aug 2, 2015 at 11:15 PM, <robbepop@web.de> wrote:
> Since recent standards banned operator new's usage for modern C++
> programs, wouldn't make it sense to take initial steps in order to make the
> language even less dependent on this operator?
>
> The only places where one actually uses 'new' in modern C++ is, when
> writing an allocater and even there one could just use plain old C malloc.
> We could lay more focus on malloc and create some useful templates for it
> in order to make C++ devs more happy when encountering those in the wild.
>
> What about template functions for:
>
> T* mem_alloc<T>(size_t size = 1u) noexcept;
> T* mem_calloc<T>(size_t size) noexcept;
> T* mem_realloc<T>(size_t size) noexcept;
>
> (or malloc<T>, calloc<T>, realloc<T> ...)
>
> Internally those could easily use reinterpret_cast<T*> to convert the
> void* of the C API.
>
> Usage example:
> auto p = malloc<T>();
> instead of:
> auto p = reinterpret_cast<T*>(malloc(sizeof(T)));
> => implicit 1 element - no ugly casts!
>
> auto arr = malloc<T>(n);
> instead of:
> auto arr = reinterpret_cast<T*>(malloc(n * sizeof(T)));
> => allocates an array of size n on heap
>
> auto q = calloc<T>(n);
> instead of:
> auto q = reinterpret_cast<T*>(malloc(n, sizeof(T)));
> => allocates n elements of type T initialized by 0. (this function could
> be improved to default initialize or initialize by a given value)
>
> auto q = realloc<T>(p, n); // where 'p' is type of T*
> instead of:
> auto q = reinterpret_cast<T*>(realloc(p, n * sizeof(T)));
>
> These changes would enhance usage of modern malloc and reduce usage of the
> otherwise useless 'new' operator which could lead to a long term
> deprecation of this operator.
>
> Regards,
> Rob
>
> --
>
> ---
> 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/.
--089e0158b6c04aed55051c8f7cdb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Quick question: How many of the coding standards that aim =
at minimizing 'new' allow 'malloc'?<br><br>I have the feeli=
ng that you are mistaking the wording with the intention. Coding standards =
recommending =C2=A0"avoid raw new", are not recommending the use =
of 'malloc', but rather to avoid memory management altogether and l=
eave memory management to libraries.=C2=A0 There is nothing in 'new'=
; that is not as bad or worse with 'malloc', not only you need to s=
till manage memory but also the creation of the object with placement new o=
ver the allocated memory.<br><br>Not to mention 'realloc'... which =
may shift the position of the objects from one location to another, leave d=
angling references, violate object lifetimes...<br><br>=C2=A0 =C2=A0 David<=
/div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Aug =
2, 2015 at 11:15 PM, <span dir=3D"ltr"><<a href=3D"mailto:robbepop@web.=
de" target=3D"_blank">robbepop@web.de</a>></span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr">Since recent standards banned operator =
new's usage for modern C++ programs, wouldn't make it sense to take=
initial steps in order to make the language even less dependent on this op=
erator?<br><br>The only places where one actually uses 'new' in mod=
ern C++ is, when writing an allocater and even there one could just use pla=
in old C malloc.<br>We could lay more focus on malloc and create some usefu=
l templates for it in order to make C++ devs more happy when encountering t=
hose in the wild.<br><br>What about template functions for:<br><br>T* mem_a=
lloc<T>(size_t size =3D 1u) noexcept;<br>T* mem_calloc<T>(size_=
t size) noexcept;<br>T* mem_realloc<T>(size_t size) noexcept;<br><br>=
(or malloc<T>, calloc<T>, realloc<T> ...)<br><br>Internal=
ly those could easily use reinterpret_cast<T*> to convert the void* o=
f the C API.<br><br>Usage example:<br>auto p =3D malloc<T>();<br>inst=
ead of:<br>auto p =3D reinterpret_cast<T*>(malloc(sizeof(T)));<br>=3D=
> implicit 1 element - no ugly casts!<br><br>auto arr =3D malloc<T>=
;(n);<br>instead of:<br>auto arr =3D reinterpret_cast<T*>(malloc(n * =
sizeof(T)));<br>=3D> allocates an array of size n on heap<br><br>auto q =
=3D calloc<T>(n);<br>instead of:<br>auto q =3D reinterpret_cast<T*=
>(malloc(n, sizeof(T)));<br>=3D> allocates n elements of type T initi=
alized by 0. (this function could be improved to default initialize or init=
ialize by a given value)<br><br>auto q =3D realloc<T>(p, n); // where=
'p' is type of T*<br>instead of:<br>auto q =3D reinterpret_cast<=
;T*>(realloc(p, n * sizeof(T)));<br><br>These changes would enhance usag=
e of modern malloc and reduce usage of the otherwise useless 'new' =
operator which could lead to a long term deprecation of this operator.<br><=
br>Regards,<br>Rob<span class=3D"HOEnZb"><font color=3D"#888888"><br></font=
></span></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 />
--089e0158b6c04aed55051c8f7cdb--
.