U++ Core vs D programming language

[janderson]

Brad Roberts wrote:
> Georg Wrede wrote:
>> Jason House wrote:
>>> Poking around the U++ web site, I spotted this page:
>>> http://www.ultimatepp.org/www$uppweb$vsd$en-us.html
>>>
>>> It says "C++ is still well ahead of D (by 70%) if not being hold back
>>> by standard library design and average implementation..."
>> http://www.ultimatepp.org/www$uppweb$overview$en-us.html
>> says:
>>
>>> Everything belongs somewhere
>>>
>>> In Ultimate++, most objects are bound to some logical scope. As a
>>> result, you will not see many new operators in code using Ultimate++
>>> and almost no delete operators outside the implementation of
>>> containers.
>>>
>>> That of course does not mean you are not allowed to use pointers, but
>>> it is good practice to use pointers just to point to things, never to
>>> manage heap resources. This also avoids all confusion regarding
>>> ownership of the underlying object, time of its deletion etc. If you
>>> need to manage data sets of variable size or polymorphic type, you
>>> should prefer using one of Ultimate++ containers.
>>>
>>> Speaking about it, there are no shared smart pointers (like
>>> boost::shared_ptr) in Ultimate++ used to manage heap resources at
>>> interface level. They are not needed and considered bad practice.
> 
> That's certainly _a_ philosophy.  If it happens to work well enough for
> your app, then it's a very valid way of doing things.  But often that's
> much more easily said than done.
> 
>> And here comes the point:
>>
>>> In C++, this approach proves to be equally good or better than
>>> garbage collected languages like Java or C#. While those languages
>>> are able to provide automatic management of heap resources, U++
>>> approach provides very deterministic automatic management of all
>>> resources.
>> What should I tell people who quote the last paragraph?
> 
> I'd challenge the original premise.  The assumption is that every
> application can be managed by static allocations on the stack and that
> it's sufficiently easy to do so that no other technique need be used.
> If that's true, then ok, every other technique is useless and almost
> certainly slower.  I have a very hard time believing that.
> 
> Next, if you can't use pure scope based allocations, then there are
> different tradeoffs between RAII, refcounting, and various garbage
> collection schemes.  The exact runtime performances vary depending on
> usage and exact implementation.  It's impossible to make absolute X is
> better than Y withouut loads of qualifications (that make them
> non-absolute :).
> 
> Later,
> Brad


I agree.  I would like to see how U++ performs when programs get larger 
and program size starts becoming a bottleneck.

-Joel