An exegesis of Walter's reference counted slice
Paulo Pinto via Digitalmars-d
digitalmars-d at puremagic.com
Tue Feb 24 13:46:53 PST 2015
On Tuesday, 24 February 2015 at 20:46:28 UTC, H. S. Teoh wrote:
> On Tue, Feb 24, 2015 at 08:21:53PM +0000, ketmar via
> Digitalmars-d wrote:
>> On Tue, 24 Feb 2015 20:11:17 +0000, weaselcat wrote:
>>
>> > On Tuesday, 24 February 2015 at 20:04:27 UTC, Andrei
>> > Alexandrescu wrote:
>> >> On 2/24/15 12:03 PM, weaselcat wrote:
>> >>> On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei
>> >>> Alexandrescu
>> >>> wrote:
>> >>>> ...
>> >>>
>> >>> Off-topic, sorry Are we still going to get a Trusted
>> >>> block, or
>> >>> just going to use trusted lambdas?(They're kind of ugly
>> >>> TBH)
>> >>
>> >> We're going to lambdas. Ugliness is a feature.
>> > Stroustrup would be proud ;)
>>
>> yet he made the whole language ugly, instead of making only
>> ugly
>> things ugly. ;-)
>
> Actually, it's worse than that. He made things that shouldn't
> be ugly,
> ugly, and things that *don't* look ugly are outright wrong.
>
> For example, naked pointers have built-in, convenient syntax.
> They are
> also extremely dangerous, and almost all C++ code containing raw
> pointers have bugs one way or another.
>
> For-loops have very nice syntax... except that unless you're
> writing the
> most inane, trivial loops, your code probably has bugs --
> off-by-1
> errors, wrong loop conditions, etc..
>
> Calling malloc/free is also easy... and your program probably
> has memory
> leak bugs too. Not to mention type-safety bugs if you're not
> careful
> about what you cast that void* into. But hey, writing:
>
> // Woohoo, bare pointer! Let's dance!
> void *p = malloc(1234);
>
> sure looks prettier than:
>
> // Repeat after me: Don't repeat yourself... don't repeat
> // yourself... don't repeat yourself...
> MyType *p = (MyType *)malloc(sizeof(MyType));
>
>
> Well, new/delete is prettier (as far as C++ goes anyway)... But
> wait,
> you still have memory leaks. Augh...
>
> And what about cleaning up resources after you're done with
> them?
>
> void func() {
> Resource *res = acquireResource();
> doStuff(res);
> freeResource(res);
> }
>
> Easy, right? Yeah, except that doStuff throws exceptions, so
> you have
> resource leakage. Solution? Write a long convoluted wrapper
> class with a
> dtor that cleans up. And a copy ctor that makes sure
> initializing one
> resource from another works correctly. And operator=() to make
> sure
> assignments work correctly. Oh but wait, your ctor is not
> exception-safe, so better rewrite *that* to use RAII too. Which
> means
> more copy ctors, more operator=()... oh wait, your copy ctor is
> not
> const-correct so it doesn't get called when you have a const
> object.
> Yeah, and your operator=() too. And ...
>
> After it's all said and done, what used to be a 3-line function
> has
> exploded into a monstrosity who knows how many lines long, with
> arcane
> incantations of auto_ptr<>, shared_ptr<>, and all that fancy
> stuff that
> no newbie ever has the hope of parsing, let alone understanding.
>
> http://bartoszmilewski.com/2013/09/19/edward-chands/
>
> Favorite quote:
>
> C++ has become an extremely complex language. There are
> countless ways of doing the same thing — almost all of them
> either plain wrong, dangerous, unmaintainable, or all of the
> above. The problem is that most code compiles and even runs.
> The
> mistakes and shortcomings are discovered much later, often
> after
> the product has been released.
>
> Yep, that's exactly why D has ruined my life, I just can't go
> back to
> that C++ garbage anymore.
>
>
> T
Almost all those warts are caused by the C compatibility and
affect also D to certain extent.
Any language that tries to achieve copy-paste compatibility with
C will suffer from it.
--
Paulo
More information about the Digitalmars-d
mailing list