www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++ and D stackoverflow

reply BCS <none anon.com> writes:
http://stackoverflow.com/questions/3024136/link-compatibility-between-c-and-d


-- 
... <IXOYE><
Jun 11 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jun 12 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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


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
Jun 12 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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 


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.
Jun 12 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Jun 12 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
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);

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.
Jun 12 2010
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
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.
Jun 12 2010
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
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


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);
Jun 12 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 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


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

Yes, thanks. Walter posted a conservative fix, we can improve it by defining hasIndirections which is a bit similar with hasAliasing: http://www.digitalmars.com/d/2.0/phobos/std_traits.html#hasAliasing Then the compiler decides statically to instruct the GC or not depending on hasIndirections. Andrei
Jun 12 2010
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
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
Jun 12 2010
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
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


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
Jun 12 2010