Smart pointers instead of GC?

Adam Wilson flyboynw at gmail.com
Sat Feb 1 11:40:20 PST 2014


On Sat, 01 Feb 2014 06:33:15 -0800, Frank Bauer <x at y.com> wrote:

> On Saturday, 1 February 2014 at 09:27:18 UTC, Adam Wilson wrote:
>> For the vast majority of use cases, a GC is the right call and D has to  
>> cater to the majority if it wants to gain any significant mindshare at  
>> all. You don't grow by increasing specialization...
>
> So catering to the C++ crowd who shun Java and C# not so much for JITing  
> their code but precisely for their forced use of a GC is a "minority"  
> issue then? Again, please take those of us more serious who don't like a  
> GC to interfere with their business and if it's only for "programming  
> hygiene" reasons. As you consider handling low latency requirements  
> undue "specialisation" anyways.
>

Real-time or low-latency programming is absolutely specialization, and for  
more reasons than a GC. It might be what you do all day, but it's not what  
the majority of programmers do all day.

As far as catering to C++. TIOBE says that C++ made up 7.5% of programmer  
interest in January. Whereas Java+C# made up 22.4% of programmer interest.  
That's almost three-times the interest. Like it or not, C++ IS the  
minority and D's mission is not solely based on converting C++ users, many  
of whom can't convert anyways. The reason I picked those three languages  
is because they are D's primary audience.

> On Saturday, 1 February 2014 at 12:04:56 UTC, JR wrote:
>> To my uneducated eyes, an ARC collector does seem like the near-ideal  
>> solution
>
> ARC would be a plus for heavily interdependent code. But it doesn't beat  
> unique_ptr semantics in local use that free their memory immediately as  
> they go out of scope or are reassigned.
>

So you want C++ back then? Got it. But the goal of D is NOT to be a  
slightly better C++, it's a be a Safe, Simple, systems language with well  
defined semantics that just happens to trace it's lineage back to C++.

>> I would *dearly* love to have concurrency in whatever we end up with,  
>> though. For a multi-core personal computer threads are free lunches, or  
>> close enough so.
>
> No they are not. I want to make good use of all the cores I have  
> available and I don't want to share them a bit with the GC. It's myyy  
> ... precious.
>

Ahem. You only have the illusion of control over the CPU, the OS scheduler  
set's the rules, all you can do is provide hints. Giving some up to the GC  
will not materially affect the performance of the your code since you  
never had a choice anyways.

> As you may have guessed, my criticism is harsh because I love the  
> language :)


-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator


More information about the Digitalmars-d mailing list