On Sunday, 26 January 2014 at 02:32:29 UTC, Frank Bauer wrote:
> Fine. Can I use it with Phobos?

Quite a bit of it, actually. There's significant parts of phobos which don't do allocation at all: std.algorithm and std.digest are two big parts that are pretty good about it.

> No it is not. It is part of the language. Every allocation *inside* the language (i.e. with new) goes through the GC.

Not necessarily, you can change the allocation strategy if you want by providing your own function. _d_newclass is a major example.

The language sometimes makes tracking the reference really hard, for example, getting tho pointer to free with a closure is tricky, and tracking temporaries made with the binary concat operator. (You could perhaps do it but it would be really easy to lose a reference somewhere and leak it, I think binary concat should just be left unimplemented if you aren't using the gc (and avoided even if you are in any performance critical section)).

So yeah, it is possible to go without the GC with the D language by changing runtime functions but the language doesn't help you get it *right*.

On 1/25/14 6:32 PM, Frank Bauer wrote:
>> There aren't that many language features that depend on a GC, and the
>> ones that do can be disabled with a custom runtime.
>
> I don't want to miss out on a single language feature of D. Where is
> that GC-free runtime?

GC is a language feature of D.

As funny as that may seem (as a comeback timed almost too well) this has interesting truth to it. Some convenience features of D require GC to work, and that's as cut and dried as it gets. Without them, D would need to sacrifice some features or complicate the language or concentrate focus on that aspect alone (and I suspect Rust is guilty of at least some of the above).

You can't have all of D without GC for the simple reason that GC is convenient and simplifies things, and often such things are desirable. Of course, reducing within reason, modularizing, and compartmentalizing the need/use of GC is a goal worth working toward. But all that requires reason and measure.

>> druntime/Phobos are designed for a mixed allocation strategy, where
>> tracing GC is one of the strategies used. Many Phobos types and
>> functions do not rely on a GC.
>
> In theory (which gives me hope), not in practice. Where is that GC-free
> Phobos?
>
>> Java and C# do not function well without GC at all (disregarding the
>> effort you'd have to go through to get a Java or C# implementation
>> without GC).
>>
>> D definitely *does*.
>
> Again, this gives me hope. Please Walter, Andrei: search all the forums
> for "I want D with opt-in GC" (fuzzy search, that is) and count matches.

We believe the clamor is overblown. The patterns in which D produces garbage (litter, for the most part) are very different from those in languages that don't offer a choice. Focusing on library functions that produce a few garbage-collected strings when the bulk of the load is elsewhere - that's penny wise and pound foolish.

That said, it's good to have control and rein in over how and where litter is produced. We see this as an ongoing focus.


Andrei

On Sunday, 26 January 2014 at 02:03:29 UTC, Frank Bauer wrote:
> On Saturday, 25 January 2014 at 23:02:44 UTC, anonymous wrote:
>> You have access to C's standard library from D.
>
> I'm aware that I can use a D subset that is roughly equivalent to C and C's standard library. This subset is precisely what I am *not* talking about. I am talking about all the great modern architectural features of D and Phobos.

