So what was the conclusion(if any) reached on how to allocate/deallocate
objects on the C heap -
equivalent of C++ new and delete keywords?
The summary i've reached so far:
1) "new" allocates on GC heap, and manually freeing memory allocated to GC's
heap is not a good
idea be it either via dele
On 13/07/2010 19:36, Andrei Alexandrescu wrote:
free(). But manual deletion has no business in the garbage collected
heap. That currently druntime provides it is an accident caused by the
current implementation; most GC's cannot provide efficient manual
reclamation. And they shouldn't anyway.
(T
Andrei Alexandrescu Wrote:
> And how would you use such a feature effectively? I've seen such
> "optional implementation" policies in standards such as SQL
> (compatibility levels) and C++ (export). They _always_ fare disastrously.
Just like we do it now: write code for the garbage collected env
Justin Johansson Wrote:
> Andrei Alexandrescu wrote:
> > On 07/14/2010 01:15 AM, Kagamin wrote:
> >> Andrei Alexandrescu Wrote:
> >>
> >>> most GC's cannot provide efficient manual reclamation. And they
> >>> shouldn't anyway.
> >>>
> >> If one doesn't want to implement a function, he can throw
>
Andrei Alexandrescu wrote:
On 07/14/2010 01:15 AM, Kagamin wrote:
Andrei Alexandrescu Wrote:
most GC's cannot provide efficient manual reclamation. And they
shouldn't anyway.
If one doesn't want to implement a function, he can throw
NotImplementedException, or don't provide the function so t
On 07/14/2010 01:15 AM, Kagamin wrote:
Andrei Alexandrescu Wrote:
most GC's cannot provide efficient manual reclamation. And they
shouldn't anyway.
If one doesn't want to implement a function, he can throw
NotImplementedException, or don't provide the function so that
program using the delete
Andrei Alexandrescu Wrote:
> most GC's cannot provide efficient manual
> reclamation. And they shouldn't anyway.
>
If one doesn't want to implement a function, he can throw
NotImplementedException, or don't provide the function so that program using
the delete won't link. But deallocation of al
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> On 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 (
On 14 July 2010 00:50, Leandro Lucarella 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 highl
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
> > wrote:
> >
> >>Vladimir Panteleev:
> >>>ARGHARGHARGH
> >>
> >>There is emplace() now. I don't know how much good it currently is.
> 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 t
Replacing delete or forbidding it in detriment of a safer alternative
function indeed makes sense when compiling in the SafeD language subset.
However, the delete operation has a well defined role in "unsafe" D.
The most advantageous would be adding clear() as well as a possible
"destroy()" functio
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
wrote:
Vladimir Panteleev:
ARGHARGHARGH
There is emplace() now. I don't know how much good it currently is.
On 07/13/2010 05:10 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:i1inhi$2fo...@digitalmars.com...
On 07/13/2010 04:42 PM, Vladimir Panteleev wrote:
On Wed, 14 Jul 2010 00:33:20 +0300, bearophile
wrote:
Vladimir Panteleev:
ARGHARGHARGH
There is emplace() now. I
On 7/13/10, Nick Sabalausky 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
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
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
"Andrei Alexandrescu" wrote in message
news:i1inhi$2fo...@digitalmars.com...
> On 07/13/2010 04:42 PM, Vladimir Panteleev wrote:
>> On Wed, 14 Jul 2010 00:33:20 +0300, bearophile
>> wrote:
>>
>>> Vladimir Panteleev:
ARGHARGHARGH
>>>
>>> There is emplace() now. I don't know how much good it
On 07/13/2010 04:42 PM, Vladimir Panteleev wrote:
On Wed, 14 Jul 2010 00:33:20 +0300, bearophile
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 v
On 07/13/2010 04:15 PM, Vladimir Panteleev wrote:
On Tue, 13 Jul 2010 23:16:30 +0300, Andrei Alexandrescu
wrote:
Not quite. New is different because it is a primitive - it can't be
implemented as a function (well it could if it user placement new, but
we're back to square one). In contrast, de
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
On 07/13/2010 04:15 PM, Vladimir Panteleev wrote:
On Tue, 13 Jul 2010 23:16:30 +0300, Andrei Alexandrescu
wrote:
Not quite. New is different because it is a primitive - it can't be
implemented as a function (well it could if it user placement new, but
we're back to square one). In contrast, de
On Wed, 14 Jul 2010 00:33:20 +0300, bearophile
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
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) an
On Wed, 14 Jul 2010 00:17:18 +0300, bearophile
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.
[
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#ne
On Tue, 13 Jul 2010 23:16:30 +0300, Andrei Alexandrescu
wrote:
Not quite. New is different because it is a primitive - it can't be
implemented as a function (well it could if it user placement new, but
we're back to square one). In contrast, delete already knows the type
of the object it's de
On Tue, 13 Jul 2010 22:42:05 +0300, bearophile
wrote:
So in SafeD the delete operation can be replaced by something safer, a
way to tell the GC to deallocate just a specific object, walking the
graph and setting to null all the inbound pointers (this is a slower
operation).
I'd just li
Andrei Alexandrescu:
> The problem is that many of today's GC are structured in ways that make
> efficient reclamation of individual block extremely inefficient.
If the GC is conservative it can think some reference to a memory block exists,
despite it's a false reference, so it can delay even f
On 07/13/2010 03:16 PM, Andrei Alexandrescu wrote:
On 07/13/2010 01:59 PM, Vladimir Panteleev wrote:
On Tue, 13 Jul 2010 21:36:02 +0300, Andrei Alexandrescu
wrote:
Not quite. New is different because it is a primitive - it can't be
implemented as a function (well it could if it user placement
On 07/13/2010 02:42 PM, bearophile wrote:
Andrei Alexandrescu:
But manual deletion has no business in the garbage collected
heap. That currently druntime provides it is an accident caused by the
current implementation; most GC's cannot provide efficient manual
reclamation. And they shouldn't any
On 07/13/2010 01:59 PM, Vladimir Panteleev wrote:
On Tue, 13 Jul 2010 21:36:02 +0300, Andrei Alexandrescu
wrote:
Not quite. New is different because it is a primitive - it can't be
implemented as a function (well it could if it user placement new, but
we're back to square one). In contrast, de
Andrei Alexandrescu:
> But manual deletion has no business in the garbage collected
> heap. That currently druntime provides it is an accident caused by the
> current implementation; most GC's cannot provide efficient manual
> reclamation. And they shouldn't anyway.
The structure of memory bloc
On Tue, 13 Jul 2010 21:36:02 +0300, Andrei Alexandrescu
wrote:
Not quite. New is different because it is a primitive - it can't be
implemented as a function (well it could if it user placement new, but
we're back to square one). In contrast, delete already knows the type of
the object it
On 07/13/2010 01:12 PM, Vladimir Panteleev wrote:
On Tue, 13 Jul 2010 18:30:26 +0300, Andrei Alexandrescu
wrote:
I agree deprecation shouldn't be taken lightly, but delete is not a
fundamental operator - it could and should be defined at most as a
simple function.
delete is the antipod of ne
On Tue, 13 Jul 2010 18:30:26 +0300, Andrei Alexandrescu
wrote:
I agree deprecation shouldn't be taken lightly, but delete is not a
fundamental operator - it could and should be defined at most as a
simple function.
delete is the antipod of new. With this logic, I don't see why new
shou
On 07/13/2010 09:45 AM, Francisco Almeida wrote:
I agree, deprecating a fundamental operator like delete should not be
taken lightly.
I agree deprecation shouldn't be taken lightly, but delete is not a
fundamental operator - it could and should be defined at most as a
simple function.
A lo
On 07/13/2010 06:48 AM, Vladimir Panteleev wrote:
On Mon, 12 Jul 2010 09:16:58 +0300, Andrei Alexandrescu
wrote:
On 07/11/2010 11:24 PM, Vladimir Panteleev wrote:
On Mon, 12 Jul 2010 00:00:46 +0300, bearophile
wrote:
A std lib function is not set in stone, later it can be improved,
modifie
I agree, deprecating a fundamental operator like delete should not be
taken lightly. A lot of us prefer to manage the memory manually and do
RAII for our own reasons. By all means, add clear(obj) to the
language/standard library, but both methods should always be available.
There is no valid reason
On Mon, 12 Jul 2010 09:16:58 +0300, Andrei Alexandrescu
wrote:
On 07/11/2010 11:24 PM, Vladimir Panteleev wrote:
On Mon, 12 Jul 2010 00:00:46 +0300, bearophile
wrote:
A std lib function is not set in stone, later it can be improved,
modified, etc.
But the same could be said about any la
On 07/12/2010 03:01 AM, Robert M. Münch wrote:
On 2010-07-12 05:03:06 +0200, Petr said:
Ok, so I now know how to explicitly free memory allocated to the GC
heap. Now the question is, should we have the usual C* c = new C(),
and I wanted to allocate it to unmanaged memory(just like it would in
C
On 2010-07-12 05:03:06 +0200, Petr said:
Ok, so I now know how to explicitly free memory allocated to the GC
heap. Now the question is, should we have the usual C* c = new C(), and
I wanted to allocate it to unmanaged memory(just like it would in C++)
and then at some
point call the destructor
On 07/11/2010 11:24 PM, Vladimir Panteleev wrote:
On Mon, 12 Jul 2010 00:00:46 +0300, bearophile
wrote:
A std lib function is not set in stone, later it can be improved,
modified, etc.
But the same could be said about any language feature! Deprecating the
delete statement, and increasing the
On 07/12/2010 12:12 AM, Eric Poggel wrote:
On 7/12/2010 12:46 AM, Rainer Deyke wrote:
On 7/11/2010 22:24, Vladimir Panteleev wrote:
But the same could be said about any language feature! Deprecating the
delete statement, and increasing the verbosity of the code for the sake
of customizability a
On 7/12/2010 12:46 AM, Rainer Deyke wrote:
On 7/11/2010 22:24, Vladimir Panteleev wrote:
But the same could be said about any language feature! Deprecating the
delete statement, and increasing the verbosity of the code for the sake
of customizability appears absurd to me. Why not move the implem
On 7/11/2010 22:24, Vladimir Panteleev wrote:
> But the same could be said about any language feature! Deprecating the
> delete statement, and increasing the verbosity of the code for the sake
> of customizability appears absurd to me. Why not move the implementation
> of the delete statement to th
On Mon, 12 Jul 2010 00:00:46 +0300, bearophile
wrote:
A std lib function is not set in stone, later it can be improved,
modified, etc.
But the same could be said about any language feature! Deprecating the
delete statement, and increasing the verbosity of the code for the sake of
custo
Ok, so I now know how to explicitly free memory allocated to the GC heap. Now
the question is, should we have the usual C* c = new C(), and I wanted to
allocate it to unmanaged memory(just like it would in C++) and then at some
point call the destructor on it and free the memory, outside of the G
Vladimir Panteleev:
> Can someone please explain to me how this is different and *better* than
> the allegedly now-deprecated delete statement?
A std lib function is not set in stone, later it can be improved, modified, etc.
> Also, what happens if the object instance was allocated on the stac
On Sun, 11 Jul 2010 21:29:40 +0300, bearophile
wrote:
Simen kjaeraas:
Petr:
What would happen if i skipped clear()?
Then your destructors wouldn't get called. GC.free takes a humble void
pointer, which knows little of destructors and other such fancy things.
If you feel unsure you will
Simen kjaeraas:
> Petr:
>> What would happen if i skipped clear()?
>
> Then your destructors wouldn't get called. GC.free takes a humble void
> pointer, which knows little of destructors and other such fancy things.
>
> If you feel unsure you will remember, feel free to use this function:
>
> v
"Lars T. Kyllingstad" wrote:
> On Sun, 11 Jul 2010 03:53:12 +, Petr wrote:
>
>> Hi all,
>>
>> I know this has been discussed million times before, but there is so
>> many posts on the mailing lists on this subject and all of them
>> different, its kind of hard to find what's authoritative an
On Sun, 11 Jul 2010 03:53:12 +, Petr wrote:
> Hi all,
>
> I know this has been discussed million times before, but there is so
> many posts on the mailing lists on this subject and all of them
> different, its kind of hard to find what's authoritative and whats not.
> TDPL doesn't really talk
On Sun, 11 Jul 2010 11:45:12 +0300, Simen kjaeraas
wrote:
There is also GC.malloc, which does basically the same. It has some bells
on it, but I know not for sure what they do.
GC.malloc will allocate managed memory (it will be unallocated when the GC
will not see any references to it).
Petr wrote:
1) Do i do clear(c) and then GC.free(c)?
Yes.
What would happen if i skipped clear()?
Then your destructors wouldn't get called. GC.free takes a humble void
pointer, which knows little of destructors and other such fancy things.
If you feel unsure you will remember, feel fre
On Sun, 11 Jul 2010 06:53:12 +0300, Petr wrote:
the delete keyword is deprecated
Wait, what?
http://www.digitalmars.com/d/2.0/expression.html#DeleteExpression
(didn't get my TDPL yet because I live in the middle of nowhere)
--
Best regards,
Vladimirmailto:vladi
Hi all,
I know this has been discussed million times before, but there is so many posts
on the mailing lists on this subject
and all of them different, its kind of hard to find what's authoritative and
whats not. TDPL doesn't really talk much
about this subject either, it just says the delete ke
56 matches
Mail list logo
