Hacker News Reader

FTFA:

    I have observed someone do this: _myarr[5]={0}; – they had in the
    .h file the definition int _myarr[5] and they remembered that this
    thing could be initialized with {0} in other contexts. What they
    did wouldn't compile in C++98; in C++11 it promptly assigned the
    int 0 to the non-existent 5th element of _myarr, and the usual
    hilarity ensued. Imagine how PHP would be ridiculed for this kind
    of little behavior – and PHP at least would never overwrite an
    unrelated variable with garbage. Imagine how with C++, the poor
    programmer will be ridiculed instead.

Let me repeat that one more time,

    the poor programmer will be ridiculed instead.

From your response,

    (and you shouldn't be having char pointers for strings anyway)

     [...]

    experienced C++ programmers don't fall to that pit either

This is what the article is about, about what you are doing again. C++ is weird, it has a bunch of unusual behaviours, and when pointed, people who fall into those traps are the ones ridiculed, instead of the language.

I don't know if C++ could have been made less weird with the constraints that it had, as others have pointed out in this thread (C compatibility with no overhead). Perhaps it couldn't be. But this article is unhappy with the attitude of defending C++'s weirdness and then blaming the programmers for falling victims to this weirdness.

"Blame" is too strong of a word, but the basic idea is that C++ provides a lot of power that PHP doesn't provide, and the price for that power is complexity. So while both languages are full of dark little corners waiting to kill you, C++'s dark little corners are there because really smart people couldn't figure out how to avoid them in all cases while still keeping the mandated design requirements, and PHP's dark little corners appear to be there because no one bothered to think anything through before banging out an interpreter.

This isn't to say C++ is the best it could be. There are plenty of outright mistakes. But on the whole, C++ is weird and complicated because it had to be, at least to a much greater degree than PHP.

If you don't know even the most basic concepts of a language like using strings for strings that's a problem in every language. You can use an array of chars in PHP and access it by a reference and then compare pointers if you _really_ want to but you don't see people ranting on that.

In C++, the following:

  "Hello, World!"

…is a null terminated array of chars. When literal strings are not, in fact, strings, this is a problem with the language. It's confusing, you see? Underlying semantics nonwithstanding, how on Earth the followig works:

   (std::string)"foo" == "foo"

and the following may not?!

   "foo" == "foo"

These are not basic concepts. These are trivia. I know there are reasons for these confusing rules, but they're still confusing. You should not mock the programmer for forgetting them now and then.

Every language has quirks and issues - if you use raw char arrays like that in general purpose C++ without an extremely good reason that's not just forgetting and trivia that's a cultural issue.

Just like you wouldn't see Python code relying on mutable default values or JavaScript value relying on `with` semantics or Java code relying on `URL` comparison through DNS very often - you shouldn't find code that relies on `"foo" == "foo"`.

I'm sorry if my comments are harsh but I really do believe C++'s issues are mostly cultural.

So, accept the traps of the language as a fact of life, and just avoid them? No, that doesn't fly with me. Programming languages aren't Forces of Nature, they are human artefacts. They can be corrected.

Of course you should never rely on `"foo" == "foo"` and other such things. Still, one would expect literal strings in the language to be of the preferred string type. C++ is the only language I know of that breaks this expectation. It does not follow the principle of least astonishment. That, is not a cultural issue.

That said, I'm willing to accept that C++ do have cultural issues. Could you tell me what they are?

It isn't so much that you ridicule the programmer; it's a question of telling the programmer "don't use these things that you see mentioned in old books, we have replacements for them now."

So, yes, comparing char*s is very different than calling strcmp; and if you want to use "==" to compare strings (so you don't have to remember to call strcmp), then use std::string.

That isn't weird. At all. The language did precisely what the programmer asked it to. When you make a language operate closely to the metal, you can expect the syntax to be more abstruse. If this kind of mistake was possible in a higher level language, I would expect that to be a language pitfall.

"When you make a language operate closely to the metal, you can expect the syntax to be more abstruse"

It's the exact opposite. Close-to-the-metal, the syntax is actually very friendly - you've got values, and you can bash them in like a half-dozen ways. C is incredibly simple (I suppose their pointer syntax is a little janky, but one can always express it "one level at a time" via typedefs).

The really complicated parts come from making high-level operations seem "easy". There is no close-to-the-metal notion of char* vs a string, or a lvalue vs an rvalue, let alone template metaprogramming.

What I should have said was provide high level abstractions while still allowing low level operations. There is an impedance mismatch that the language needs to address. Languages like Rust can get away with this by not allowing the most low level operations that are deemed unsafe and so have a more user friendly api. C on the other hand, makes no attempts at make the abstraction so the syntax is just small by definition.

You really don't think that the semantics of foo[5] = {0} vs int foo[5] = {0} being completely different in C++11 is weird?

They read differently so why shouldn't they be different? One has a type specification so reads like a declaration. The other doesn't. This wasn't weird before C++11 too. The only difference is that one didn't compile before (prior to the introduction of initializer lists).

Wow, C++ apologists really are persistent.

> if you do silly things like use raw references you can still get screwed.. experienced C++ programmers don't fall to that pit either

Yes, they do. Empirically.

It was just an example. You're completely doing the double standard thing the OP is going on about. PHP and C++ are very comparable in how much they nearly encourage programmer mistakes, yet somehow in PHP it's the language's fault, and in C++ the programmer's just an idiot.

The tough one in C++'s case is that it isn't as easy as you think to critique the choices that were made. In most cases they are consequences of following design principles (and ones that seem good) through to the end (and you may disagree with the design principles, but then you probably shouldn't use the language). With PHP, that isn't the case and Rasmus would be the first person to tell you that.

> - In PHP you don't have resource management, the process kind of just dies and resources get deallocated.

We have long running PHP processes for months at a time (hey, code reuse) and they do not suffer memory leaks. Works great actually!

However, for desktop applications and short-lived processes, freeing app-level resources is pointless and only bad for performance. Why bother running through a destructor chain when you can keep your external data clean and just kill -9 the process? This is how iOS makes you work anyway.

> Why bother running through a destructor chain ...

The Gold linker (written in C++) doesn't ( http://www.airs.com/blog/archives/362 ): "[I]n the gold linker I often deliberately omitted destructors, because many of the data structures live for the life the program; in such a case, destructors serve only to slow down program exit."

However, there are some things that you really want to know happened when the process exits for any reason. If possible, you'd probably like your files closed in a way that allows them to be re-opened. That's easy to do with destructors. Destructors: they were always for more than just memory management.

> If possible, you'd probably like your files closed in a way that allows them to be re-opened. That's easy to do with destructors.

That doesn't help with data corruption coming from the environment. The power going off on your machine, your external drive, a crash in your process or an external signal all won't give you time to exit.

There are libraries worth relying on for this, like SQLite. It's not in C++.

This is a weird argument: "I just bought a Porsche, and it handles better than any car I've owned!"/"you can't tow things with a Porsche."

Anyhow, as you implicitly acknowledge, destructors help with orderly shutdown, even if the shutdown is caused by an error condition. I prefer them to try...finally that other languages rely on. I can live with C#'s IDisposable, but I personally have a better chance of getting my destructors right than implementing IDisposable correctly (remember, in a garbage collected language, you don't have a defined order that things will be destroyed in).

But, on the completely different topic of how to do disaster recovery when both your program and the host operating system are shut down in a non-orderly manner: I personally am not aware of any language features in any language that make that easier. However, I know it can be done in C++ (stasis ( http://stasis.io/ ), SQL Server, MySQL/MariaDB, Firebird ( http://firebirdsql.org/ ) and SciDB ( http://www.scidb.org/ ) are all implemented in C++, although they aren't all necessarily object oriented C++).

Also, PHP doesn't give you type safety. I have no idea why the article said that but that's just ridiculous.

The PHP runtime does know the types of all values at all times, though, in a way that the C++ runtime, insofar as it can be said to have one, does not. To call that type _safety_ is a little much even by the standards of dynamic languages, because PHP is so willing to do implicit type coercion, but _at runtime_ a PHP program is certainly more able to detect type errors than a C++ program.

Comparing PHP with C++ is just silly in the first place. Nobody is trying to seriously write a deferred renderer that can do global illumination in PHP.

Well, he describes the FQA as "an overly combative reply to Marshall Cline's fairly combative FAQ". He's not claiming impartiality.

But yes, it does look like he's gone very far out of his way to try to find things to complain about.