W dniu 23.05.2013 20:13, Brad Anderson pisze:
> @nogc comes to mind (I believe Andrei mentioned it during one of the
> talks released). [1][2]
>
> 1: http://d.puremagic.com/issues/show_bug.cgi?id=5219
> 2: http://wiki.dlang.org/DIP18

When I started learning D 2 years ago, I read on the D webpage that D
allows manual memory management and it's possible to disable the GC. My
first thought was that standard library is written without using GC.
This could be kind of lowest common denominator solution to the
problem. Later, I found it was only my wishful thinking. So, you can
disable GC, but then you can't reliably use the standard library.

Lowest common denominator has its own weaknesses, mainly it sometimes
sacrifices performance, as some algorithms may perform better using
managed slices for example, than using manually managed memory.

nogc attribute could be used to not only block GC, it could be used to
select between GC and non-GC code with the help of the overloading
mechanism. So, the programmer instead of writing one function, would
actually write two functions, one for the GC and one for manual memory
management - only if they need separete code. This will surely double
the effort for some functions, but certainly not for the whole library.
Majority of code doesn't need separete functions, mainly because it's
non allocating code. But some, like containers would surely need these
two "branches".

It would be inconvenient to do twice the work when writing programs,
but I'm not so sure it is when writing a library. And this is just
because it's a _library_, usually written once and then reused. I think
that double effort is not that discouraging in this case.

So, I'd kindly suggest to at least think about this. I'm proposing that
nogc functions could be overloaded similarly to immutable/const
functions.

The other idea is to divide threads into two thread groups: managed and
unmanaged. This is like running two programs together, one written in
D, and one written in C++. If we can run managed and unmanaged
processes separately, why not run two analogous "subprocesses" inside
one process. nogc could help with that.

Obviously, such thread groups must NOT share any mutable data. They
could communicate with some sort of IPC, or perhaps ITC -
std.concurrency comes to mind.

This kind of separation _inside one process_ could help many
applications. Imagine real time sound application, with managed GUI and
unmanaged real time sound loop. I know, everything is possible now, but
I'd rather wait for a safe and clean solution - the one in the D style:)

On Thursday, 23 May 2013 at 18:13:17 UTC, Brad Anderson wrote:
> There was a lot of interesting stuff in Benjamin Thaut's article about GC versus manual memory management in a game [4] and the discussion about it on the forums [5].  A lot of this collective knowledge built up on manual memory management techniques specific to D should probably be formalized and added to the official documentation.  There is a Memory Management [6] page in the documentation but it appears to be rather dated at this point and not particularly applicable to modern D2 (no mention of emplace or scoped and it talks about using delete and scope classes).
>
> Game development is one place D can really get a foothold but all too often the GC is held over D's head because people taking their first look at D don't know how to avoid using it and often don't realize you can avoid using it entirely. This is easily the most common issue raised by newcomers to D with a C or C++ background that I see in the #d IRC channel (many of which are interested in game dev but concerned the GC will kill their game's performance).

I think that Phobos should have some support for manual memory management. I don't mean clearing out the gc usage there, as it's fairly obvious. I rather think about something like unique_ptr/shared_ptr in the std. I think unique_ptr can't be implemented without rval refs, also C++ sollutions may not fit here. Anyways, now it's not so straightforward how to live without gc so standard sollution would be really helpful.

Also, it should be visible in C++/D that D can really deal with manual memory management conveniently - when I checked out Dlang first time I felt very disappointed that "delete" operator is deprecated. "So - they advertise one can code without GC, yet they seem to deprecate the operator" - false claims discourage people from using new languages.

On Thu, 23 May 2013 21:37:26 +0200
"Kiith-Sa" <kiithsacmp@gmail.com> wrote:

