www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Compile time check for GC?

reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
Is there some way for library authors to test whether a GC is 
present at compile time?  nogc just means that my code does not 
depend on a GC, but it doesn't tell the compiler that my code is 
incompatible with GC.

I want to compute pointers in a way that is not scannable by a 
conservative collector for performance reasons. So I need to make 
sure that the faster code isn't chosen when people use GC using 
"static if"s.
Jan 26 2021
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/26/21 8:10 AM, Ola Fosheim Grøstad wrote:

 Is there some way for library authors to test whether a GC is present at 
 compile time?  nogc just means that my code does not depend on a GC, but 
 it doesn't tell the compiler that my code is incompatible with GC.
 
 I want to compute pointers in a way that is not scannable by a 
 conservative collector for performance reasons. So I need to make sure 
 that the faster code isn't chosen when people use GC using "static if"s.
 
 
 


The only way to ensure the GC isn't used is with betterC. Even with 
 nogc tag on main, the GC could be used in static ctors, and casting 
function pointers/etc.

In that case, you can do version(D_BetterC)

And this will only apply to templates, not to compiled code, since 
compiled code already is done (and one can obviously use betterC 
compiled code in normal D code).

-Steve
Jan 26 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 26 January 2021 at 15:30:09 UTC, Steven Schveighoffer 
wrote:

 The only way to ensure the GC isn't used is with betterC. Even 
 with  nogc tag on main, the GC could be used in static ctors, 
 and casting function pointers/etc.


Yes,  nogc is not strong enough... It is for a container library, 
so maybe I could put test for the properties of the elements 
instead?

I guess I would want test if the Element type contains a pointer 
that should be traced by the GC.

But how would I go about it?


 And this will only apply to templates, not to compiled code, 
 since compiled code already is done (and one can obviously use 
 betterC compiled code in normal D code).


Yes, but templates is ok, but I think Better_C is too restrictive 
in the long term. So I hope there is some way for my library to 
figure out if it has to care about GC for the template parameters 
the user provides.

I guess I also will find the equivalent of C++ 
std::trivially_copyable, std::trivially_destructible in Phobos, 
to figure out if memcpy is safe.
Jan 26 2021
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/26/21 11:00 AM, Ola Fosheim Grøstad wrote:

 On Tuesday, 26 January 2021 at 15:30:09 UTC, Steven Schveighoffer wrote:

 The only way to ensure the GC isn't used is with betterC. Even with 
  nogc tag on main, the GC could be used in static ctors, and casting 
 function pointers/etc.


 
 Yes,  nogc is not strong enough... It is for a container library, so 
 maybe I could put test for the properties of the elements instead?
 
 I guess I would want test if the Element type contains a pointer that 
 should be traced by the GC.
 
 But how would I go about it?


std.traits.hasAliasing?


 And this will only apply to templates, not to compiled code, since 
 compiled code already is done (and one can obviously use betterC 
 compiled code in normal D code).


 
 Yes, but templates is ok, but I think Better_C is too restrictive in the 
 long term. So I hope there is some way for my library to figure out if 
 it has to care about GC for the template parameters the user provides.


I thought about it a bit more, and even this is not good enough. One can 
compile a betterC library using your code, which is then used by a 
GC-allocating app, which means your library is told betterC is in use 
while compiling the template, but the GC is still involved.

So there doesn't seem to be a way to be sure that a pointer is not a GC 
pointer.

-Steve
Jan 26 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 26 January 2021 at 16:08:15 UTC, Steven Schveighoffer 
wrote:

 std.traits.hasAliasing?


I guess, but it will limit me too much. I should accept Element 
types that manage their own memory and has pointers to sub-ojects 
that don't point to GC memory. But I guess that would require a 
language extension or I would have to establish my own protocol 
(basically some enum I can test for, I guesss).



 enough. One can compile a betterC library using your code, 
 which is then used by a GC-allocating app, which means your 
 library is told betterC is in use while compiling the template, 
 but the GC is still involved.

 So there doesn't seem to be a way to be sure that a pointer is 
 not a GC pointer.


:-/
Jan 26 2021
prev sibling parent reply Kagamin <spam here.lot> writes:
You can define a symbol that will conflict with GC and prevent 
linking with it.
Jan 27 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 27 January 2021 at 20:21:02 UTC, Kagamin wrote:

 You can define a symbol that will conflict with GC and prevent 
 linking with it.


That was an interesting thought! Maybe that could be a first step.

It didn't occur to me that I could sabotage the usage of GC. :-D
Jan 27 2021
parent Kagamin <spam here.lot> writes:
You can make it opt in, it's insurance.
Jan 28 2021