You're asking for something to exist right now, which doesn't. You want a GC-free minimum runtime which allows use of the majority of the language (actually you sound like you want all, but that can't happen), and a standard library which can be used GC-free. This does not exist and everyone is well aware of it, hence the question of this thread "Current state of "D as a better C" (Windows)?"

However your initial post claims that the language won't let us achieve that state, and people here are trying to explain that simply isn't true, we just don't have the libraries built up yet.

Someone needs to take the approach of using D as C, that means give up all the nice feature of D and use it as if it were C. That person will then need to build out and submit patches to bring more of the D language into this "C" world.

@Adam: thanks for pointing out _d_newclass for me. But for classes I would just simply use custom allocators and deallocators and use new and delete as in C++.

Leaves dynamic arrays and the rest of Phobos (which parts?) which I have to forego if I don't like GC (but I do like slices so much, not much left for me to slice then ...). And no, anonymous, it's not just reallocating or appending to arrays, every dynamic array is allocated on the GC'd heap from the start.

I would really like to have something like Rust's owned pointer and refernce semantics in D by default:

Allocation with new gives an *owning pointer* similar to std.typecons.Unique, that frees its associated memory automatically when it goes out of scope.

Creating a *reference* from an owning pointer gives a 'non-owning' pointer with no effect on automatic memory management whatsoever, but with the compiler-enforced requirement that its associated owning pointer can not be mutated as long as there are outstanding references in scope. Also the lifetime of a reference can not exceed the lifetime of the owning pointer it stems from.

This is why even a working (http://forum.dlang.org/thread/l96otj$tsj$1@digitalmars.com) std.typecons.Unique is not enough. The relationship between owning pointers and references needs compiler enforcement.

@Andrei: Short of dumping all GC-dependent language concepts, GC collection cycle times are key, no matter how little litter is produced. Hope the GC tracing algorithm you are implementing for the new custom allocators does not have to chase references too deep into the heap. Maybe implementing Rust-style owning pointers and references into the core language could turn out to be less time-consuming? We could still have GC around as an option a la GCollect!MyClass.

On Sunday, 26 January 2014 at 04:18:47 UTC, Jesse Phillips wrote:
> However your initial post claims that the language won't let us achieve that state, and people here are trying to explain that simply isn't true, we just don't have the libraries built up yet.
>

Wrong. Read one post above:

On Sunday, 26 January 2014 at 03:29:00 UTC, Andrei Alexandrescu wrote:
> GC is a language feature of D.
>
> As funny as that may seem (as a comeback timed almost too well) this has interesting truth to it. Some convenience features of D require GC to work, and that's as cut and dried as it gets.

But I agree with Andrei: it requires reason and measure. I just think that D could keep all of the features that make it great (modules, templates, slices are without rival, Phobos is well laid out), even after a complete overhaul of the memory system. Or watch part of the (real) systems programmers move from C++ to Rust (should it reach a stable 1.0, it already compiles itself) and the Java / C# crowd stay where they are.

On Sunday, 26 January 2014 at 05:17:35 UTC, Frank Bauer wrote:
> @Adam: thanks for pointing out _d_newclass for me. But for classes I would just simply use custom allocators and deallocators and use new and delete as in C++.

Aye, I don't recommend overloading `new` to mean something else. Currently `new` = GC allocation, and code can rely on that. Better to have such code break (by not defining _d_newclass) than silently leak or worse.

> Leaves dynamic arrays and the rest of Phobos (which parts?) which I have to forego if I don't like GC (but I do like slices so much, not much left for me to slice then ...). And no, anonymous, it's not just reallocating or appending to arrays, every dynamic array is allocated on the GC'd heap from the start.

Huh? You can slice any pointer:

---
T[] allocArray(T)(size_t num)
{
    if (auto chunk = cast(T*)calloc(num, T.sizeof))
        return chunk[0 .. num];
    else
        onOutOfMemoryError();
}
---

As well as fixed-length arrays:

---
char[128] buffer = ...;
auto myStackString = buffer[0 .. len];
---

Slices are plenty useful without GC.

Am 26.01.2014 03:03, schrieb Frank Bauer:
> On Saturday, 25 January 2014 at 23:02:44 UTC, anonymous wrote:
>> C doesn't have new/delete.
>
> Please read-before-write (non atomic operation): C has the *semantics*
> of new / delete with malloc and free. D has too, if you constrain
> yourself to memory allocation via std.c.stdlib.malloc and free, which
> means no object allocation with *new* anymore. We don't want to
> constrain ourselves to that, do we? What we want is malloc/free
> *semantics* throughout if we choose so.

Whose semantics are those?

Are you aware, that standard malloc/free vary a lot from compiler to compiler?

Even generating cascading allocations or deallocations, as they tend to use more low level APIs on from the operating system?

Anyone doing high performance computing or games with C ends up creating their own allocators anyway.

So I wonder what is this magic performance semantics from malloc/free.

--
Paulo

On Sunday, 26 January 2014 at 03:29:00 UTC, Andrei Alexandrescu wrote:

> GC is a language feature of D.

I hope what you mean is "automatic memory management is a feature of D".  I want to clarify my previous statements by saying automatic memory management is something that I find attractive in D, and something I hope to build in my runtime. But as a rude janitor that barges into the party, orders the band to stop playing and the dancers to stop moving so he can sweep the floor (i.e. GC) ... There must be a better way...and I hope some of you will help me find it.

Mike

On Sunday, 26 January 2014 at 02:03:29 UTC, Frank Bauer wrote:
> C has the *semantics* of new / delete with malloc and free. D has too, if you constrain yourself to memory allocation via std.c.stdlib.malloc and free, which means no object allocation with *new* anymore. We don't want to constrain ourselves to that, do we? What we want is malloc/free *semantics* throughout if we choose so.
[...]
> I'm aware that I can use a D subset that is roughly equivalent to C and C's standard library. This subset is precisely what I am *not* talking about. I am talking about all the great modern architectural features of D and Phobos.
>
>> Your points don't apply to D vs C.
>
> It does if I want to use D in its entirety not just its subset equivalent to C.
>
> So if I want C++ new/delete or Rust's owned pointer semantics I should constrain myself to D's subset that is equivalent to C and forget about Phobos altogether? Welcome to the *new* D.

Welcome to "D as a better C", not "D as a better 'better C' than
C++ and Rust". You might shed a tear for all the goodness you're
missing out on, but there's still templates, slicing, methods,
etc left.

On 2014-01-26 03:32, Frank Bauer wrote:

> I don't want to miss out on a single language feature of D. Where is
> that GC-free runtime?

Here it is: https://github.com/D-Programming-Language/druntime/blob/master/src/gcstub/gc.d

It implements the GC API using malloc. One needs to manually delete the memory with GC.free.

-- 
/Jacob Carlborg