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

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

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.

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.

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.

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.