> On Thursday, 23 May 2013 at 18:13:17 UTC, Brad Anderson wrote:
> > While there hasn't been anything official, I think it's a safe bet to say that D is being used for a major title, Remedy's Quantum Break, featured prominently during the announcement of Xbox One. Quantum Break doesn't come out until 2014 so the timeline seems about right (Remedy doesn't appear to work on more than one game at a time from what I can tell).
> >
> >
> > That's pretty huge news.
> >
> >
> > Now I'm wondering what can be done to foster this newly acquired credibility in games.  By far the biggest issue I hear about when it comes to people working on games in D is the garbage collector.  You can work around the GC without too much difficulty as Manu's experience shared in his DConf talk shows but a lot of people new to D don't know how to do that.  We could also use some tools and guides to help people identify and avoid GC use when necessary.
> >
> > @nogc comes to mind (I believe Andrei mentioned it during one of the talks released). [1][2]
> >
> > Johannes Pfau's work in progress -vgc command line option [3] would be another great tool that would help people identify GC allocations.  This or something similar could also be used to document throughout phobos when GC allocations can happen (and help eliminate it where it makes sense to).
> >
> > There was a lot of interesting stuff in Benjamin Thaut's article about GC versus manual memory management in a game [4] and the discussion about it on the forums [5].  A lot of this collective knowledge built up on manual memory management techniques specific to D should probably be formalized and added to the official documentation.  There is a Memory Management [6] page in the documentation but it appears to be rather dated at this point and not particularly applicable to modern D2 (no mention of emplace or scoped and it talks about using delete and scope classes).
> >
> > Game development is one place D can really get a foothold but all too often the GC is held over D's head because people taking their first look at D don't know how to avoid using it and often don't realize you can avoid using it entirely. This is easily the most common issue raised by newcomers to D with a C or C++ background that I see in the #d IRC channel (many of which are interested in game dev but concerned the GC will kill their game's performance).
> >
> >
> > 1: http://d.puremagic.com/issues/show_bug.cgi?id=5219
> > 2: http://wiki.dlang.org/DIP18
> > 3: https://github.com/D-Programming-Language/dmd/pull/1886
> > 4: http://3d.benjamin-thaut.de/?p=20#more-20
> > 5: http://forum.dlang.org/post/k27bh7$t7f$1@digitalmars.com
> > 6: http://dlang.org/memory.html
> 
> 
> Without official confirmation, I think it's rather early to
> assume D's
> being used in Quantum Break. D might compile on the new consoles,
> but
> what about druntime/phobos/etc ?
> 

I'd like to hear an official confirmation (or denial) at this point,
too (assuming Remedy is at a point where they're comfortable making a
statement on the matter - and after all, it would make sense if
they're still keeping open the possibility of backing out of D for
whatever they're using it on by release if they end up needing to do so,
even if such a possibility is very unlikely).

However, I do think it's a safe bet: Like Brad said, Remedy is a
relatively small dev company that doesn't have a history of working on
multiple AAA titles simultaneously. They *are* known to have one other
mystery title besides Quantum Break in development, but it's for iOS -
so it's not a AAA title, and it's definitely not x86, so that one can
definitely be ruled out (unless Manu was messing with us to keep
it super-secret ;) ).

As far as I'm concerned, the whole "Quantum Break uses D" thing *is* technically a rumor, and I think it's probably best to keep it framed that way out of respect for Manu and his employer. But it's a very convincing rumor that I do believe.

On Thu, 23 May 2013 16:02:05 -0400, QAston <qaston@gmail.com> wrote:

> Also, it should be visible in C++/D that D can really deal with manual memory management conveniently - when I checked out Dlang first time I felt very disappointed that "delete" operator is deprecated. "So - they advertise one can code without GC, yet they seem to deprecate the operator" - false claims discourage people from using new languages.

While I'm not specifically addressing the ability or not to disable the GC (I agree D has problems tehre), deprecating the delete operator does NOT preclude manual memory management.

The problem with delete is it conflates destruction with deallocation.  Yes, when you deallocate, you want to destroy, but manual deallocation is a very dangerous operation.  Most of the time, you want to destroy WITHOUT deallocating (this is for cases where you are relying on the GC).

Then I think Andrei also had a gripe that D had a whole keyword dedicated to an unsafe operation.

You can still destroy and deallocate with destroy() and GC.free().

-Steve

On Thursday, May 23, 2013 21:37:26 Kiith-Sa wrote:
> It'd be good to have an easy-to-use way to manually allocate classes/structs in Phobos (higher-level than emplace, something close in usability to C++ new/delete), preferably with a way to override the allocation mechanism (I assume the fabled "allocators" have something to do with this? Maybe we'll get them once DNF is released... ... ...)'

Presumably, we'll get that with custom allocators. So, it's probably just a question of how long it'll take to sort those out.

- Jonathan M Davis

On Thursday, 23 May 2013 at 20:07:08 UTC, Steven Schveighoffer wrote:
> While I'm not specifically addressing the ability or not to disable the GC (I agree D has problems tehre), deprecating the delete operator does NOT preclude manual memory management.
>
> The problem with delete is it conflates destruction with deallocation.  Yes, when you deallocate, you want to destroy, but manual deallocation is a very dangerous operation.  Most of the time, you want to destroy WITHOUT deallocating (this is for cases where you are relying on the GC).
>
> Then I think Andrei also had a gripe that D had a whole keyword dedicated to an unsafe operation.
>
> You can still destroy and deallocate with destroy() and GC.free().
>
> -Steve

Yes, I know the rationale behind deprecating delete and i agree with it. But from newcomer's point of view this looks misleading - not everyone has enough patience (or hatered towards c++) to lurk inside mailing lists and official website shows the deprecated way of doing things: http://dlang.org/memory.html . IMO manual memory management howto should be in a visible place - to dispell the myths language suffers from. Maybe even place in to the malloc-howto in Efficency paragraph of main website.

