• novice3 (9/9) Sep 29 2020 Naive newbie question:
• =?UTF-8?Q?Ali_=c3=87ehreli?= (7/13) Sep 29 2020 I am not a language expert but I can't imagine how the compiler knows
• IGotD- (19/26) Sep 29 2020 It doesn't need to know when a certain event happens but based on
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (3/8) Sep 29 2020 Seems like a mix of Go and Rust... People will probably end up
• bachmeier (10/19) Sep 29 2020 Completely avoiding the question about D, all it says in that
• Dukc (17/19) Oct 02 2020 I don't know V so can't be sure, but doing it the same way as in

novice3 <sorryno em.ail> writes:

Naive newbie question:

Can we have (in theory) in D lang memory management like V lang?

Quote:
   
https://github.com/vlang/v/blob/master/doc/docs.md#memory-management

"V doesn't use garbage collection or reference counting. The 
compiler cleans everything up during compilation. If your V 
program compiles, it's guaranteed that it's going to be leak 
free."

=?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:

On 9/29/20 3:57 AM, novice3 wrote:> Naive newbie question:
 Can we have (in theory) in D lang memory management like V lang?

 Quote:
 https://github.com/vlang/v/blob/master/doc/docs.md#memory-management

 "V doesn't use garbage collection or reference counting. The compiler
 cleans everything up during compilation. If your V program compiles,
 it's guaranteed that it's going to be leak free."

I am not a language expert but I can't imagine how the compiler knows 
whether an event will happen at runtime. Imagine a server program 
allocates memory for a client. Let's say, that memory will be 
deallocated when the client logs out or the server times that client 
out. The compiler cannot know either of that will ever happen, right?

Ali

IGotD- <nise nise.com> writes:

On Tuesday, 29 September 2020 at 15:47:09 UTC, Ali Çehreli wrote:
 I am not a language expert but I can't imagine how the compiler 
 knows whether an event will happen at runtime. Imagine a server 
 program allocates memory for a client. Let's say, that memory 
 will be deallocated when the client logs out or the server 
 times that client out. The compiler cannot know either of that 
 will ever happen, right?

 Ali

It doesn't need to know when a certain event happens but based on 
ownership and program flow. Let's think Rust for a moment.

You get a connection and you allocate some metadata about it. 
Then you put that metadata on a list and the list owns that 
object. It will stay there as long there is a connection and the 
program can go and do other things, the list still owns the 
metadata.

After a while the client disconnects and the program finds the 
metadata in the list and removes it and puts it in a local 
variable. Some cleanup is one but the metadata is still owned by 
the local variable and when that variable goes out of scope 
(basically end of a {} block), then it will deallocated.

It's really a combination of ownership and scopes.

That little simple example shows that you don't necessarily need 
to know things in advance in order to have static lifetimes. 
However, there are examples where there is no possibility for the 
compiler to infer when the object goes out of scope. Multiple 
ownership is an obvious example of that.

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:

On Tuesday, 29 September 2020 at 16:03:39 UTC, IGotD- wrote:
 That little simple example shows that you don't necessarily 
 need to know things in advance in order to have static 
 lifetimes. However, there are examples where there is no 
 possibility for the compiler to infer when the object goes out 
 of scope. Multiple ownership is an obvious example of that.

Seems like a mix of Go and Rust...  People will probably end up 
using array indexes instead of references... Just like in Rust.

bachmeier <no spam.net> writes:

On Tuesday, 29 September 2020 at 10:57:07 UTC, novice3 wrote:
 Naive newbie question:

 Can we have (in theory) in D lang memory management like V lang?

 Quote:
   
 https://github.com/vlang/v/blob/master/doc/docs.md#memory-management

 "V doesn't use garbage collection or reference counting. The 
 compiler cleans everything up during compilation. If your V 
 program compiles, it's guaranteed that it's going to be leak 
 free."

Completely avoiding the question about D, all it says in that 
section is

"The strings don't escape draw_text, so they are cleaned up when 
the function exits.

In fact, the first two calls won't result in any allocations at 
all. These two strings are small, V will use a preallocated 
buffer for them."

That's a toy example. It would be hard to mess that up in C, and 
I'd expect it to be easy for the compiler to handle it.

Dukc <ajieskola gmail.com> writes:

On Tuesday, 29 September 2020 at 10:57:07 UTC, novice3 wrote:
 Naive newbie question:

 Can we have (in theory) in D lang memory management like V lang?

I don't know V so can't be sure, but doing it the same way as in 
the examples sounds possible.

The first two calls are easy. D string literals are stored in the 
read-only memory that is uploaded together with the machine code 
before execution. So the naive implementation wouldn't allocate 
any more than the V version.

The third one is more difficult. To allocate without using GC or 
RC means using an owning container, that releases memory when 
exiting the scope. While they can be checked against leaking 
referenced using the `-dip1000` feature, it's practical only when 
the memory has a single clear owner and there is no need to store 
references to it elsewhere. The GC and RC are better as a 
general-purpose solution.

On the other hand, D could avoid all allocation in the third 
example by using ranges. That would cause the printing function 
to figure out the message as it prints.