Jump to page: 1 2
Thread overview
C++ and D @ stackoverflow
Jun 12, 2010
BCS
Jun 12, 2010
Leandro Lucarella
Jun 12, 2010
Walter Bright
Jun 12, 2010
Brad Roberts
Jun 12, 2010
Walter Bright
Jun 12, 2010
Brad Roberts
Jun 12, 2010
Walter Bright
Jun 13, 2010
Leandro Lucarella
June 12, 2010
http://stackoverflow.com/questions/3024136/link-compatibility-between-c-and-d


-- 
... <IXOYE><



June 12, 2010
BCS wrote:
> http://stackoverflow.com/questions/3024136/link-compatibility-between-c-and-d 

I just posted an answer that contains a couple of news.

Andrei
June 12, 2010
Andrei Alexandrescu, el 12 de junio a las 00:32 me escribiste:
> BCS wrote:
> >http://stackoverflow.com/questions/3024136/link-compatibility-between-c-and-d
> 
> I just posted an answer that contains a couple of news.

As I said with your new RefCounted implementation, unless I'm missing something, there will be problems if you store pointers (or objects that have pointers) to the GC heap, as you never communicate with the GC.

I don't think is a good idea to include such structures (if I'm not mistaken), they only piss-off people messing with their memories, introducing the subtle ugly problems they wanted to avoid coming to a GC'ed language.

Or at least you should include a *HUGE* disclaimer telling people they can't store pointers to the GC heap in that structures (unless they have roots to the same pointed objects in another part of the GC roots, of course :).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Es mucho mas probable que el salchichón sea primavera a que la primavera
sea salchichón.
	-- Peperino Pómoro
June 12, 2010
Leandro Lucarella wrote:
> Andrei Alexandrescu, el 12 de junio a las 00:32 me escribiste:
>> BCS wrote:
>>> http://stackoverflow.com/questions/3024136/link-compatibility-between-c-and-d
>> I just posted an answer that contains a couple of news.
> 
> As I said with your new RefCounted implementation, unless I'm missing
> something, there will be problems if you store pointers (or objects that
> have pointers) to the GC heap, as you never communicate with the GC.

Could you please give an example? Thanks!

Andrei
June 12, 2010
Andrei Alexandrescu wrote:
> Leandro Lucarella wrote:
>> Andrei Alexandrescu, el 12 de junio a las 00:32 me escribiste:
>>> BCS wrote:
>>>> http://stackoverflow.com/questions/3024136/link-compatibility-between-c-and-d 
>>>>
>>> I just posted an answer that contains a couple of news.
>>
>> As I said with your new RefCounted implementation, unless I'm missing
>> something, there will be problems if you store pointers (or objects that
>> have pointers) to the GC heap, as you never communicate with the GC.
> 
> Could you please give an example? Thanks!

All you have to do is for your malloc'd data, tell the gc about it so it can search the malloc'd data for pointers.

Add the data with:

	import core.memory;

	addRange(p, size);

and remove it when calling free() with:

	removeRange(p);

You don't need to do this if the array elements do not contain any pointers or references, for example, if they are an array of ints.
June 12, 2010
On 6/12/2010 8:57 AM, Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> Leandro Lucarella wrote:
>>> Andrei Alexandrescu, el 12 de junio a las 00:32 me escribiste:
>>>> BCS wrote:
>>>>> http://stackoverflow.com/questions/3024136/link-compatibility-between-c-and-d
>>>>>
>>>> I just posted an answer that contains a couple of news.
>>>
>>> As I said with your new RefCounted implementation, unless I'm missing something, there will be problems if you store pointers (or objects that have pointers) to the GC heap, as you never communicate with the GC.
>>
>> Could you please give an example? Thanks!
> 
> All you have to do is for your malloc'd data, tell the gc about it so it can search the malloc'd data for pointers.
> 
> Add the data with:
> 
>     import core.memory;
> 
>     addRange(p, size);
> 
> and remove it when calling free() with:
> 
>     removeRange(p);
> 
> You don't need to do this if the array elements do not contain any pointers or references, for example, if they are an array of ints.

Or, even better:

import core.memory;

void* m = GC.malloc(size);
June 12, 2010
Brad Roberts wrote:
> Or, even better:
> 
> import core.memory;
> 
> void* m = GC.malloc(size);

The idea was to not use the gc, instead explicitly manage the block of memory.
June 12, 2010
On 6/12/2010 1:53 PM, Walter Bright wrote:
> Brad Roberts wrote:
>> Or, even better:
>>
>> import core.memory;
>>
>> void* m = GC.malloc(size);
> 
> The idea was to not use the gc, instead explicitly manage the block of memory.

Actually, the point was to get precise lifetime of memory, right?  That's where the refcounting comes in.  That the memory comes from the gc doesn't mean it can't be refcounted to achieve that.  It does mean that it's needlessly scanned as part of any collection cycles.  It's not too hard to suggest that it's worth doing to find refcount cycles that should have gone away.

June 12, 2010
Brad Roberts wrote:
> On 6/12/2010 1:53 PM, Walter Bright wrote:
>> Brad Roberts wrote:
>>> Or, even better:
>>>
>>> import core.memory;
>>>
>>> void* m = GC.malloc(size);
>> The idea was to not use the gc, instead explicitly manage the block of
>> memory.
> 
> Actually, the point was to get precise lifetime of memory, right?  That's where
> the refcounting comes in.  That the memory comes from the gc doesn't mean it
> can't be refcounted to achieve that.  It does mean that it's needlessly scanned
> as part of any collection cycles.  It's not too hard to suggest that it's worth
> doing to find refcount cycles that should have gone away.
> 

You're right, but enormous effort has gone into improving malloc/free, why not take advantage of it? It also serves as a demonstration for how to do it.
June 13, 2010
Andrei Alexandrescu, el 12 de junio a las 07:20 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el 12 de junio a las 00:32 me escribiste:
> >>BCS wrote:
> >>>http://stackoverflow.com/questions/3024136/link-compatibility-between-c-and-d
> >>I just posted an answer that contains a couple of news.
> >
> >As I said with your new RefCounted implementation, unless I'm missing something, there will be problems if you store pointers (or objects that have pointers) to the GC heap, as you never communicate with the GC.
> 
> Could you please give an example? Thanks!

I guess is clear from the suggestion by Walter, but basically you are
not telling the GC about the roots outside the stack(s) and static data.
If the GC can't reach an object from that roots, but those objects are
still pointed by the malloc()ed memory, the GC will recycle the
"dangling" objects (from the GC POV) and bad things will happen (memory
corruption, basically).

I hope it clarifies.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Ladrón no es cualquiera, ladrón es quien usurpa el bien ajeno en
beneficio propio, si no, no.
	-- Ricardo Vaporeso
« First   ‹ Prev
1 2