On Thursday, 23 May 2013 at 20:15:51 UTC, QAston wrote:
> Maybe even place in to the malloc-howto in Efficency paragraph of main website.

Sorry, should be:
Maybe even place the malloc-howto in Efficency paragraph of main website.

On Thu, May 23, 2013 at 10:15:50PM +0200, QAston wrote:
> On Thursday, 23 May 2013 at 20:07:08 UTC, Steven Schveighoffer wrote:
> >While I'm not specifically addressing the ability or not to disable the GC (I agree D has problems tehre), deprecating the delete operator does NOT preclude manual memory management.
> >
> >The problem with delete is it conflates destruction with deallocation.  Yes, when you deallocate, you want to destroy, but manual deallocation is a very dangerous operation.  Most of the time, you want to destroy WITHOUT deallocating (this is for cases where you are relying on the GC).
> >
> >Then I think Andrei also had a gripe that D had a whole keyword dedicated to an unsafe operation.
> >
> >You can still destroy and deallocate with destroy() and GC.free().
> >
> >-Steve
> 
> Yes, I know the rationale behind deprecating delete and i agree with it. But from newcomer's point of view this looks misleading - not everyone has enough patience (or hatered towards c++) to lurk inside mailing lists and official website shows the deprecated way of doing things: http://dlang.org/memory.html . IMO manual memory management howto should be in a visible place - to dispell the myths language suffers from. Maybe even place in to the malloc-howto in Efficency paragraph of main website.

Please file a bug on the bugtracker to update memory.html to reflect current usage. Misleading (or outdated) documentation is often worse than no documentation.


T

-- 
Lawyer: (n.) An innocence-vending machine, the effectiveness of which depends on how much money is inserted.

On Thursday, 23 May 2013 at 20:02:06 UTC, QAston wrote:
> I think that Phobos should have some support for manual memory management. I don't mean clearing out the gc usage there, as it's fairly obvious. I rather think about something like unique_ptr/shared_ptr in the std. I think unique_ptr can't be implemented without rval refs, also C++ sollutions may not fit here. Anyways, now it's not so straightforward how to live without gc so standard sollution would be really helpful.

There is std.typecons.Unique and std.typecons.RefCounted.  Unique is more cumbersome than unique_ptr but it should work though I've never tried to use it.  Proper rvalue references would be a nice improvement here.

RefCounted doesn't support classes yet simply because nobody has taken the time to add support for them.

It'd be nice to just be able to say shared_ptr = RefCounted, unique_ptr = Unique when somebody asks about smart pointers in D though.

std.typecons.scoped is also useful but a bit buggy/cumbersome.  jA_cOp (IRC handle) is working on improving it.  Manu tried his hand at implementing his own version for fun (which came up because we were engaged in yet another GC argument with someone coming from C++).

23-May-2013 22:13, Brad Anderson пишет:
> While there hasn't been anything official, I think it's a safe bet to
> say that D is being used for a major title, Remedy's Quantum Break,
> featured prominently during the announcement of Xbox One. Quantum Break
> doesn't come out until 2014 so the timeline seems about right (Remedy
> doesn't appear to work on more than one game at a time from what I can
> tell).
>
> Now I'm wondering what can be done to foster this newly acquired
> credibility in games.  By far the biggest issue I hear about when it
> comes to people working on games in D is the garbage collector.  You can
> work around the GC without too much difficulty as Manu's experience
> shared in his DConf talk shows but a lot of people new to D don't know
> how to do that.  We could also use some tools and guides to help people
> identify and avoid GC use when necessary.
>
> @nogc comes to mind (I believe Andrei mentioned it during one of the
> talks released). [1][2]

I have simple and future proof proposal:

1. Acknowledge how containers would look like (API level is fine, and std.container has it). Postpone allocator or consider them be backed into container.

2. Then for any function that has to allocate something (array typically) add a compile-time parameter - container to use. Obviously there has to be a constraint on what kind of operations it must provide.

3. std.algorithm and std.range become usable. We then can extend this policy beyond.

Some examples to boot:

1. std.array.array - incredibly nice tool, turns any range into array.
Let's make a construct function that does the same for any container:
auto arr = array(iota(0, 10).map....)
--->
auto arr = construct!(Array!int)(iota(0, 10).map...)

by repeatedly calling insertAny in general, and doing better things depending on the primitives available (like reserving space beforehand for array-like types).

BTW users can use alias FTW:
alias toArray = construct!(Array!int); // Yay!

2. schwartzSort - allocates array internally. We just need to pass it the right replacement type for array. schwartzSort!(Array!int)(...) - no GC required now. Ditto for levenshteinDistance etc.

There could be some limitations on how far such approach can go with introducing new overloads. Alternative is new functions with some suffix/prefix.
-- 
Dmitry Olshansky