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


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


 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.
Jun 12 2010
parent reply 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


 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);
Jun 12 2010
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 reply 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
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);


 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.
Jun 12 2010
prev sibling parent reply 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


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


 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.


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