On Thursday, 11 September 2014 at 16:02:31 UTC, Sean Kelly wrote:
> On Thursday, 11 September 2014 at 13:16:07 UTC, Marc Schütz wrote:
>> On Thursday, 11 September 2014 at 12:38:54 UTC, Andrey Lifanov wrote:

> hidden allocations anywhere.  And it's completely possible with Tango to write an application that doesn't allocate at all once things are up and running.  With Phobos... not so much.

Hi,

Could you provide one or two short but illustrative examples in Tango and Phobos showing the howto and the why not in Phobos?

Will Andrei's allocators improve that with some rewrite of Phobos?

Thanks.

On Thursday, 11 September 2014 at 16:02:31 UTC, Sean Kelly wrote:
> On Thursday, 11 September 2014 at 13:16:07 UTC, Marc Schütz wrote:
>> On Thursday, 11 September 2014 at 12:38:54 UTC, Andrey Lifanov wrote:
>>> Hello everyone! Being a C/C++ programmer I don't understand, why such language as D (system programming language) implemented garbage collector as a core feature, not as additional optional module or library.
>>
>> I can enlighten you ;-) The reason is safety. Past experience (especially with C & C++) has shown that manual memory management is easy to get wrong. Besides, certain features would not easily be possible without it (dynamic arrays, closures).
>
> GC is hugely important for concurrent programming as well.  Many of the more powerful techniques are basically impossible without garbage collection.

There is an interesting alternative that the Linux kernel uses,
called RCU (read-copy-update). They have a convention that
references to RCU managed data must not be held (= borrowed by
kernel threads as local pointers) across certain events,
especially context switches. Thus, when a thread modifies an RCU
data structure, say a linked list, and wants to remove an element
from it, it unlinks it and tells RCU to release the element's
memory "later". The RCU infrastructure will then release it once
all processors on the system have gone through a context switch,
at which point there is a guarantee that no thread can hold a
reference to it anymore.

But this is a very specialized solution and requires a lot
discipline, of course.

On Thursday, 11 September 2014 at 19:14:42 UTC, Marc Schütz wrote:
> On Thursday, 11 September 2014 at 16:02:31 UTC, Sean Kelly wrote:
>> On Thursday, 11 September 2014 at 13:16:07 UTC, Marc Schütz wrote:
>>> On Thursday, 11 September 2014 at 12:38:54 UTC, Andrey Lifanov wrote:
>>>> Hello everyone! Being a C/C++ programmer I don't understand, why such language as D (system programming language) implemented garbage collector as a core feature, not as additional optional module or library.
>>>
>>> I can enlighten you ;-) The reason is safety. Past experience (especially with C & C++) has shown that manual memory management is easy to get wrong. Besides, certain features would not easily be possible without it (dynamic arrays, closures).
>>
>> GC is hugely important for concurrent programming as well.  Many of the more powerful techniques are basically impossible without garbage collection.
>
> There is an interesting alternative that the Linux kernel uses,
> called RCU (read-copy-update). They have a convention that
> references to RCU managed data must not be held (= borrowed by
> kernel threads as local pointers) across certain events,
> especially context switches. Thus, when a thread modifies an RCU
> data structure, say a linked list, and wants to remove an element from it, it unlinks it and tells RCU to release the element's
> memory "later". The RCU infrastructure will then release it once
> all processors on the system have gone through a context switch,
> at which point there is a guarantee that no thread can hold a
> reference to it anymore.

Yes, RCU is one approach I was thinking of.  The mechanism that
detects when to collect the memory is basically a garbage
collector.

Am 11.09.2014 20:32, schrieb Daniel Alves:
> You know, currently I spend most of my time programming in ObjC, but I
> really love C, C++ and D.
>
> Since the Clang Compiler, ObjC dropped the GC entirely. Yes, that's
> right, no GC at all. And, in fact, it does support concurrent
> programming and everything else. ....


It is incredible how Objective-C's ARC became a symbol for reference counting, instead of the living proof of Apple's failure to produce
a working GC for Objective-C that didn't crash every couple of seconds.

Marketing is great!

--
Paulo

On Thursday, 11 September 2014 at 12:38:54 UTC, Andrey Lifanov
wrote:
> Hello everyone! Being a C/C++ programmer I don't understand, why such language as D (system programming language) implemented garbage collector as a core feature, not as additional optional module or library. I and many other C/C++ programmers prefer to control things manually and use flexible allocation schemes that suitable for concrete situations. When every nanosecond matters, this is the only option, at least nowadays.
>
> So this particular thing stops many of us from using D. When you can abandon performance, you usually choose Java (Scala) or C# because of their rich support and libraries. And the opposite matter is when you need high performance. In this case there is almost nothing to choose from. C/C++11 now looks not so bad.
>
> And I think of idea of complete extraction of GC from D. For this to achieve, I suppose, I have to dig deeply into D compiler and also correct/re-implement many things in modules, so this ends up with almost new version of D.
>
> I would like to hear your suggestions and some basic instructions. Maybe this is not a good idea at all or it will be very hard to realize.
>
> Thank you for your attention!

Dear C++ programmer. I know you language do not give a damn about
multicore, but it is a reality in the hardware for more than 10
years now.

