4 ms·

This is a very interesting read but it's full of FUD. You'd expect `==` to work in PHP because it compares value. With a char* reference the syntax and everyth

by inglor 12y ago

This is a very interesting read but it's full of FUD. You'd expect `==` to work in PHP because it compares value. With a char* reference the syntax and everything around it indicates that you're working with well... pointers (and you shouldn't be having char pointers for strings anyway). Don't even mention PHP references etc. C++ still has a lot of going for it - no one thinks it's terribly great and awesome - but the reason people ridicule PHP and admire C++ is that it solves a much bigger problem. - In PHP you don't have resource management, the process kind of just dies and resources get deallocated. In C++ that's not acceptable for perfomance. - In PHP you have memory safety - oh wait you really don't, if you do silly things like use raw references you can still get screwed.. experienced C++ programmers don't fall to that pit either. - In PHP you don't have to explicitly deal with memory which is again because you're solving a much easier problem. When your whole world is an immutable page request response cycle life is rainbows and sunshine. Comparing languages is always ridiculous and populistic but that comparison was just bonkers. Not that C++ doesn't have quirks - it sure does, but comparing it to PHP is just silly. (Not saying anything about PHP being a bad or good language here, just that the comparison is ridiculous)

inglor 12y ago
Also, PHP doesn't give you type safety. I have no idea why the article said that but that's just ridiculous.
- banachtarski 12y ago
  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.
- saucetenuto 12y ago
  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.
deleted 12y ago
[deleted]
astrange 12y ago
> - 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.
- maxlybbert 12y ago
  > Why bother running through a destructor chain ... The Gold linker (written in C++) doesn't ( http://www.airs.com/blog/archives/362 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.
  - astrange 12y ago
    > 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++.
    - maxlybbert 12y ago
      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/ http://stasis.io/ ), SQL Server, MySQL/MariaDB, Firebird ( http://firebirdsql.org/ http://firebirdsql.org/ ) and SciDB ( http://www.scidb.org/ http://www.scidb.org/ ) are all implemented in C++, although they aren't all necessarily object oriented C++).
pcwalton 12y ago
> 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.
AnimalMuppet 12y ago
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.
skrebbel 12y ago
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.
- cbsmith 12y ago
  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.
jordigh 12y ago
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.
- maxlybbert 12y ago
  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.
- deong 12y ago
  "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.

by inglor 12y ago

inglor 12y ago

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

banachtarski 12y ago
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.
saucetenuto 12y ago
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.

deleted 12y ago

[deleted]

astrange 12y ago

> - 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.

maxlybbert 12y ago
> Why bother running through a destructor chain ... The Gold linker (written in C++) doesn't ( http://www.airs.com/blog/archives/362 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.
- astrange 12y ago
  > 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++.
  - maxlybbert 12y ago
    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/ http://stasis.io/ ), SQL Server, MySQL/MariaDB, Firebird ( http://firebirdsql.org/ http://firebirdsql.org/ ) and SciDB ( http://www.scidb.org/ http://www.scidb.org/ ) are all implemented in C++, although they aren't all necessarily object oriented C++).

pcwalton 12y ago

> 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.

AnimalMuppet 12y ago

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.

skrebbel 12y ago

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.

cbsmith 12y ago
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.

jordigh 12y ago

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.

maxlybbert 12y ago
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.
deong 12y ago
"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.