Andrew Lentvorski wrote: > Christopher Smith wrote: > >> The fact that you said "C/C++" kind of screams that you aren't getting >> the point here. C most definitely does not have destructors, and in fact >> most resource management related bugs in C++ can be traced back to >> failing to apply C++'s semantics for avoiding these problems. One of >> C++'s greatest strengths (C compatibility) really turns out to be a >> short coming in this regard: programmers code C++ programs like they are >> C programs. > > Sorry. I misspoke. I tend to think of manual resource management and > lump C/C++ together. > > You are correct that C++ has destructors. And this works fantastically > well as long as programmers only use the STL and access memory. > > Once you touch non-memory resources or have to write your own > destructors, it breaks down. > > You can't put cleanup code for things like sockets into destructors > since even closing a socket can cause errors. And destructors can't > throw exceptions. Whoops. Hence, back to manual resource management > and C++ is no better than Java (it is, in fact, worse but I'll just > assume equality). > > And, if someone has to write their own destructors, there are a bunch of > guidelines that they have to know cold so as not to get things wrong. > Pass. > >> Garbage collection doesn't manage sockets at all. That's the problem. > > And neither can destructors. Sorry. If you don't understand that, > you're in deep trouble already. Please go read "Exceptional C++" by > Herb Sutter (Gah! Checking amazon.com he's up to 3 *entire* books on > the problems of exceptions. Yuk. Glad I don't do C++ anymore ...) > > Destructors only *look* like they can clean up non-memory resources. And > that's the real problem with C++ ... so many things *look* like they can > solve your problem. > > It's only after writing 10,000 lines of code that the subtleties start > to bite. By then nobody wants to go back and redo the architecture to > get it right. Been there, done that, got the scars, don't want any more. > >> There are certainly classes of programs where this stuff doesn't matter, >> particularly with building a simple prototype. If you are trying to >> claim that this isn't an issue for a lot of Java programs, check out how >> man serious projects don't have a "finally" clause in them. ;-) > > Java does use finalizers as a safety net for sockets: > > "On the other hand, nonmemory resources like file handles and socket > handles must be explicitly released by the program, using methods with > names like close(), destroy(), shutdown(), or release(). Some classes, > such as the file handle stream implementations in the platform class > library, provide finalizers as a "safety net" so that if the program > forgets to release the resource, the finalizer can still do the job when > the garbage collector determines that the program is finished with it. > But even though file handles provide finalizers to clean up after you if > you forget, it is still better to close them explicitly when you are > done with them. Doing so closes them much earlier than they otherwise > would be, reducing the chance of resource exhaustion." > > And, BTW, "finally" gets used for locking in Java, as well. > >>> I have the same opinion about the Collections interface in Java. I use >>> the concrete interface rather than the Collection interface. Use the >>> richest interface that makes sense. >> >> "concrete interface"? > > I use will use LinkedList (the actual data structure) instead of Queue > (the collections interface). > > Java prefers Queue on the theory that you can change the underlying > implementation (LinkedList). I'm with Scott Meyers (see Effective STL) > that this is a red herring. You normally need guarantees about > performance and complexity (big O() notation) that preclude changing the > underlying data structure anyway. > >>> I do find the fact that I can't create a default action for interfaces >>> in Java to be annoying. >> >> If you use factories and dynamic proxies you can build a framework that >> will do it for you. You can probably do something similar with >> attributes as well. > > "The usage of design patterns indicates a language failure." > > I forget where I heard it, but I am now convinced of this. If I have to > use patterns, I am in the wrong language.
<..snip..> Seems to me I read this in one of graham's essays http://www.paulgraham.com/articles.html ..although it might have been at some functional programming location stumbled onto by starting from lisp articles.. ..jim -- KPLUG-LPSG@kernel-panic.org http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
