Slashdot Mirror

Its not so much that people drive too slow, its that people like to ride their brakes, or brake for stupid fender benders on the side of the road. Try this little applet out for size to see the effects of it.

Gawkers should have their driving privileges revoked.

I carry a Coghlan magnesium fire starter, a Swiss Army knife, and a folding comb in my pocket at all times, without any problems. Each of these items is larger than the drive in question. The key, is to put it in your front pocket. You will never sit on it that way.

C++ is a tremendously type safe language.

I can't stop laughing about that sentence. Like another comment said, have a look at ML to see what is a language with a safe type system.

You can't expect to have any reasonable type safety when keeping so much compatibility with C. The changes between C and C++ about the typing rules for basic types was made with performance improvement in mind, not safety. They added a bool type to C++, which might be considered a step toward type safety. But they allow bool and int to be implicitely cast one into the other. They did not want to break all the idiomatic constructions of C you usually find in clauses like:

int i;
[...]
if(i) ...

The best illustration of that is an example I found in the famous c++ pitfalls at http://www.horstmann.com/cpp/pitfalls.html. Look for the example that starts with "The stream classes support a type conversion basic_ios "

And I'm not talking about the other implicit conversions like the one from int to float (already made in other comments) with all the nifty interactions it has with overloading, inheritance, whatever...

#include <iostream>

int main(int argc, char **argv)
{
int z = 5;
if(1 <= z <= 3){
std::cout << "I love Stroustroup\n";
}
else{
std::cout << "I hate Stroustroup\n";
}
}

• The STL makes no guarantees that it checks for errors (bounds checking, using a pointer into the wrong collection, etc.), and it is designed in such a way that error checking is quite costly. (Note that there have been a couple of attempts at making a safe STL; see here; it is unacceptable that this isn't part of the standard and isn't used by default).
• It's hard to predict whether any particular data structure or algorithm is going to be fast. Sure, it makes asymptotic guarantees, but everybody does that; it's the constants that matter.
• The library is too complex for most needs, and you can't easily just use "a little bit" of it. If you want to write efficient code using STL, you have to understand it pretty well.
• STL's complex semantics also make thread safety hard to guarantee.

The STL wasn't adopted because the committee liked it tremendously, it was adopted by default: it was the only serious proposal for collection classes for C++ that the committee had, and C++ needed collection classes in order to pass as a standard. I think what C++ should have gotten was a simple template array class, list class, and hash table class, with excellent error checking. IMO, STL has greatly damaged the C++ language.

How can you live with the C++ STL? Your best bet is to pick a small, simple subset of concrete STL datatypes and operations (vector, stack, and map) and stick to those in your interfaces and most of your code. You can implement your own, safe and efficient versions of those for development and internal use and use the standard STL versions when you ship library code. Forget about iterators: they are a mess to debug. And use the STL algorithms only if you don't care about performance.

Note that I have nothing against generic programming: generic programming is an old and well-established idea (and predates Stepanov and Lee by many years). C++ is just not a good language to push it to the extremes that STL pushes it.

FWIW, I don't know if he's the author, but I first saw that "March of Progress" bit at Cay Horstmann's site.

A Traffic Simulator Applet written by Cay Horstmann

Language choice tends to be a religious issue for some, but after you've learned ten or twenty programming languages, your view becomes more objective.

Pascal tanked for a number of reasons. One reason was ISO standardization of what was essentially Wirth's original version, which was terribly limited. ISO Pascal doesn't scale well; separate compilation and header files weren't standardized. Nor was an I/O system that could handle errors. So everybody's implementation extended Pascal, incompatibly. Yes, there are object-oriented extensions to Pascal. Lots of them, and that's a problem. Delphi is nice, but do you want to be dependent on Borland?

Modula gradually solved the scaling problem. Modula I added modules; Modula II was a decent non-OOP language, and Modula III added objects. All are dead, although if you care, you can still get Modula III compilers from what's left of DEC's research operation since Compaq bought it.

Ada isn't dead, I know, but it's not used much. And it really is too verbose. The original designers had to make it run on systems without full ASCII punctuation marks, for backwards compatibility with long-forgotten hardware.

The big win for C users is that the language, as standardized and deployed, is complete enough to get almost anything done. Yes, the safety sucks, but at least your project won't hit a wall where you just can't do something.

As for Java, there are technical problems, but most of the problems are political. Microsoft hates the thing. Sun can't quite get their act together on the tools (remember Java Workstation?). Each vendor has a different GUI builder. Most of the GUI systems generate slow code. The transition to the new event model is half complete. The security model turned out to be insecure. And Sun has issued a huge collection of half-working Java packages which they don't maintain very well. Java has found a good niche as the language for the client side of business applications, but it's not making a serious dent in C/C++. I was much more enthusiastic about Java two years ago than I am now.

One promising idea is Safe STL for C++. In debug mode, it's more or less safe; most subscript and pointer errors are caught. It still doesn't catch dangling pointers. You'd need some kind of LINT-like tool to find all the places a non-STL operation might be doing something bad. (Other than high-end CASE tools, there's not much like that for C++.) And the STL is far too complicated for what it does. (Read the discussions in comp.lang.c++.moderated to convince yourself of this. How many language lawyers does it take to construct a loop?) But Safe STL is a step in the right direction.

Language safety is primarily a maintenance issue. You want a safe language not for the original programmer, but for the people maintaining, using, extending, and reusing the code later, long after the original author's mindset has been lost. In large systems, these problems dominate the original coding.