Smart pointers instead of GC?
Paulo Pinto
pjmlp at progtools.org
Tue Feb 4 03:57:24 PST 2014
On Tuesday, 4 February 2014 at 11:13:03 UTC, Don wrote:
> On Tuesday, 4 February 2014 at 10:32:26 UTC, ed wrote:
>> 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.
>
> Yeah, I dunno what "systems language" means really.
For me it means you can write an OS with it, even if some tiny
parts require the use of Assembly glue.
--
Paulo
More information about the Digitalmars-d
mailing list