Smart pointers instead of GC?
ed
growlercab at gmail.com
Tue Feb 4 02:32:24 PST 2014
On Tuesday, 4 February 2014 at 09:59:07 UTC, Don wrote:
> On Tuesday, 4 February 2014 at 03:43:53 UTC, ed wrote:
>> On Tuesday, 4 February 2014 at 01:36:09 UTC, Adam Wilson wrote:
>>> On Mon, 03 Feb 2014 17:04:08 -0800, Manu
>>> <turkeyman at gmail.com> wrote:
>>>
>>>> On 4 February 2014 06:21, Adam Wilson <flyboynw at gmail.com>
>>>> wrote:
>>>>
>>>>> On Mon, 03 Feb 2014 12:02:29 -0800, Andrei Alexandrescu <
>>>>> SeeWebsiteForEmail at erdani.org> wrote:
>>>>>
>>>>> On 2/3/14, 6:57 AM, Frank Bauer wrote:
>>>>>>
>>>>>>> Anyone asking for the addition of ARC or owning pointers
>>>>>>> to D, gets
>>>>>>> pretty much ignored. The topic is "Smart pointers instead
>>>>>>> of GC?",
>>>>>>> remember? People here seem to be more interested in
>>>>>>> diverting to
>>>>>>> nullable, scope and GC optimization. Telling, indeed.
>>>>>>>
>>>>>>
>>>>>> I thought I made it clear that GC avoidance (which
>>>>>> includes considering
>>>>>> built-in reference counting) is a major focus of 2014.
>>>>>>
>>>>>> Andrei
>>>>>>
>>>>>>
>>>>> Andrei, I am sorry to report that anything other than
>>>>> complete removal of
>>>>> the GC and replacement with compiler generated ARC will be
>>>>> unacceptable to
>>>>> a certain, highly vocal, subset of D users. No arguments
>>>>> can be made to
>>>>> otherwise, regardless of validity. As far as they are
>>>>> concerned the
>>>>> discussion of ARC vs. GC is closed and decided. ARC is the
>>>>> only path
>>>>> forward to the bright and glorious future of D. ARC most
>>>>> efficiently solves
>>>>> all memory management problems ever encountered.
>>>>> Peer-Reviewed Research and
>>>>> the Scientific Method be damned! ALL HAIL ARC!
>
>>
>> Most of us know and understand the issues with ARC and that
>> with a GC. Many of us have seen how they play out in systems
>> level development. There is a good reason all serious driver
>> and embedded development is done in C/C++.
>>
>> A language is the compiler+std as one unit. If Phobos depends
>> on the GC, D depends on the GC. If Phobos isn't systems level
>> ready, D isn't systems level ready. I've heard arguments here
>> that you can turn off the GC, but that equates to rewriting
>> functions that already exists in Phobos and not using any
>> third-party library.
>
> At Sociomantic, that is exactly what we have done. Phobos is
> almost completely unusable at the present time.
>
> I personally don't think that ARC would make much difference.
> The problem is that *far* too much garbage is being created.
> And it's completely unnecessary in most cases.
>
> To take an extreme example, even a pauseless, perfect GC,
> wouldn't make std.json acceptable.
>
>
>> Why would anyone seriously consider that as an option?
>> Embedded C++ has std:: and third-party libraries where memory
>> is under control?
>>
>> Realistically D as a systems language isn't even at the hobby
>> stage.
>
> We're using D as a systems language on a global commercial
> scale. And no, we don't use malloc/free. We just don't use
> Phobos.
Maybe I'm thinking too much embedded, which I admit isn't fair on
D and at this stage maybe not a realistic comparison.
Our projects are Siemens medical devices so it is 90% embedded, a
different level of system perhaps. They too would be on a global
scale and I'd love to get D on them :-)
Cheers,
ed
More information about the Digitalmars-d
mailing list