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