As it turns out, outside being a convenience, a GC is capital for
multicore programming. Here are some of the reason:
  - Other memory management technique require bookkeeping. In a
multicore environment, that mean expensive synchronization.
  - It allow, combined with immutability, to get rid of the
concept of ownership. That mean data sharing without any sort of
synchronization once again. This is useful for multicore, but
even on a single core, D's immutable strings + slicing have
proven to be a killer feature for anything that is text
processing like.
  - This is an enabler for lock free data structures. As you don't
need to do memory management manually, your datastructure can
remain valid even with less operation, which generally makes it
easier to make those atomic/lock free.

It has other various benefits:
  - It removes a whole class of bugs (and memory corruption bug
tend to be not the easiest to debug).
  - It remove constraint from the original design. That mean you
can get a prototype working faster, and reduce time to market.
This is key for many companies. Obviously, it still mean that
you'll have to do memory management work if you want to make your
code fast and efficient, but this is now something you can
iterate on while you have a product working.

Now that do not mean GC is the alpha and omega of memory
management, but, as seen, it has great value. Right now, the
implementation is now super good, and it has been made a priority
recently. We also recognize that other technique have value, and
that is why the standard lib propose tool to do reference
counting (and it can do it better than C++ has it knows if
synchronization is necessary). There is important work done to
reduce memory allocation were it is not needed in the standard
lib, and @nogc will allow you to make sure some part of your code
do not rely on the GC.

Everyone tells about greatness and safety of GC, and that it is hard to live without it... But, I suppose, you all do know the one programming language in which 95% of AAA-quality popular desktop software and OS is written. And this language is C/C++.

How do you explain this? Just because we are stubborn and silly people, we use terrible old C++? No. The real answer: there is no alternative.

Stop telling fairy tales that there is not possible to program safe in C++. Every experienced programmer can easily handle parallel programming and memory management in C++. Yes, it requires certain work and knowledge, but it is possible, and many of us do it on the everyday basis (on my current work we use reference counting, though the overall quality of code is terrible, I must admit).

On Thu, 11 Sep 2014 20:55:42 +0000
Andrey Lifanov via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Everyone tells about greatness and safety of GC, and that it is hard to live without it... But, I suppose, you all do know the one programming language in which 95% of AAA-quality popular desktop software and OS is written. And this language is C/C++.
> 
> How do you explain this?
there were times when cool software was written in assembler language. and the real answer was: "there is no alternative".

stop telling fairy tales that it is easy to program safe in C++. but if you still want C++, i can give you some links where you can download free C++ compilers.

why switch to D and throwing out one of it's greatest features? as we told you, there *IS* the way to avoid GC if you want. did you read that messages? those about 'scoped' and other things? and about the things you'll lose if you don't want to use GC? did you noticed that you can mix GC and manual allocations (with some carefull coding, of course)?

you gave no use cases, yet insisting that GC is bad-bad-bad-bad. we told you that refcounting is a form of GC, and it's not that predictable as you believe, but you still talking about "no GC".

please, do you really want to learn or just trolling?

btw, i think that this whole thread belongs to 'D.learn'.

On Thursday, 11 September 2014 at 20:55:43 UTC, Andrey Lifanov wrote:
> Every experienced programmer can easily handle parallel programming and memory management in C++.

Eliminate "parallel programming" from that statement and I could be convinced to believe you, though after years of diagnosing bugs that almost invariably tied back to dangling pointer issues, even that would be a hard sell.  But even for programmers who really have this stuff down... how much of your code and your mental energy with C++ is spent on memory ownership rules?  Is it really a productive use of your time?  Does the program materially benefit from the design required to make it safe, correct, and self-documenting with respect to memory ownership and data lifetime?  Are smart pointers really that pleasant to work with?

On Thursday, 11 September 2014 at 20:55:43 UTC, Andrey Lifanov wrote:
> Everyone tells about greatness and safety of GC, and that it is hard to live without it... But, I suppose, you all do know the one programming language in which 95% of AAA-quality popular desktop software and OS is written. And this language is C/C++.
>
> How do you explain this? Just because we are stubborn and silly people, we use terrible old C++? No. The real answer: there is no alternative.
>
> Stop telling fairy tales that there is not possible to program safe in C++. Every experienced programmer can easily handle parallel programming and memory management in C++. Yes, it requires certain work and knowledge, but it is possible, and many of us do it on the everyday basis (on my current work we use reference counting, though the overall quality of code is terrible, I must admit).

You mean safe like openssl, gnutls or apple's one ?

On 11/09/14 21:02, eles wrote:

> Could you provide one or two short but illustrative examples in Tango
> and Phobos showing the howto and the why not in Phobos?

Tango:

import tango.text.Unicode;

void foo ()
{
    char[3] result; // pre-allocate buffer on the stack
    auto b = "foo".toUpper(result);
}

Phobos:

import std.uni;

void foo ()
{
    auto b = "foo".toUpper(); // no way to use a pre-allocated buffer
}

> Will Andrei's allocators improve that with some rewrite of Phobos?

Yes, they could.

-- 
/Jacob Carlborg