However, I will dispute the claim that performance gains happen only at the hardware level - although programmers cannot really optimize every tiny bit, there is no harm in encouraging good programming.
Absolutely. Serious performance tuning is a difficult task, and it's foolish to attempt it without good information to work from, hence the usual recommendations to use profilers, disassemblers, etc. That doesn't mean a competent developer shouldn't be aware of the issues, and act on them if appropriate, though.
Actually, I think the article shot itself in the foot slightly, by undermining its own argument with its own information. Sure, the performance of its example application improved by around an order of magnitude using newer hardware. Sure, it was written in a language not designed for high performance work. But the example was a trivial manipulation of around 1GB of data, and the program was getting that done a whole 60 or so times in a second on a 3GHz beast? That's pathetic performance, and seems a pretty damn good argument that either low level hackery in something like C or assembler, or choosing a high level language with good performance like OCaml, are still the best ways to go if performance really matters.
The article also suggests that if you can do those 60 manipulations a second, you're up to modern video game standards. Somebody should mention to the author what's actually involved in rendering a state-of-the-art FPS, because it's a bit more than a trivial display of a graphic file every 1/60 of a second!:-) (Yeah, OK, everybody's got fancy accelerated graphics cards today, but still...)
Well, except for your wallet and your stress levels. Why spend all that money to buy a "state of the art" graphics card today, when something 12-18 months old could still give can't-tell-the-difference real-world performance at a fraction of the cost and with vastly more stability in drivers etc?
(Yes, I made the mistake, but only once. And I'm still waiting to find a game to challenge the card I bought on that occasion.)
(And no, I don't run games at 1600x1200 on my 19" Iiyama CRT, and neither does anyone else who values their eyesight. Theoretical FPS numbers don't mean anything to me; image quality and performance with the settings I'm actually going to use do.)
There's a gigantic danger for tech-heads who upgrade multiple times per year to be seriously out of touch with the consumer base at large.
It seems to me that the traditional upgrade cycle is now an anachronism. In the era of broadband Internet, it has become common practice for major software releases to be made at what used to be a mid-late beta stage. You then rely on numerous on-line patches to fix the screw-ups. This is a very significant difference to the old system where you released a product and then maybe a service pack (effectively what used to be called a minor release) was distributed via snail mail and magazine cover disks a few months later, with a large collection of fixes and minor improvements. That in turn is a far cry from the days when you released a pretty solid version of your product or your reputation suffered greatly and your competitors gained a commercial advantage as a result of your incompetence.
Unfortunately, I think all of this is a retrograde step. For a start, it shafts all the people who don't have broadband: do you have any idea how much time it would take to download all the "critical" fixes for a WinXP distribution over a 56k modem, and how much it would cost at 1p/min over dial-up? Moreover, it leads to a loss of quality and a raft of serious security and stability flaws in any new release. The old saying "Never buy version 1.0 of anything" still applies, even when it isn't called that any more.
What I don't understand is why, given the dominant position they have in the market and the negative feedback all the aforementioned security and stability flaws generate, Microsoft doesn't take a step back towards the "one big release" approach.
The world's busiest e-commerce websites are largely written in Java.
Actually, the last real data I saw (but note that this was some time ago) was that 7 of the 10 most visited web sites in the world ran on C++ back-ends. Sorry, no link off the top of my head, but IIRC there was some discussion of that statistic in these parts, so a search will probably turn it up. Do you have any more up-to-date information?
The results and strong entries for this competition are always an interesting read, so best of luck to everyone entering.
Just one niggle, though: last year, the first and second places were actually taken by entries using C++. I hope this year's proclamations won't suffer another unfortunate delay if the winner happens to be a non-functional language.
You can judge for yourself whether that pun was intended.:-)
But if you aren't willing to go get some of the easy certs how would I, as a hiring manager, know that you will really stretch yourself at my company.
Because he's smart enough not to waste his time and money on meaningless Mickey Mouse "qualifications"?;-)
I've seen a lot of resumes and everybody with a few years of experience can list lots of technologies, even if they don't really know them. You have to do something to prove you are different.
And here's the serious comment: you could start by listing how much experience you really have in each skill. A list of buzzwords is indeed fairly meaningless. A well-chosen list of buzzwords related to the job for which you're applying, divided into "strong", "working knowledge" and "some exposure", is much more informative.
If you've got the experience, it's hard to go wrong with giving a concise description of how much you've used a skill and how long ago, e.g., "Java (3 years, last used Sept 2003)". That's clearly more informative than "Java" on a resume, but still easy enough for someone to scan. If they're trying to get an overall picture of your skills and how useful they would be for the job you want (and any competent personel people will be doing that) then this should give them a good enough idea to know whether to shortlist you for interview or not.
No, sorry, it's not naive at all. At the end of the day, voters elect representatives, not corporations. Campaign contributions matter because they sway a disproportionate number of otherwise ambivalent voters. If those voters aren't ambivalent, it's a different game entirely.
Tell me, of those "hundreds of thousands of attempts" you mentioned, how many of you offered to donate the cost of 5 CDs to your local representatives in exchange for supporting your cause? For that matter, how many of you even wrote your representatives? Now tell me how many of you just bitched about how the world sucks on Slashdot, and resigned yourselves because you can't beat big business.
Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has. --
Margaret Mead
Think about it. If all reproducible works were GPL'd, then for most purposes copyright would be meaningless.
No, if all reproducible works were free-as-in-freedom, then copyright would be meaningless. Making software free-as-in-RMS requires copyright just as much as making non-free software, because it imposes artificial limitations on how the material may be used.
Using the word "freedom" to imply otherwise is just as disingenuous on the part of the FSF as claiming mass distribution of copyrighted works is "fair use" when you're not personally receiving money from it (but are profiting nonetheless), or using the deliberately inlammatory terms "software piracy" or "theft" to refer to such copyright infringement. All sides do it, but the debate would be more constructive if they didn't.
In reality many of us don't give a hoot about copyright. What we really want is free (as in speach) software.
Actually, IME, what most people around here want is free (as in beer) software. And music. And movies. And lunch. Arguments about monopoly abuse or free-as-in-speech are just convenient excuses to justify ripping people off and breaking the law.
The free-as-in-speech argument is genuine from a few people, including yourself I suspect, and I have nothing against it: as far as I'm concerned, you're the guys writing the stuff, so you can impose whatever conditions on its use you see fit. It is irritating when other people use it in a fairly pathetic attempt to cover their real motivation, though.
I think you've got the problem absolutely right. This is a direct consequence of two things: big media business abusing its monopoly, and a certain type of Joe Public breaking the law. In both cases, these are not good things, but they are done because the perps think they can get away with it.
As has often been said (but rarely heard) in these parts, the correct solution to this situation is to fix the problem, not to try to circumvent it by ever more devious means. The music industry should be compelled by the legal system to stop its price fixing practices, under the threat of having its business made seriously unprofitable by the courts. That will lead to reasonable competition in the market, and fairer prices and better distribution methods will naturally follow.
At the same time, I have no sympathy for the song-swappers who have been taking the piss for years because the tech was ahead of the law. You brought this upon yourselves. Copyright law is there for a reason. If you don't like the law, the solution is to seek to have it changed. If as many people agree with you as you think, that shouldn't be difficult, now should it? Of course, in this case, the widely-flouted law actually is reasonable, it's the failure of the authorities to enforce the flip-side of the law and smack the media outfits down that is causing the problem.
By carrying on with the current approach, all the oh-so-clever, we'll-just-use-encryption song swappers in this thread are simply inviting the inevitable: legislation to ban encryption in electronic transmissions, together with draconian enforcement rules and mandatory monitoring. This is a fight you cannot win. Wake up and start fighting the fight you can, or the world will be a worse place for your selfish actions.
OK, but at work the systems in question are not connected to the outside world, and the password is a formality (which, as it happens, I am contractually required to supply to anyone else working there who needs it anyway). On these systems, we could quite happily do without any passwords at all, and the fact that not only do I have to have one, but I am forced to waste time updating numerous systems according to their own pet rules to keep everything in sync is inexcusable.
That issue, together with the silly and prehistoric permissions/ownership system used by many *nix flavours, have collectively wasted nearly a man-day of the company's time (most mine, some for the sysadmins) in recent weeks, for absolutely no benefit whatsoever. Now, why was it that *nix knows better than us, again?:-)
One of those accounts I mentioned was a new credit card. The first time I tried to log in, I discovered that they'd already expired some details I'd only had for a few days, and I had to ring them up and get everything reset. To confirm my identity, the first question they asked after my name was "What's your memorable word?" I had no idea; it was a random thing I had to enter (amongst numerous other random things I had to enter) on a web site a month earlier, that I'd never used before in my life. Expecting someone to remember that sort of thing is just pointless, and since they have to check by some other means (e.g., confirming personal details) when you forget anyway, it does absolutely nothing to enhance security.
really? then i'd like to change to blank passwords.
If you want a blank password, that's your responsibility. Your OS has no business telling you you may not have one.
The sysadmin comment was a swipe at people who think they're being clever when they tell users they must use yet another creative collection of symbols. In fact, as any competent security professional can tell you, this can make systems much less secure (depending on other factors, obviously). Social engineering attacks, and simply reading passwords off something near a computer terminal, are way more common methods of gaining illegal access than dictionary cracks, and guess which two of these three become more likely when you enforce awkward-to-remember passwords?
Documentation to the contrary will simply be ignored, or get your ass tossed out on the street to avoid managerial embarrassment.
But you'll still be employable, as opposed to telling management you know better than them, which will get your ass tossed out onto the street whether or not the shit hits the fan, and with nothing but a lousy reference to show for it.
Because they care more about legal threats from multi-billion dollar megacorps than they do about Joe Freshman's "right" to illegally rip the latest Britney album?
I will turn in my badge the day the shit hits the fan and I will laugh the whole way home because I have documented, in hard copy, all of these "decisions".
And that's all you're expected to do. They have made a decision. If it contradicts your security advice, make sure they sign off on it. Now you've done your job, and can leave them to do theirs. If the shit hits the fan, that's the risk your management decided to take. If it doesn't, they made the right choice. Either way, the parent was right, and it's their choice to make.
Ironically, you're probably right. A combination of two real words, possibly with a random digit stuck in between them or replacing a letter or two, is one of the best choices for a password: it's far more memorable to most people than a random character string, but defeats your average dictionary attack.
I just moved all my financial stuff to one bank, for exactly two reasons. Firstly, the interest rates sucked where I was before. Mostly, I required four 4-digit PIN numbers, six 10+ digit ID numbers, three "memorable" words, and two more 6-digit code numbers, just to manage my darned money! (For anyone who's wondering, that's a budget and a current account at the bank, and the two credit cards I use occasionally -- just four "accounts".) Go ahead and tell me that's not silly. My new stuff will require one PIN, one numerical ID and one password in total, BTW.
I love people who think this sort of nonsense is actually good for security, as well, particularly those who force me to use something really cryptic for a password. Take UNIX, for example. Just the other week at work, I was trying to change my password on our office systems, of which there are many. Unfortunately, for the various inter-system logins to work without irritating me every few seconds, I need the same account name and password on all of the systems. That's wonderful when, after spending a silly amount of time updating these on several independent systems, I then find that one of the UNIX platforms thinks my new password is too like a dictionary word! I KNOW IT'S LIKE A DICTIONARY WORD, F***WIT, I CHOSE IT!
User interface rules 101: by all means offer unobtrusive advice, but the user is always right, and there should always be a "No, just do what I told you and shut up" option. No, you don't know better. And no, I don't care if you're the sysadmin.
The problem is that exceptions short-circuit the return path in non-obvious ways. Say we have a chain of functions a calling b calling c. c throws an exception. a catches it. Does b need to care?
No. If b needs to care, it should be catching (and possibly rethrowing) the exception itself. The RAII idiom in C++ evolved precisely to handle the situation where b needs to do action as a side effect of control leaving it, but without caring about the specifics of the exception causing that to happen.
It may be possible to do something scary with smart pointers and templates, but that is, as I said, scary.
No it's not, it's absolutely routine, and page 1 of the smart pointer manual. If you don't grok this, I can understand why you don't like exceptions, but that's an understanding/education issue, not a problem with the exception concept.
But in a garbage collected language, you don't have to worry about this sort of cleanup except in very rare cases, and it all works very nicely.
On the contrary, I think it's far more dangerous in a GC'd language. The most common problem of resource management amongst those who rely on GC is complacency: because they can't leak memory, they forget the basic principles of resource management, and consequently leak just about everything else. Most of the major GC'd languages in the family don't have deterministic destruction semantics, so RAII is out, and if you want timely resource release then now you have to write finally blocks everywhere. That is certainly not an improvement in either readability or robustness!
I define pass by reference to be exactly what pass by reference is in C++.
OK, then our disagreement is purely one of definitions. I was using "pass by reference" in the generic computer science/programming language theory sense, as the complement of "pass by value". That means that passing a reference and passing a pointer in C++ can both be used to achieve pass by reference semantics.
However, your original claim (if I understand it correctly) said there is no difference between passing by reference in C++, and passing pointers in C.
Not quite. I was describing how you achieve the effect generally known as "pass by reference" in C, not implying that C++'s references (which were never relevant) and pointers are the same thing.
True, the C++ STL has several of the features which are labeled "No" in the comparison. But it appears that one of the design objectives of D is to put features like arrays into the core of the language, rather that relying on some library.
OK. That's completely the opposite design philosophy to C++, but that's their choice. It's unhelpful to imply that C++ doesn't have those features, however. Any programmer writing in either C++ or D could use them routinely, so both columns should be ticked if it's going to be a useful comparison.
Unfortunately, you have to use the at member rather than operator[] to get the checked version; the latter isn't required to be bounds checked. That is a very unfortunate (and well acknowledged) design error: the safer version should have been the default.
Slashdot Mirror
Absolutely. Serious performance tuning is a difficult task, and it's foolish to attempt it without good information to work from, hence the usual recommendations to use profilers, disassemblers, etc. That doesn't mean a competent developer shouldn't be aware of the issues, and act on them if appropriate, though.
Actually, I think the article shot itself in the foot slightly, by undermining its own argument with its own information. Sure, the performance of its example application improved by around an order of magnitude using newer hardware. Sure, it was written in a language not designed for high performance work. But the example was a trivial manipulation of around 1GB of data, and the program was getting that done a whole 60 or so times in a second on a 3GHz beast? That's pathetic performance, and seems a pretty damn good argument that either low level hackery in something like C or assembler, or choosing a high level language with good performance like OCaml, are still the best ways to go if performance really matters.
The article also suggests that if you can do those 60 manipulations a second, you're up to modern video game standards. Somebody should mention to the author what's actually involved in rendering a state-of-the-art FPS, because it's a bit more than a trivial display of a graphic file every 1/60 of a second! :-) (Yeah, OK, everybody's got fancy accelerated graphics cards today, but still...)
Well, except for your wallet and your stress levels. Why spend all that money to buy a "state of the art" graphics card today, when something 12-18 months old could still give can't-tell-the-difference real-world performance at a fraction of the cost and with vastly more stability in drivers etc?
(Yes, I made the mistake, but only once. And I'm still waiting to find a game to challenge the card I bought on that occasion.)
(And no, I don't run games at 1600x1200 on my 19" Iiyama CRT, and neither does anyone else who values their eyesight. Theoretical FPS numbers don't mean anything to me; image quality and performance with the settings I'm actually going to use do.)
You don't; their Sales Director comes to you...
It seems to me that the traditional upgrade cycle is now an anachronism. In the era of broadband Internet, it has become common practice for major software releases to be made at what used to be a mid-late beta stage. You then rely on numerous on-line patches to fix the screw-ups. This is a very significant difference to the old system where you released a product and then maybe a service pack (effectively what used to be called a minor release) was distributed via snail mail and magazine cover disks a few months later, with a large collection of fixes and minor improvements. That in turn is a far cry from the days when you released a pretty solid version of your product or your reputation suffered greatly and your competitors gained a commercial advantage as a result of your incompetence.
Unfortunately, I think all of this is a retrograde step. For a start, it shafts all the people who don't have broadband: do you have any idea how much time it would take to download all the "critical" fixes for a WinXP distribution over a 56k modem, and how much it would cost at 1p/min over dial-up? Moreover, it leads to a loss of quality and a raft of serious security and stability flaws in any new release. The old saying "Never buy version 1.0 of anything" still applies, even when it isn't called that any more.
What I don't understand is why, given the dominant position they have in the market and the negative feedback all the aforementioned security and stability flaws generate, Microsoft doesn't take a step back towards the "one big release" approach.
Actually, the last real data I saw (but note that this was some time ago) was that 7 of the 10 most visited web sites in the world ran on C++ back-ends. Sorry, no link off the top of my head, but IIRC there was some discussion of that statistic in these parts, so a search will probably turn it up. Do you have any more up-to-date information?
The results and strong entries for this competition are always an interesting read, so best of luck to everyone entering.
Just one niggle, though: last year, the first and second places were actually taken by entries using C++. I hope this year's proclamations won't suffer another unfortunate delay if the winner happens to be a non-functional language.
You can judge for yourself whether that pun was intended. :-)
Because he's smart enough not to waste his time and money on meaningless Mickey Mouse "qualifications"? ;-)
And here's the serious comment: you could start by listing how much experience you really have in each skill. A list of buzzwords is indeed fairly meaningless. A well-chosen list of buzzwords related to the job for which you're applying, divided into "strong", "working knowledge" and "some exposure", is much more informative.
If you've got the experience, it's hard to go wrong with giving a concise description of how much you've used a skill and how long ago, e.g., "Java (3 years, last used Sept 2003)". That's clearly more informative than "Java" on a resume, but still easy enough for someone to scan. If they're trying to get an overall picture of your skills and how useful they would be for the job you want (and any competent personel people will be doing that) then this should give them a good enough idea to know whether to shortlist you for interview or not.
No, sorry, it's not naive at all. At the end of the day, voters elect representatives, not corporations. Campaign contributions matter because they sway a disproportionate number of otherwise ambivalent voters. If those voters aren't ambivalent, it's a different game entirely.
Tell me, of those "hundreds of thousands of attempts" you mentioned, how many of you offered to donate the cost of 5 CDs to your local representatives in exchange for supporting your cause? For that matter, how many of you even wrote your representatives? Now tell me how many of you just bitched about how the world sucks on Slashdot, and resigned yourselves because you can't beat big business.
No, if all reproducible works were free-as-in-freedom, then copyright would be meaningless. Making software free-as-in-RMS requires copyright just as much as making non-free software, because it imposes artificial limitations on how the material may be used.
Using the word "freedom" to imply otherwise is just as disingenuous on the part of the FSF as claiming mass distribution of copyrighted works is "fair use" when you're not personally receiving money from it (but are profiting nonetheless), or using the deliberately inlammatory terms "software piracy" or "theft" to refer to such copyright infringement. All sides do it, but the debate would be more constructive if they didn't.
Actually, IME, what most people around here want is free (as in beer) software. And music. And movies. And lunch. Arguments about monopoly abuse or free-as-in-speech are just convenient excuses to justify ripping people off and breaking the law.
The free-as-in-speech argument is genuine from a few people, including yourself I suspect, and I have nothing against it: as far as I'm concerned, you're the guys writing the stuff, so you can impose whatever conditions on its use you see fit. It is irritating when other people use it in a fairly pathetic attempt to cover their real motivation, though.
Yes, we are. Unfortunately I've already posted to this thread so I can't mod him back up, but I would have done otherwise.
And cos I'm such a nice guy, I'll even self-mod this down to 1 since it's off-topic.
I think you've got the problem absolutely right. This is a direct consequence of two things: big media business abusing its monopoly, and a certain type of Joe Public breaking the law. In both cases, these are not good things, but they are done because the perps think they can get away with it.
As has often been said (but rarely heard) in these parts, the correct solution to this situation is to fix the problem, not to try to circumvent it by ever more devious means. The music industry should be compelled by the legal system to stop its price fixing practices, under the threat of having its business made seriously unprofitable by the courts. That will lead to reasonable competition in the market, and fairer prices and better distribution methods will naturally follow.
At the same time, I have no sympathy for the song-swappers who have been taking the piss for years because the tech was ahead of the law. You brought this upon yourselves. Copyright law is there for a reason. If you don't like the law, the solution is to seek to have it changed. If as many people agree with you as you think, that shouldn't be difficult, now should it? Of course, in this case, the widely-flouted law actually is reasonable, it's the failure of the authorities to enforce the flip-side of the law and smack the media outfits down that is causing the problem.
By carrying on with the current approach, all the oh-so-clever, we'll-just-use-encryption song swappers in this thread are simply inviting the inevitable: legislation to ban encryption in electronic transmissions, together with draconian enforcement rules and mandatory monitoring. This is a fight you cannot win. Wake up and start fighting the fight you can, or the world will be a worse place for your selfish actions.
OK, but at work the systems in question are not connected to the outside world, and the password is a formality (which, as it happens, I am contractually required to supply to anyone else working there who needs it anyway). On these systems, we could quite happily do without any passwords at all, and the fact that not only do I have to have one, but I am forced to waste time updating numerous systems according to their own pet rules to keep everything in sync is inexcusable.
That issue, together with the silly and prehistoric permissions/ownership system used by many *nix flavours, have collectively wasted nearly a man-day of the company's time (most mine, some for the sysadmins) in recent weeks, for absolutely no benefit whatsoever. Now, why was it that *nix knows better than us, again? :-)
No offence, but I think you're missing the point.
One of those accounts I mentioned was a new credit card. The first time I tried to log in, I discovered that they'd already expired some details I'd only had for a few days, and I had to ring them up and get everything reset. To confirm my identity, the first question they asked after my name was "What's your memorable word?" I had no idea; it was a random thing I had to enter (amongst numerous other random things I had to enter) on a web site a month earlier, that I'd never used before in my life. Expecting someone to remember that sort of thing is just pointless, and since they have to check by some other means (e.g., confirming personal details) when you forget anyway, it does absolutely nothing to enhance security.
If you want a blank password, that's your responsibility. Your OS has no business telling you you may not have one.
The sysadmin comment was a swipe at people who think they're being clever when they tell users they must use yet another creative collection of symbols. In fact, as any competent security professional can tell you, this can make systems much less secure (depending on other factors, obviously). Social engineering attacks, and simply reading passwords off something near a computer terminal, are way more common methods of gaining illegal access than dictionary cracks, and guess which two of these three become more likely when you enforce awkward-to-remember passwords?
But you'll still be employable, as opposed to telling management you know better than them, which will get your ass tossed out onto the street whether or not the shit hits the fan, and with nothing but a lousy reference to show for it.
Because they care more about legal threats from multi-billion dollar megacorps than they do about Joe Freshman's "right" to illegally rip the latest Britney album?
And that's all you're expected to do. They have made a decision. If it contradicts your security advice, make sure they sign off on it. Now you've done your job, and can leave them to do theirs. If the shit hits the fan, that's the risk your management decided to take. If it doesn't, they made the right choice. Either way, the parent was right, and it's their choice to make.
Ironically, you're probably right. A combination of two real words, possibly with a random digit stuck in between them or replacing a letter or two, is one of the best choices for a password: it's far more memorable to most people than a random character string, but defeats your average dictionary attack.
I just moved all my financial stuff to one bank, for exactly two reasons. Firstly, the interest rates sucked where I was before. Mostly, I required four 4-digit PIN numbers, six 10+ digit ID numbers, three "memorable" words, and two more 6-digit code numbers, just to manage my darned money! (For anyone who's wondering, that's a budget and a current account at the bank, and the two credit cards I use occasionally -- just four "accounts".) Go ahead and tell me that's not silly. My new stuff will require one PIN, one numerical ID and one password in total, BTW.
I love people who think this sort of nonsense is actually good for security, as well, particularly those who force me to use something really cryptic for a password. Take UNIX, for example. Just the other week at work, I was trying to change my password on our office systems, of which there are many. Unfortunately, for the various inter-system logins to work without irritating me every few seconds, I need the same account name and password on all of the systems. That's wonderful when, after spending a silly amount of time updating these on several independent systems, I then find that one of the UNIX platforms thinks my new password is too like a dictionary word! I KNOW IT'S LIKE A DICTIONARY WORD, F***WIT, I CHOSE IT!
User interface rules 101: by all means offer unobtrusive advice, but the user is always right, and there should always be a "No, just do what I told you and shut up" option. No, you don't know better. And no, I don't care if you're the sysadmin.
No. If b needs to care, it should be catching (and possibly rethrowing) the exception itself. The RAII idiom in C++ evolved precisely to handle the situation where b needs to do action as a side effect of control leaving it, but without caring about the specifics of the exception causing that to happen.
No it's not, it's absolutely routine, and page 1 of the smart pointer manual. If you don't grok this, I can understand why you don't like exceptions, but that's an understanding/education issue, not a problem with the exception concept.
On the contrary, I think it's far more dangerous in a GC'd language. The most common problem of resource management amongst those who rely on GC is complacency: because they can't leak memory, they forget the basic principles of resource management, and consequently leak just about everything else. Most of the major GC'd languages in the family don't have deterministic destruction semantics, so RAII is out, and if you want timely resource release then now you have to write finally blocks everywhere. That is certainly not an improvement in either readability or robustness!
OK, then our disagreement is purely one of definitions. I was using "pass by reference" in the generic computer science/programming language theory sense, as the complement of "pass by value". That means that passing a reference and passing a pointer in C++ can both be used to achieve pass by reference semantics.
Not quite. I was describing how you achieve the effect generally known as "pass by reference" in C, not implying that C++'s references (which were never relevant) and pointers are the same thing.
FWIW, I very much doubt that.
OK. That's completely the opposite design philosophy to C++, but that's their choice. It's unhelpful to imply that C++ doesn't have those features, however. Any programmer writing in either C++ or D could use them routinely, so both columns should be ticked if it's going to be a useful comparison.
I imagine so, given that they do.
Unfortunately, you have to use the at member rather than operator[] to get the checked version; the latter isn't required to be bounds checked. That is a very unfortunate (and well acknowledged) design error: the safer version should have been the default.