digitalmars.D - Re: Manual memory management in D2
- bearophile <bearophileHUGS lycos.com> Jul 13 2010
- "Vladimir Panteleev" <vladimir thecybershadow.net> Jul 13 2010
- bearophile <bearophileHUGS lycos.com> Jul 13 2010
- Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Jul 13 2010
- Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Jul 13 2010
- "Nick Sabalausky" <a a.a> Jul 13 2010
- div0 <div0 users.sourceforge.net> Jul 13 2010
- Petr <janda.petr gmail.com> Jul 13 2010
- pillsy <pillsbury gmail.com> Jul 13 2010
- "Vladimir Panteleev" <vladimir thecybershadow.net> Jul 13 2010
- Adam Ruppe <destructionator gmail.com> Jul 13 2010
- Leandro Lucarella <luca llucax.com.ar> Jul 13 2010
- Tim Verweij <tjverweij gmail.com> Jul 13 2010
Vladimir Panteleev:However, D allows overloading new/delete for custom allocators[1] - this can be used for a cleaner way to allocate objects in unmanaged memory. I don't see why this use of the delete keyword should be deprecated. [1]: http://digitalmars.com/d/2.0/memory.html#newdelete
Andrei (and Walter too, I presume) has killed that too just few days ago :o) Bye, bearophile
Jul 13 2010
On Wed, 14 Jul 2010 00:17:18 +0300, bearophile <bearophileHUGS lycos.com> wrote:Vladimir Panteleev:However, D allows overloading new/delete for custom allocators[1] - this can be used for a cleaner way to allocate objects in unmanaged memory. I don't see why this use of the delete keyword should be deprecated. [1]: http://digitalmars.com/d/2.0/memory.html#newdelete
Andrei (and Walter too, I presume) has killed that too just few days ago :o)
ARGHARGHARGH * forks D * -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jul 13 2010
Vladimir Panteleev:ARGHARGHARGH
There is emplace() now. I don't know how much good it currently is.* forks D *
I think you can't fork D2 in simple ways, because I think you can't just copy the back-end. To fork D2 you probably have to work on the D2 version of LDC (it's not finished) and then you can modify it. Creating LDC2 is a good thing, but probably forking it now is kind of useless :-) Bye, bearophile
Jul 13 2010
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> On 07/13/2010 04:33 PM, bearophile wrote:Vladimir Panteleev:ARGHARGHARGH
There is emplace() now. I don't know how much good it currently is.
rocks. Andrei
Jul 13 2010
On 07/13/2010 04:42 PM, Vladimir Panteleev wrote:On Wed, 14 Jul 2010 00:33:20 +0300, bearophile <bearophileHUGS lycos.com> wrote:Vladimir Panteleev:ARGHARGHARGH
There is emplace() now. I don't know how much good it currently is.
I know that I can do this manually in other ways, the problem is that this creates verbose and unintuitive code.
I agree. I think we should, again, define two primitives: T* malloc(T, A...)(A args) if (!is(T == class) && !isDynamicArray!T); T malloc(T, A...)(A args) if (is(T == class) || isDynamicArray!T); free(T)(ref T obj); The first two call C's malloc, constructor (if any), and returns the allocated object. The last calls the destructor (if any) and then free(). worksforyou? Andrei
Jul 13 2010
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message news:i1inhi$2fon$1 digitalmars.com...On 07/13/2010 04:42 PM, Vladimir Panteleev wrote:On Wed, 14 Jul 2010 00:33:20 +0300, bearophile <bearophileHUGS lycos.com> wrote:Vladimir Panteleev:ARGHARGHARGH
There is emplace() now. I don't know how much good it currently is.
I know that I can do this manually in other ways, the problem is that this creates verbose and unintuitive code.
I agree. I think we should, again, define two primitives: T* malloc(T, A...)(A args) if (!is(T == class) && !isDynamicArray!T); T malloc(T, A...)(A args) if (is(T == class) || isDynamicArray!T); free(T)(ref T obj); The first two call C's malloc, constructor (if any), and returns the allocated object. The last calls the destructor (if any) and then free(). worksforyou?
I think I'm missing something. Instead of regressing back to malloc & co., why not just have the custom allocators?
Jul 13 2010
On 07/13/2010 05:10 PM, Nick Sabalausky wrote:"Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org> wrote in message news:i1inhi$2fon$1 digitalmars.com...On 07/13/2010 04:42 PM, Vladimir Panteleev wrote:On Wed, 14 Jul 2010 00:33:20 +0300, bearophile <bearophileHUGS lycos.com> wrote:Vladimir Panteleev:ARGHARGHARGH
There is emplace() now. I don't know how much good it currently is.
I know that I can do this manually in other ways, the problem is that this creates verbose and unintuitive code.
I agree. I think we should, again, define two primitives: T* malloc(T, A...)(A args) if (!is(T == class)&& !isDynamicArray!T); T malloc(T, A...)(A args) if (is(T == class) || isDynamicArray!T); free(T)(ref T obj); The first two call C's malloc, constructor (if any), and returns the allocated object. The last calls the destructor (if any) and then free(). worksforyou?
I think I'm missing something. Instead of regressing back to malloc& co., why not just have the custom allocators?
Because C++ allocators suck but I never knew exactly why. So... your design here. Andrei
Jul 13 2010
On 13/07/2010 22:58, Andrei Alexandrescu wrote:On 07/13/2010 04:42 PM, Vladimir Panteleev wrote:On Wed, 14 Jul 2010 00:33:20 +0300, bearophile <bearophileHUGS lycos.com> wrote:Vladimir Panteleev:ARGHARGHARGH
There is emplace() now. I don't know how much good it currently is.
I know that I can do this manually in other ways, the problem is that this creates verbose and unintuitive code.
I agree. I think we should, again, define two primitives: T* malloc(T, A...)(A args) if (!is(T == class) && !isDynamicArray!T); T malloc(T, A...)(A args) if (is(T == class) || isDynamicArray!T); free(T)(ref T obj); The first two call C's malloc, constructor (if any), and returns the allocated object. The last calls the destructor (if any) and then free(). worksforyou? Andrei
Are they going to register the range with the GC for scanning? If so then fine. I do stuff where I've got deterministically allocated structs which can wind up having the only live references to other GC objects. Though perhaps we could have 2 different functions, one that registers the object with the GC & one without. Being able to easily mix & match memory strategies is a great feature so it would be nice to still be able to easily do it, even if you make it all library functions with great big 'Danger Will Robinson!' stickers all over it. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Jul 13 2010
On 07/13/2010 05:15 PM, div0 wrote:On 13/07/2010 22:58, Andrei Alexandrescu wrote:On 07/13/2010 04:42 PM, Vladimir Panteleev wrote:On Wed, 14 Jul 2010 00:33:20 +0300, bearophile <bearophileHUGS lycos.com> wrote:Vladimir Panteleev:ARGHARGHARGH
There is emplace() now. I don't know how much good it currently is.
I know that I can do this manually in other ways, the problem is that this creates verbose and unintuitive code.
I agree. I think we should, again, define two primitives: T* malloc(T, A...)(A args) if (!is(T == class) && !isDynamicArray!T); T malloc(T, A...)(A args) if (is(T == class) || isDynamicArray!T); free(T)(ref T obj); The first two call C's malloc, constructor (if any), and returns the allocated object. The last calls the destructor (if any) and then free(). worksforyou? Andrei
Are they going to register the range with the GC for scanning?
Yah, just like std.container.Array does.If so then fine. I do stuff where I've got deterministically allocated structs which can wind up having the only live references to other GC objects. Though perhaps we could have 2 different functions, one that registers the object with the GC & one without. Being able to easily mix & match memory strategies is a great feature so it would be nice to still be able to easily do it, even if you make it all library functions with great big 'Danger Will Robinson!' stickers all over it.
std.container.Array automatically detects the existence of pointers. But then the pointers could be to other mallocated stuff, so your proposed primitive makes sense. Andrei
Jul 13 2010
T* malloc(T, A...)(A args) if (!is(T == class) && !isDynamicArray!T); T malloc(T, A...)(A args) if (is(T == class) || isDynamicArray!T); free(T)(ref T obj);
The first two call C's malloc, constructor (if any), and returns the allocated object. The last calls the destructor (if any) and then free().
worksforyou?
Then again, why not just port C++ std::memory interface to make C++ programmers feel right at home? :) Thanks, Petr
Jul 13 2010
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s articleOn 07/13/2010 04:42 PM, Vladimir Panteleev wrote:
I agree. I think we should, again, define two primitives:
T* malloc(T, A...)(A args) if (!is(T == class) && !isDynamicArray!T); T malloc(T, A...)(A args) if (is(T == class) || isDynamicArray!T); free(T)(ref T obj);
The first two call C's malloc, constructor (if any), and returns the allocated object. The last calls the destructor (if any) and then free(). worksforyou?
I think malloc should be malloc and free should be free. I'd like almost any other conceivable pair of names better, like make/unmake, create/destroy, build/smash, whatever. Cheers, Pillsy
Jul 13 2010
On Wed, 14 Jul 2010 00:33:20 +0300, bearophile <bearophileHUGS lycos.com> wrote:Vladimir Panteleev:ARGHARGHARGH
There is emplace() now. I don't know how much good it currently is.
I know that I can do this manually in other ways, the problem is that this creates verbose and unintuitive code.* forks D *
I think you can't fork D2 in simple ways, because I think you can't just copy the back-end. To fork D2 you probably have to work on the D2 version of LDC (it's not finished) and then you can modify it. Creating LDC2 is a good thing, but probably forking it now is kind of useless :-)
Strictly hypothetically speaking, if I really were to fork D I'd just host a source repository of the frontend, or publish frontend patches. Compiling DMD is pretty simple. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jul 13 2010
On 7/13/10, Nick Sabalausky <a a.a> wrote:I think I'm missing something. Instead of regressing back to malloc & co., why not just have the custom allocators?
For me, what I don't like is they are in the wrong place. If you use a malloc/free custom allocator, that fact is hidden in the class. There's no outward indication that you need to use care and delete it. Also, if you have one class that you want to use in two separate ways, the custom allocator doesn't do it. Sometimes I want it manually, sometimes I want it automatic. The usage site is where I want to make the decision, rarely in the class definition.
Jul 13 2010
Andrei Alexandrescu, el 13 de julio a las 16:58 me escribiste:On 07/13/2010 04:42 PM, Vladimir Panteleev wrote:On Wed, 14 Jul 2010 00:33:20 +0300, bearophile <bearophileHUGS lycos.com> wrote:Vladimir Panteleev:ARGHARGHARGH
There is emplace() now. I don't know how much good it currently is.
I know that I can do this manually in other ways, the problem is that this creates verbose and unintuitive code.
I agree. I think we should, again, define two primitives: T* malloc(T, A...)(A args) if (!is(T == class) && !isDynamicArray!T); T malloc(T, A...)(A args) if (is(T == class) || isDynamicArray!T); free(T)(ref T obj); The first two call C's malloc, constructor (if any), and returns the allocated object. The last calls the destructor (if any) and then free(). worksforyou?
Please, don't name them malloc() and free(), their names are highly associated with just asking for memory. If you ditch new and delete, just name them new() and delete() :). But maybe it isn't a good idea anyway because new/delete are highly associated with the GC (OTOH you can overload new/delete to use other allocators). Maybe create() and destroy()? They could accept an optional function pointer/delegate with the same signature as malloc/free to do the actual allocation/freeing and default to C's malloc/free. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Vivimos en una época muy contemporánea, Don Inodoro... -- Mendieta
Jul 13 2010
--002215048e777712ee048b4d1b54 Content-Type: text/plain; charset=ISO-8859-1 On 14 July 2010 00:50, Leandro Lucarella <luca llucax.com.ar> wrote:Please, don't name them malloc() and free(), their names are highly associated with just asking for memory. If you ditch new and delete, just name them new() and delete() :). But maybe it isn't a good idea anyway because new/delete are highly associated with the GC (OTOH you can overload new/delete to use other allocators). Maybe create() and destroy()? They could accept an optional function pointer/delegate with the same signature as malloc/free to do the actual allocation/freeing and default to C's malloc/free.
TimV --002215048e777712ee048b4d1b54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 14 July 2010 00:50, Leandro Lucarella <span d= ir=3D"ltr"><<a href=3D"mailto:luca llucax.com.ar">luca llucax.com.ar</a>= ></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0p= t 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1= ex;"> <div class=3D"h5"> </div>Please, don't name them malloc() and free(), their names are high= ly<br> associated with just asking for memory. If you ditch new and delete,<br> just name them new() and delete() :). But maybe it isn't a good idea<br=
can overload new/delete to use other allocators). Maybe create() and<br> destroy()?<br> <br> They could accept an optional function pointer/delegate with the same<br> signature as malloc/free to do the actual allocation/freeing and default<br=
<div class=3D"im"><br></div></blockquote><br></div>This makes sense to me. = I second these suggestions.<br><br>TimV<br> --002215048e777712ee048b4d1b54--
Jul 13 2010