Ooh... inspiration has struck....

Create filtering proxy that converts all of the text into images of the text, and converts all of the images into html tables where each pixel in the image is a 1x1 cell of with the background color set to the appropriate color.

Hehe... evil I know.

IMDB has a technique where they use CSS positioning to place a scaled 1x1 transparent gif over their photos so that right-clicking and doing a save-as saves the 1x1 gif.

Of course this does nothing to stop knowledgeable users.

Returning a reference to a local object in Java is perfectly valid and is done all the time.  So I would expect to have to break that habit for  people moving form Java to C++, other than that though I'd be surprised to see other programmers screw it up too often.

Maybe I'm too optimistic.

Personally, I prefer to only use const references.  If I'm going to modify a value I'll pass it in as a pointer, that way it's obvious in the calling code without having to look up the declaration.  Consider:

foo(bar);

 vs.

 foo(&bar);

 the &bar is a tip-off that foo is modifying bar.

@JvdL said:

@asuffield said:

You don't have what it takes to be a software developer.

@Mikademus said:

You just seem like an ass with anger issues [...] Ass-u-field

@bstorer said:

Your recent MO of posting smug invectives seems misguided at best.

@fist-poster said:

You don't understand references [...] You've degenerated into less than a troll

This starts to look like a pissing contest.

To Mikademus, bstorer, fist-poster:
Asuffield is right: references are not safer than pointers and are primarily syntactic sugar that sometimes (operator overloading) makes your code easier to read, but often merely obfuscates it. Compilers will only protect from blatant typos, if at all. If you don't believe him or me, read second opinions by Bjaerne Stroustrup or Dan Saks.

Don't try to beat asuffield on his home ground: he knows more about this stuff than all of us put together.

To asuffield:
You'll stand a better chance that people will listen to you if you wouldn't start your rethoric with insults.

From Stroustrup's page that was linked:

If passing ``not an object'' (e.g. a null pointer) is acceptable, using a pointer makes sense. My personal style is to use a pointer when I want to modify an object because in some contexts that makes it easier to spot that a modification is possible.

I've bolded the relevant portion.  The implication is that in all other situations using a pointer does *not* make sense, or equivalently:  If passing "not an object" (e.g. a null pointer) is *NOT* acceptable, using a reference makes sense. 

That's because a reference *must* refer to an object.  Yes you can go out of your way to make that object invalid, but there is little a programming language can do to prevent willful stupidity.  So instead the focus is on preventing accidental errors, something which references do quite admirably.

@asuffield said:

Preventing SQL injection via escaping is a fundamentally braindamaged approach. You have one piece of code that interprets the query, and another piece of code that predicts how the first one will interpret the query, and modifies the query to stop it from doing that. Unless you can manage to keep the two perfectly in sync, you have security holes. The chances of getting this right are very slim. Historically they have done a very bad job of getting it right, and there's no particular reason to think that it's any better now.

The correct method is to stop passing the query as a flat string, and segregate the tainted data from the executable code properly. All the important databases (and mysql) implement this using parameter marks in prepared queries. All the major languages except PHP support (and very strongly recommend that you use) this. Yes, other C applications that were as braindamaged as PHP would also suffer from this flaw - but most major ones are not this poorly designed.

The last time I looked at the C-API (admittedly years ago) there was no support for parameterized queries.  You had to use the escape functions.  Everything was returned as a string, so if you selected a number, you had to convert it from a string to a number yourself after you got it back from the database.  Unless I just completely misread the API documentation.

 Dave