I'm a bit puzzled about the whole `@nogc` thing. At first I thought it just switched off the garbage collector and that you had to allocate and free memory manually using `import core.memory: GC;` I tried this and it failed because @nogc means that the function can not allocate/free memory (https://dlang.org/spec/function.html#nogc-functions). If this is the case, how do you allocate/free memory without using the garbage collector? Does allocating and freeing memory using `GC.malloc` and `GC.free` avoid D's garbage collector? Also what is the syntax for removing dangling pointers?

Can you also confirm that `@nogc` in a class do the same thing in that class as it does for a function? Also structs are not supposed to be tracked by the garbage collector but if I do something like this:

```
struct MyType(T)
{
  T[] data;
  this(size_t n)
  {
    data = new T[n];
  }
}
```

Is `data` in `MyType` tracked by the garbage collector? If it is how do I allocate it in such a way that it is not?

Thanks

On Thursday, 21 May 2020 at 02:50:22 UTC, data pulverizer wrote:
> I'm a bit puzzled about the whole `@nogc` thing. At first I thought it just switched off the garbage collector and that you had to allocate and free memory manually using `import core.memory: GC;` I tried this and it failed because @nogc means that the function can not allocate/free memory (https://dlang.org/spec/function.html#nogc-functions). If this is the case, how do you allocate/free memory without using the garbage collector? Does allocating and freeing memory using `GC.malloc` and `GC.free` avoid D's garbage collector? Also what is the syntax for removing dangling pointers?

Marking a function @nogc means you can't use the garbage collector in that function, or call other functions that use it. It's still there, and functions that are not marked @nogc can still use it.

To allocate memory without the GC, you have a couple of options. The simplest is to use C's malloc function, which can be found in the core.stdc.stdlib module. A more complicated but more powerful option is to use a non-GC-based memory allocator from the std.experimental.allocator package. Either way, you will have to take care of freeing the memory yourself, either manually or using a technique like RAII.

On Thursday, 21 May 2020 at 02:50:22 UTC, data pulverizer wrote:
> Can you also confirm that `@nogc` in a class do the same thing in that class as it does for a function?

I don't think it does anything in either case, but if it does anything it will just apply @nogc to each member function in them.

> Is `data` in `MyType` tracked by the garbage collector?

Yes, it is tracked. What @nogc does is prohibit calling that function from ever calling the GC's collect method. It doesn't affect what is and isn't collected when that is eventually called somewhere else.

> If it is how do I allocate it in such a way that it is not?

though you can malloc memory to hide it from the GC, you generally shouldn't.

Note that in your example if T is ubyte or some other trivial value type it isn't scanned anyway since the static type info tells it it will never contain pointers/references.

On 5/20/20 10:50 PM, data pulverizer wrote:
> how do you allocate/free memory without using the garbage collector? 

Use C malloc and free.

> Does allocating and freeing memory using `GC.malloc` and `GC.free` avoid D's garbage collector?

No, an allocation can trigger a collection. D does not have a scheduled GC, it basically runs the GC when it can't allocate any more memory from it's pools before it tries to get more from the OS.

I *think* that @nogc is supposed to mean "Be able to run this without a GC implemented", not that no collections will run.

-Steve

On Thursday, 21 May 2020 at 15:09:57 UTC, Steven Schveighoffer wrote:
> On 5/20/20 10:50 PM, data pulverizer wrote:
>> how do you allocate/free memory without using the garbage collector?
>
> Use C malloc and free.
>
>> Does allocating and freeing memory using `GC.malloc` and `GC.free` avoid D's garbage collector?
>
> No, an allocation can trigger a collection. D does not have a scheduled GC, it basically runs the GC when it can't allocate any more memory from it's pools before it tries to get more from the OS.
>
> I *think* that @nogc is supposed to mean "Be able to run this without a GC implemented", not that no collections will run.
>
> -Steve

Hi all! I will try to ask again(previous two posts still have no answers) : are there any site/page/docs somewhere to track actual info about @nogc support in language itself and in phobos library? Or, at least plans to extend such support?

On Thursday, 21 May 2020 at 17:19:10 UTC, Konstantin wrote:
> Hi all! I will try to ask again(previous two posts still have no answers) : are there any site/page/docs somewhere to track actual info about @nogc support in language itself and in phobos library? Or, at least plans to extend such support?

https://dlang.org/spec/function.html#nogc-functions - here's language support. Phobos tends to infer attributes like @nogc, so it's context dependent, the actual info is provided by the compiler.

There is automem to help with manual memory management
https://code.dlang.org/packages/automem