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
