www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - D compiler need -nogc witch and document of library also need nogc

reply dangbinghoo <dangbinghoo gmail.com> writes:
hi there,

I think that D compiler needs -nogc switch to fully disable gc 
for a project, and document of phobos also needs a friendly way 
to list-out all  nogc API.

we already have -betterC, and betterC disabled GC, why we could 
not have a standalone option for doing this?



----
binghoo dang
Jun 11 2019
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Tuesday, 11 June 2019 at 08:05:31 UTC, dangbinghoo wrote:

 hi there,

 I think that D compiler needs -nogc switch to fully disable gc 
 for a project, and document of phobos also needs a friendly way 
 to list-out all  nogc API.

 we already have -betterC, and betterC disabled GC, why we could 
 not have a standalone option for doing this?



 ----
 binghoo dang


you can do this with a druntime switch or by calling GC.disable  
in your main()
Jun 11 2019
parent reply Basile B. <b2.temp gmx.com> writes:
On Tuesday, 11 June 2019 at 08:08:14 UTC, Basile B. wrote:

 On Tuesday, 11 June 2019 at 08:05:31 UTC, dangbinghoo wrote:

 hi there,

 I think that D compiler needs -nogc switch to fully disable gc 
 for a project, and document of phobos also needs a friendly 
 way to list-out all  nogc API.

 we already have -betterC, and betterC disabled GC, why we 
 could not have a standalone option for doing this?



 ----
 binghoo dang


 you can do this with a druntime switch or by calling GC.disable
  in your main()


the druntime switch is "--DRT-gc=gc:manual". You pass it the 
compiled program after its own args.
Jun 11 2019
parent reply dangbinghoo <dangbinghoo gmail.com> writes:
On Tuesday, 11 June 2019 at 08:16:31 UTC, Basile B. wrote:

 On Tuesday, 11 June 2019 at 08:08:14 UTC, Basile B. wrote:



 you can do this with a druntime switch or by calling GC.disable
  in your main()


 the druntime switch is "--DRT-gc=gc:manual". You pass it the 
 compiled program after its own args.


thanks, I know this from dlang.org. But this is not useful when 
trying to write  nogc code for a project.

We need to make sure we use only  nogc API when writing code, not 
when running the app.


Thanks!


----
binghoo dang
Jun 11 2019
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 11 June 2019 at 08:59:01 UTC, dangbinghoo wrote:

 We need to make sure we use only  nogc API when writing code, 
 not when running the app.


That's what the  nogc annotation does, statically forces you to 
only use other  nogc stuff via compiler errors.
Jun 11 2019
parent reply dangbinghoo <dangbinghoo gmail.com> writes:
On Tuesday, 11 June 2019 at 12:40:39 UTC, Adam D. Ruppe wrote:

 On Tuesday, 11 June 2019 at 08:59:01 UTC, dangbinghoo wrote:

 We need to make sure we use only  nogc API when writing code, 
 not when running the app.


 That's what the  nogc annotation does, statically forces you to 
 only use other  nogc stuff via compiler errors.


yeah,  nogc does the job. But the problem is that, you need to 
mark all functions, classes, everything you write to manually 
marked, so if compiler supports -nogc, it will helps great.


-----
binghoo dang
Jun 11 2019
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jun 11, 2019 at 02:46:03PM +0000, dangbinghoo via Digitalmars-d-learn
wrote:

 On Tuesday, 11 June 2019 at 12:40:39 UTC, Adam D. Ruppe wrote:

 On Tuesday, 11 June 2019 at 08:59:01 UTC, dangbinghoo wrote:

 We need to make sure we use only  nogc API when writing code, not
 when running the app.


 
 That's what the  nogc annotation does, statically forces you to only
 use other  nogc stuff via compiler errors.


 
 yeah,  nogc does the job. But the problem is that, you need to mark
 all functions, classes, everything you write to manually marked, so if
 compiler supports -nogc, it will helps great.


[...]

Try putting ` nogc:` at the top of each file, like this:

	 nogc:

	struct MyStruct { ... }
	int myFunc(...) { ... }
	// etc.


T

