www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - using the compiler without GC

reply watcher <test aol.com> writes:
Cheers, everybody!

I was wondering when it will be possible to use the compiler 
without the gc?

Thank you
Jul 09
next sibling parent reply Daniel Kozak <kozzi11 gmail.com> writes:
On Tue, Jul 9, 2019 at 9:37 PM watcher via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 Cheers, everybody!

 I was wondering when it will be possible to use the compiler
 without the gc?

 Thank you
I am not sure what you mean? AFAIK compiler does not use GC, just allocate and never deallocate idiom. Or do you ask when it will be possible to write D code without reliance on GC?
Jul 09
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 10/07/2019 8:48 AM, Daniel Kozak wrote:
 
 
 On Tue, Jul 9, 2019 at 9:37 PM watcher via Digitalmars-d 
 <digitalmars-d puremagic.com <mailto:digitalmars-d puremagic.com>> wrote:
 
     Cheers, everybody!
 
     I was wondering when it will be possible to use the compiler
     without the gc?
 
     Thank you
 
 
 I am not sure what you mean? AFAIK compiler does not use GC, just 
 allocate and never deallocate idiom. Or do you ask when it will be 
 possible to write D code without reliance on GC?
The compiler does use the GC. That is what the -lowmem switch does.
Jul 09
prev sibling next sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Tuesday, 9 July 2019 at 19:31:54 UTC, watcher wrote:
 Cheers, everybody!

 I was wondering when it will be possible to use the compiler 
 without the gc?

 Thank you
From your question it is unclear wheter you ask about the GC during application runtime or during the compilation process of your application. I just assume you meant the GC during application runtime. Depending on your scenario it is already possible to detect and also avoid the GC. But your question reminds me to the first rule of performance optimization: Go for readable and easy code first, optimise only if you can measure a performance issue. In this context it means: very likely you never ever will face a performance issue due to the GC. If you really face an issue, it might be in 5 % of your application. D will provide you different tools to control or even avoid GC here. Beside that, the GC was improved in recent DMD version (parallel execution) and also a fork based GC for posix system is on it's way. Kind regards Andre
Jul 09
prev sibling next sibling parent bpr <brogoff gmail.com> writes:
On Tuesday, 9 July 2019 at 19:31:54 UTC, watcher wrote:
 Cheers, everybody!

 I was wondering when it will be possible to use the compiler 
 without the gc?

 Thank you
If you want to use D as a better C, which of course includes omitting the GC, there is an aptly named compiler switch "-betterC" which leaves you with a powerful subset of D that still has the static metaprogramming features. For now, you don't have many D libraries available to you in DasBetterC. https://dlang.org/spec/betterc.html
Jul 09
prev sibling parent reply t <tette comcast.com> writes:
On Tuesday, 9 July 2019 at 19:31:54 UTC, watcher wrote:
 Cheers, everybody!

 I was wondering when it will be possible to use the compiler 
 without the gc?

 Thank you
i guess he ment: i do not want to allocate memory with the gc, but use all d features. the resultant executable should not include a gc. as far as i know, thats not possible and thats why i don't use d.
Jul 09
parent reply evilrat <evilrat666 gmail.com> writes:
On Wednesday, 10 July 2019 at 04:51:03 UTC, t wrote:
 i guess he ment:
 i do not want to allocate memory with the gc, but use all d 
 features. the resultant executable should not include a gc. as 
 far as i know, thats not possible and thats why i don't use d.
So what's the problem with simply avoiding quite short list of features that may ever involve GC, and keep the GC without work?
Jul 09
parent reply bachmeier <no spam.net> writes:
On Wednesday, 10 July 2019 at 05:41:43 UTC, evilrat wrote:
 On Wednesday, 10 July 2019 at 04:51:03 UTC, t wrote:
 i guess he ment:
 i do not want to allocate memory with the gc, but use all d 
 features. the resultant executable should not include a gc. as 
 far as i know, thats not possible and thats why i don't use d.
So what's the problem with simply avoiding quite short list of features that may ever involve GC, and keep the GC without work?
Nobody has ever chosen a language because of a feature it didn't have. That wouldn't make sense. You can write dismissive comments about a language because of features you don't like but removal of features will never be a reason to use a language.
Jul 10
next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Wednesday, 10 July 2019 at 17:14:57 UTC, bachmeier wrote:
 but removal of features will never be a reason to use a 
 language.
I think D lists the removal of the C preprocessor as a plus.
Jul 10
parent bachmeier <no spam.net> writes:
On Wednesday, 10 July 2019 at 19:29:10 UTC, Dennis wrote:
 On Wednesday, 10 July 2019 at 17:14:57 UTC, bachmeier wrote:
 but removal of features will never be a reason to use a 
 language.
I think D lists the removal of the C preprocessor as a plus.
That wouldn't be viewed as a good thing unless followed by a better way to do the same things as a preprocessor. You can't really say that the GC can be removed from D because there's something better. GC-less D doesn't bring anything new to the table.
Jul 10
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 10 July 2019 at 17:14:57 UTC, bachmeier wrote:
 On Wednesday, 10 July 2019 at 05:41:43 UTC, evilrat wrote:
 On Wednesday, 10 July 2019 at 04:51:03 UTC, t wrote:
 i guess he ment:
 i do not want to allocate memory with the gc, but use all d 
 features. the resultant executable should not include a gc. 
 as far as i know, thats not possible and thats why i don't 
 use d.
So what's the problem with simply avoiding quite short list of features that may ever involve GC, and keep the GC without work?
Nobody has ever chosen a language because of a feature it didn't have. That wouldn't make sense. You can write dismissive comments about a language because of features you don't like but removal of features will never be a reason to use a language.
Go community seems to see it differently, threating to leave if it ever improves the error handling or gets some kind of lightweight generics as part of the Go 2.0 ongoing transition.
Jul 11