-- 
Never ascribe to malice that which is adequately explained by incompetence. --
Napoleon Bonaparte
Jun 11 2019
prev sibling parent reply KnightMare <black80 bk.ru> writes:
On Tuesday, 11 June 2019 at 08:05:31 UTC, dangbinghoo wrote:

 I think that D compiler needs -nogc switch to fully disable gc 
 for a project,


LDC -nogc?


 and document of phobos also needs a friendly way to list-out 
 all  nogc API.


+1
people who are interested only in betterC/nogc shouldn't see 
documentation to api that they are not suitable.
Jun 11 2019
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 11 June 2019 at 10:24:05 UTC, KnightMare wrote:

 people who are interested only in betterC/nogc shouldn't see 
 documentation to api that they are not suitable.


I've considered doing that before, but it is actually impossible 
to get right in the general case due to attribute inference.

Consider `map`, for example. If you map a nogc function, map is 
nogc. But if not, it isn't - it depends on what function the user 
passes to it. So the documentation can not know for sure.
Jun 11 2019
parent reply KnightMare <black80 bk.ru> writes:
On Tuesday, 11 June 2019 at 12:42:03 UTC, Adam D. Ruppe wrote:

 On Tuesday, 11 June 2019 at 10:24:05 UTC, KnightMare wrote:

 people who are interested only in betterC/nogc shouldn't see 
 documentation to api that they are not suitable.


 I've considered doing that before, but it is actually 
 impossible to get right in the general case due to attribute 
 inference.

 Consider `map`, for example. If you map a nogc function, map is 
 nogc. But if not, it isn't - it depends on what function the 
 user passes to it. So the documentation can not know for sure.


imo problem with nogc/betterc is more deeper.
lets suppose we already have rcstring class and man want to write 
func that returns slice of it.
char[] someStrProcess(...) {
   rcstring tmp = "hello" ~ rcreadln; // somehow we got rcstring
   return tmp[5..$-5];
}
with current slise (struct{.ptr, .length}) we have a problem - 
data of tmp we'll be freed at function exit and current slice 
will ref to garbage. so compiler should forbid such situation.
this is not very well coz people read four current books where 
the slices were colorfully described, but for some reason a 
person cannot use them. they will come to forum and will ask 
another clarifying questions.

ok. we should returns some another 
slice(struct{.rcarray,.offset,.length}) which knows about RC:
rcslice<char> someStrProcess(...) {
   rcstring tmp = "hello" ~ rcreadln; // somehow we got rcstring
   return tmp[5..$-5]; // I dont want return whole string just 
part of it
   // should I return new rcstring as tmp.substr( 5, tmp.length-10 
)?
   // should we lose slices at all?
}
and this is something new that not described yet. well, it will 
be.
but maybe better write compiler that will returns rcslice as 
native new style slice char[] that knows about RC? some lang that 
mix of D and Swift which already used RC as ARC with familiar 
from book syntax.
and tada! we have two different language in one compiler, we have 
two different RT with one compiler. maybe it will be Phobos and 
Deimos.
Jun 11 2019
parent KnightMare <black80 bk.ru> writes:
On Tuesday, 11 June 2019 at 14:44:20 UTC, KnightMare wrote:
Stroustrup said about C++ (not exactly quote. I translated it 
from my lang not English):
since C and C ++ will be used by the same people on
many years, the differences between languages should be
either minimal or maximal to minimize the amount
mistakes and misunderstandings.

so this 2 modes - gc & nogc - of D must follow the same principle.
DBC with RC will be new lang.
so, will they be very similar or very different?
Jun 11 2019
prev sibling parent dangbinghoo <dangbinghoo gmail.com> writes:
On Tuesday, 11 June 2019 at 10:24:05 UTC, KnightMare wrote:

 On Tuesday, 11 June 2019 at 08:05:31 UTC, dangbinghoo wrote:

 I think that D compiler needs -nogc switch to fully disable gc 
 for a project,


 LDC -nogc?


thanks for help. It's a shame that I didn't look in details of 
the LCD help info.
Yeah, the great LDC already support this!

Thanks!

-------
binghoo dang
Jun 11 2019