 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / September 2006On Java and C++
Java programmers seem to always be whining about how confusing and overly complex C++ appears to them. I would like to introduce an explanation for this. Is it possible that Java programmers simply aren't smart enough to understand C++? This is not merely a whimsical hypothesis. Given my experience with Java programmers --- the code they write and the conversations they have --- Occam's Razor points to this explanation. For example, "Oooh I'm confused about the difference between pointers, references, and objects! How confusing!" "Oooh operator overloading confuses me! The expression x + y is so confusing, who knows what's happening with that? If x and y are complex numbers, what the hell could x + y mean?" "Oooh multiple inheritance is so confusing! Though I am both a father and a programmer, I still find it so confusing how the same object can be two different things! How confusing!" "Oooh and virtual bases are so bizarre! I am a student --- myself 'the father' is the same student as myself 'the programmer' --- but nonetheless the idea of virtual bases is absolutely confounding and confusing to me!" Again, Occam's Razor is a valuable tool here. In deciding among competing hypotheses, choose the simplest one. To impartial observers of indoctrinated Java programmers, the explanation is simple indeed. snipped dribble.... oh good a pissing competition! My Ruby is better than your (Insert your fave, all time language here). > Again, Occam's Razor is a valuable tool here. In deciding among > competing hypotheses, choose the simplest one. The simplest is: you are a troll.  SignatureSalu2 > > Again, Occam's Razor is a valuable tool here. In deciding among > > competing hypotheses, choose the simplest one. > > The simplest is: you are a troll. Concurred. Perhaps give this one some Occam's Shaving Cream. John drivel +-------------------+ .:\:\:/:/:. | PLEASE DO NOT F :.:\:\:/:/:.: | FEED THE TROLLS | :=.' - - '.=: | | '=(\ 9 9 /)=' | Thank you, | ( (_) ) | Management | /`-vvv-'\ +-------------------+ / \ | | @@@ / /|,,,,,|\ \ | | @@@ /_// /^\ \\_\ @x@@x@ | | |/ WW( ( ) )WW \||||/ | | \| __\,,\ /,,/__ \||/ | | | jgs (______Y______) /\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ ============================================================== SignatureIan Collins. > drivel > [quoted text clipped - 14 lines] > -- > Ian Collins. Wow, posted for only 15 minutes and already 3 replies including a "don't reply to the trolls" reply. Nice one ;) ["Followup-To:" header set to comp.lang.java.programmer.] On 2006-04-26, wellstone9912@yahoo.com penned: > Java programmers seem to always be whining about how confusing and > overly complex C++ appears to them. No, they aren't. Therefore the rest of your troll is moot. Signaturemonique Help us help you: http://www.catb.org/~esr/faqs/smart-questions.html > ["Followup-To:" header set to comp.lang.java.programmer.] On > 2006-04-26, wellstone9912@yahoo.com penned: > > Java programmers seem to always be whining about how confusing and > > overly complex C++ appears to them. > > No, they aren't. They aren't because usally nobody forces them to program on C++ and they have no reason to whine. It is C++ programmers who should whine about this. But it appears now, when C++ became finally complex enough to be unacessible to mere mortals, that C++ programmers are feeling themself members of club open to introduced only . Now they look somewhat like Linux hackers looking down on programmers using other, less esotheric languages. > ["Followup-To:" header set to comp.lang.java.programmer.] On > 2006-04-26, wellstone9912@yahoo.com penned: >> Java programmers seem to always be whining about how confusing and >> overly complex C++ appears to them. > > No, they aren't. Java programmers have no reason to whine because usually nobody forces than to use C++. It is C++ programmers who could whine. But, when C++ finally become too complex to be understood by mere mortals, C++ programmers become feeling themselves members of club with secrets comprehensible only to introduced. They become proud to use C++ and look down on programmers using less esoteric languages like Java. And so they don't whine either, and C++ language quietly and slowly moves toward oblivion ;) from how to start a flame.. chapter 1 I agree that may be C++ programmers are smarter. Even more, I agree that person that fully understands C++ (or Common Lisp, or PL/I) should be very clever and more clever than average (not neccessary Java) programmer. But this doesn't help C++ to be very bad and getting steadily worse language. Because computer language is tool. Because people don't study language for the sake of it, they study them to write programs. More difficult and complex language is, more time is wasted studying it, and less people will understand what they are actually writing when they use this language. I bet <1% of C++ programmers fully understand C++ language. I am sure statistics is radically different for Java - which is MUCH simpler and more easy to understand. I myself programmed about 10 years on C++ and 5 years on Java, so I was able to compare them. And I am sorry for people who achieved full understanding of C++ virtual inheritance, STL, Templates, Functors, and so on. They uselessly wasted huge efforts. And writing programs on complex, poorly understood language doesn't help to write reliable and efficient programs. In this sense C was much better language (through clever use of preprocessor could provide ugly programs). And I understand why C is still so popular in Linux. > Java programmers seem to always be whining about how confusing and > overly complex C++ appears to them. I would like to introduce an [quoted text clipped - 24 lines] > competing hypotheses, choose the simplest one. To impartial observers > of indoctrinated Java programmers, the explanation is simple indeed. ... > In this sense C was much better language (through clever use of > preprocessor could provide ugly programs). And I understand why C is > still so popular in Linux. ... Now, you are begging for a fight? > ... >> In this sense C was much better language (through clever use of [quoted text clipped - 3 lines] > > Now, you are begging for a fight? How should I respond to this? May be I am new to this newsgroup. I (esthetically) liked C very much when I have first seen it, and still think it is (and especially was (I mean in context of 70-80s when it was created)) very good language. However I now prefer to program on Java. I think best quality of Java is how beautifully it removes most unnecessary choices, leaving one very decent way to do things. I now (esthetically) hate C++, however still program on it (using very few 'modern' features, but using classes) sometimes. So I stay by my opinion that C is (was) good language, and C++ is bad language. > How should I respond to this? May be I am new to this newsgroup. > I (esthetically) liked C very much when I have first seen it, and [quoted text clipped - 7 lines] > So I stay by my opinion that C is (was) good language, and C++ is > bad language. The so called "ugly" features is what makes C++ so powerfull. Operator overloading is essentiall for RAD-classes. Aynway... >> I think best quality of >> Java is how beautifully it removes most unnecessary choices, leaving [quoted text clipped - 6 lines] > The so called "ugly" features is what makes C++ so powerfull. Operator > overloading is essentiall for RAD-classes. Aynway... I always wondered in such context what word 'powerfull' means? Does it mean that you can write program that cannot be written on Java? or Does it mean that you can write shorter C++ program doing the same as equivalent Java program? Then may be you should like Perl even more? Or does it man that you can write library, such that equivalent C++ program will LOOK simpler than Java program? >>> I think best quality of Java is how beautifully it removes most >>> unnecessary choices, leaving one very decent way to do things. [quoted text clipped - 11 lines] > Or does it man that you can write library, such that equivalent C++ > program will LOOK simpler than Java program? I meant in last case C++ program using C++ library looks simpler than Java program using Java library. I think that some people may be missing the point in having multiple programming languages. Why do you think that the world has more than one language? Why don't we all use English instead of all having different languages, it would make life so much easier. Well, in fact, it wouldn't. In my honest opinion, once you know how to program at a decent level, you should be able to use any language with just a small amount of effort, if you want to master that language then fine, but be prepared to put the work in. At the same time, the amount of programs or applications that require a team of programmers to know every in-depth detail of their language is slim. C++ has advantages over Java, it also has its fair share of disadvantages. I don't buy into the fact that Java is easier to learn. I have been a learning C++ for about 3 years and as part of my uni course, have now been asked to program some Java. I find Java as a language nice to work with but have the same number of problems I would have expected from learning a new language. Yes, its a slimmed down version, yes it may be easier to do certain things but if we made all programming languages insanely difficult only a small number of people would ever get the joy the rest of us get from programming. Just my thoughts..... > The so called "ugly" features is what makes C++ so powerfull. I don't agree with the fatalistic idea that a feature must be ugly in order to be powerful. The warts in C++ are not due to its power, but to its desire to integrate new features in while retaining source compatibility with 30 years of past decisions, good and bad. If you're willing to give up legacy compatibility, it's possible to design a language with similar and even greater power, but in a much simpler and straightforward package. Such is the D programming language, www.digitalmars.com/d/ For an example of how an "ugly" power feature like templates can be made easier (and even more powerful), see www.digitalmars.com/d/templates-revisited.html . -Walter Bright Digital Mars >> The so called "ugly" features is what makes C++ so powerfull. > [quoted text clipped - 11 lines] > made easier (and even more powerful), see > www.digitalmars.com/d/templates-revisited.html . OK. True, the D language has cleaned up old C inheritances C++ suffers from. However, I doubt anyone would switch to D unless you provide a large class library for almost everything. That's the only true benefit of Java, the large std library. I hope to see D grow and be _the_ (C++)++ one day, though. > OK. True, the D language has cleaned up old C inheritances C++ suffers > from. However, I doubt anyone would switch to D unless you provide a > large class library for almost everything. That's the only true > benefit of Java, the large std library. Yes, large standard library helps. However Perl, Python, C# have something close. I would give additional benefits (for me). a) You don't have to think should you include fields of have variables as objects or references or pointers. It is decided for you usually close to optimal way (closest to references). b) You don't have to bother to use auto_pointer (not working with collections) or new delete or automatic destructor. It is decided for you to use something like auto_ptr but much better. c) You don't have to decide about programming style. Sun provided standard Java style. d) You don't have to decide about naming of files and classes - they are the same. e) Logical package directory structure is forced on you. f) You don't have to choose between char *, string, CString ... - String is better (or same) than either of them and it is only choice. g) you don't have to choose between long int, unsigned int, WORD, DWORD, size_t .... - close to optimal choice if forced on you. h) You don't decide do you use internal or external functions definitions, or do you use macro. - close to optimal choice if only one possible. i) You don't have to decide if you use methods or define new operators. Java choice is sometimes more verbose, but usually more clear. ... As you can guess, I can continue. Dropping all these choices first - makes programming easier, you have less things to bother about, second - makes language smaller and more easy to understand. Of course such approach could lead to very bad language - but Java luckily has good design. And I thing C++ standard committee just made bad design - introducing complexities which doesn't add enough benefits to justify them. > a) You don't have to think should you include fields of have > variables > as objects or references or pointers. It is decided for you usually > close to optimal way (closest to references). What about pointer to a pointer? A pointer is a pointer, a reference is a reference, a variable is a variable. Period. > b) You don't have to bother to use auto_pointer (not working with > collections) or new delete or automatic destructor. It is decided > for you to use something like auto_ptr but much better. I like new/delete. Makes me feel I'm in charge. Just my .02$ > c) You don't have to decide about programming style. Sun provided > standard Java style. Juck! > d) You don't have to decide about naming of files and classes - they > are the same. no, they _have to be_ the same. Otherwise the compiler pukes. > e) Logical package directory structure is forced on you. What about freedom of choice? > f) You don't have to choose between char *, string, CString ... - > String is better (or same) than either of them and it is only > choice. Yeah, and a lot slower in some cases. User std::string where you need dynamic strings, use char[] where you need static strings. You don't have to - but you _can_! > g) you don't have to choose between long int, unsigned int, WORD, > DWORD, size_t .... - close to optimal choice if forced on you. Just a question of style. I use the built-in tpyes for everything. > h) You don't decide do you use internal or external functions > definitions, or do you use macro. - close to optimal choice if only > one possible. That's a real feature of java and D! Include files totally suck! Internal functions are a great benefit as well. Though I'd not want to loose the preprocessor. > i) You don't have to decide if you use methods or define new > operators. Java choice is sometimes more verbose, but usually more > clear. ?? I don't understand that. You can't define operators in Java, can you? Defining operators is one of the most important things for OOP IMHO. > And I thing C++ standard committee just made bad design - > introducing complexities which doesn't add enough benefits to > justify them. Well, if you knew C++ as good as Java, you wouldn't say so I guess. Anyway - I don't give a **** about what others use to write stuff, so this is all just blahblah about nothing. There's no point making one language better than the other. You will pick what suits you best or what your boss indoctrinates on you. I normally dont get involved with pissing contests, but there's only so much bs in a single post i can take without replying... <snip> >> b) You don't have to bother to use auto_pointer (not working with >> collections) or new delete or automatic destructor. It is decided for you >> to use something like auto_ptr but much better. > > I like new/delete. Makes me feel I'm in charge. Just my .02$ So, your entire reasoning behind preferring manual memory managment over garbage collection is that "you feel in charge"? You should give assembly language a go. Meanwhile, in the real world most recent garbage collectors outperform manual memory managment in the vast majority of applications, and as a bonus you get the complete lack of memory leaks and such. >> c) You don't have to decide about programming style. Sun provided >> standard Java style. > > Juck! I'll grant you that it's a matter of taste, but no self respecting developer will consider standards a bad thing. If you do, draw your conclusions. >> d) You don't have to decide about naming of files and classes - they are >> the same. > > no, they _have to be_ the same. Otherwise the compiler pukes. And the ability to stick tons of classes in a single file with a non-related name would be a good thing because....? Again, standards -> good >> e) Logical package directory structure is forced on you. > > What about freedom of choice? Can you think of a single instance where having an illogical directory structure is preferred over a logical one? >> f) You don't have to choose between char *, string, CString ... - String >> is better (or same) than either of them and it is only choice. > > Yeah, and a lot slower in some cases. User std::string where you need > dynamic strings, use char[] where you need static strings. You don't have > to - but you _can_! When was the last time you benchmarked Java strings vs. C++? >> g) you don't have to choose between long int, unsigned int, WORD, DWORD, >> size_t .... - close to optimal choice if forced on you. > > Just a question of style. I use the built-in tpyes for everything. It's freedom that doesnt add anything but confusion and hurts readability. >> i) You don't have to decide if you use methods or define new operators. >> Java choice is sometimes more verbose, but usually more clear. > > ?? I don't understand that. You can't define operators in Java, can you? > Defining operators is one of the most important things for OOP IMHO. He's not claiming you can, he simply says the exact same functionality can be achieved albeit more verbose (i.e. .add rather than +). There are certainly instances where operator overloading provides more readable code, but at the same time it can also be the cause of rather unpredictable code. On this point my stance is that if used with care operator overloading is a pretty neat thing. >> And I thing C++ standard committee just made bad design - introducing >> complexities which doesn't add enough benefits to justify them. [quoted text clipped - 4 lines] > better than the other. You will pick what suits you best or what your boss > indoctrinates on you. Ofcourse there's a point in making languages "better" or at least different than others. Sometimes a language is simply outdated, sometimes it's just not a viable option for certain applications (people generally dont write web-based application in C++ for example, just as you wont find many commercial games or OSs written in Java). As for bosses, people usually get a job based on their language skills and preferences, not the other way around. Anyway. there's room for both, but most of your arguments in the post above are flawed or outdated in my opinion, as i feel you're considering rather obvious weaknesses of C++ to be benefits. And to the OP, anyone claiming C++ programmers are somehow better than Java programmers is a tool. 90% of skills related to being a "good developer" is completely unrelated to the language you're using. > I normally dont get involved with pissing contests, but there's only so much > bs in a single post i can take without replying... [quoted text clipped - 56 lines] > On this point my stance is that if used with care operator overloading is a > pretty neat thing. Unfortunately I once saw one of the senior developers/team leaders actually overload the comma operator. That cause no end of problems. Its a powerful tool granted, so is an electric screw driver - but most times a simpler approach is better. * Remon van Vliet: > Meanwhile, in the real world most recent garbage collectors > outperform manual memory managment in the vast majority of applications, and > as a bonus you get the complete lack of memory leaks and such. All three of those assertions are incorrect. (1) the explicit assertion of guaranteed performance is incorrect, (2) the explicit assertion of no memory leaks is incorrect, and (3) the implicit assertion of no automatic garbage collection in C++, as if it was a non-C++ only technique, is incorrect. Such incorrect, emotionally based beliefs help create bad software. I think perhaps the easiest for you to see the incorrectness of, is (2), the belief that no memory leaks occur. A simple way to create a memory leak in Java is to install an object in some global list of objects to be called back on (event handling), then forget to remove it. In short, what you wrote is rubbish, and dangerous rubbish. SignatureA: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? >I think perhaps the easiest for you to see the incorrectness of, is (2), >the belief that no memory leaks occur. A simple way to create a memory >leak in Java is to install an object in some global list of objects to >be called back on (event handling), then forget to remove it. see http://mindprod.com/jgloss/packratting.html I think you are quibbling over terminology. A leak would be an object nothing pointed to continuing to tie up ram. Packratting is holding on to objects you will never need again. Unless you ran a program twice and studied the history, there is no way you could have the ESP to determine that even in theory. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Roedy Green skrev: > >I think perhaps the easiest for you to see the incorrectness of, is (2), > >the belief that no memory leaks occur. A simple way to create a memory [quoted text clipped - 8 lines] > twice and studied the history, there is no way you could have the ESP > to determine that even in theory. This is playing wordgames. I don't care if it is what is in Java-speak called a memory leak or pack-ratting. The fact is that you have to do some "resource management" stuff to avoid memory usage increasing ad infinitum. And this is not theoretical. If I remember correctly this behaviour was found in a released official Java-library. So Java is not just "allocate and forget" even when it comes down to "pure" memory. Again the advantage is with C++. /Peter > -- > Canadian Mind Products, Roedy Green. > http://mindprod.com Java custom programming, consulting and coaching. >This is playing wordgames. I don't care if it is what is in Java-speak >called a memory leak or pack-ratting. The fact is that you have to do >some "resource management" stuff to avoid memory usage increasing ad >infinitum. And this is not theoretical. If I remember correctly this >behaviour was found in a released official Java-library. Swing is rather notorious for this. If you don't remember to call "dispose()" on your GUI windows when you are done with them, they may decide to stick around indefinately. This then also prevents the GC from collecting everything that is referenced within the window, which can be a lot. >So Java is not >just "allocate and forget" even when it comes down to "pure" memory. >Again the advantage is with C++. Depends a bit on what you mean by "pure" memory, but that is probably too academic a debate to get into. Cheers Bent D SignatureBent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd powered by emacs * Roedy Green: >> I think perhaps the easiest for you to see the incorrectness of, is (2), >> the belief that no memory leaks occur. A simple way to create a memory [quoted text clipped - 6 lines] > nothing pointed to continuing to tie up ram. Packratting is holding > on to objects you will never need again. When a program uintentionally gobbles up memory, never releasing it, and never using it again, there is a memory leak. So, you're not quibbling over terminology: you're using terminology to try to define that reality away. Which would be utterly silly were it not that someone might believe it, and that someone evidently has believed it. Your reference states: "In fact it is almost impossible to write a program that nullifies references to every object the instant it will never be needed again. So every program is guilty of minor packratting." Apart from the lack of connection from premise to conclusion, that's not a fact, it's an excuse for sloppiness. Trying to define the problem away by inventing new terminology and redefining old is more of the same, an extra, fallback excuse position for incompetence. "Hey, it's not a memory leak, it's /packratting/ [or whatever], and besides [fallback excuse position], it's impossible to avoid, so there!" Let's not discuss at that level, trying to pull the wool over things that are technically clear and trivial but perhaps not viewed as compatible with one's position. It is possible to avoid memory leaks, it is possible to have them with or without automatic garbage collection, and it is possible to use garbage collection in C++, so the assumptions are all incorrect. SignatureA: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? >Apart from the lack of connection from premise to conclusion, that's not >a fact, it's an excuse for sloppiness. In java, memory leaks and packratting are quite different problems and require quite different tools to detect them and quite different solutions. If you wished, you could make the same distinction in C++, but you don't because the distinction does not matter so much for C++. The point we Java folk make is that what we call memory leaks are basically handled. They can't happen unless the JVM designer has blown it. There are a few packratting gotchas you have to specifically watch out for. We have tools called profilers for detecting the others. Memory allocation is generally not a problem except in very complex programs. Nearly all of us Java folk came originally from a C++ background, so there is no way on earth you will convince us that C++ memory allocation is easier and more fool proof, especially when you don't even claim to know Java. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. * Roedy Green: >> Apart from the lack of connection from premise to conclusion, that's not >> a fact, it's an excuse for sloppiness. > > In java, memory leaks and packratting are quite different problems and > require quite different tools to detect them and quite different > solutions. Exactly how can the memory leak that cannot exist, be detected and require a different solution? > If you wished, you could make the same distinction in C++, but you > don't because the distinction does not matter so much for C++. On the contrary, in C++ it's meaningful to talk about different kinds of memory leaks, such as when there's still a reference somewhere, what you call a "packrat", and when there's no reference anywhere. If the case of no reference couldn't exist, as in Java, then it would be meaningless to distinguish it. That distinction is meaningless for Java. > there is no way on earth you will convince us that C++ memory > allocation is easier and more fool proof, especially when you don't > even claim to know Java. I have not made the claims you assert. I don't believe that you talk on behalf of "us", as you imply. Perversely, I hope you're trolling. SignatureA: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? >Exactly how can the memory leak that cannot exist, be detected and >require a different solution? If you discovered a true leak, you have to create an SSCCE and submit that to the JVM vendor, or the AOT run time vendor. See http://mindprod.com/jgloss/sscce.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >* Roedy Green: >> [quoted text clipped - 7 lines] > Exactly how can the memory leak that cannot exist, be detected and require > a different solution? If Roedy had written "require quite different sets of tools and quite different sets of solutions", would that have been better? Then you could say that for problems which do not exist, the appropriate sets are the empty sets. Obviously, if one problem can occur, and another problem cannot occur, then they must be different problems, which I believe was Roedy's main point, even if he failed to express it properly. >> If you wished, you could make the same distinction in C++, but you >> don't because the distinction does not matter so much for C++. [quoted text clipped - 4 lines] > no reference couldn't exist, as in Java, then it would be meaningless to > distinguish it. That distinction is meaningless for Java. (Ditto as above, I think what Roedy meant is clear, though he may have not have expressed it in a way that you wanted). >> there is no way on earth you will convince us that C++ memory >> allocation is easier and more fool proof, especially when you don't >> even claim to know Java. > > I have not made the claims you assert. I don't believe that you talk on > behalf of "us", as you imply. Maybe this is a psychological phenomena, but when I read "us", I had assumed he was referring to "Java folks" (perhaps because I am one of those Java folks). I think there's a lot of emotional energy here which may cause us to say things we wish we hadn't (where we here is both Java folks and C++ folks). There's too much of an us-versus-them mentality going on, and it's very easy for a Java person, posting from a Java newsgroup, to see an unfamiliar name, and think "must be some C++ fanatic" and vice versa. > Perversely, I hope you're trolling. If you go through the Google archives of comp.lang.java.programmer, you'll see Roedy has a pretty good track record of being a helpful contributor to the Java community. I don't suspect him of trolling. Rather, I suspect these kind of threads bring out the worst in us. - Oliver > >* Roedy Green: > >> [quoted text clipped - 16 lines] > then they must be different problems, which I believe was Roedy's main > point, even if he failed to express it properly. That is really grasping at straws. Using set theory to weed out a meaning you like from a the rewording of a statement. If we were in the middle of an argument about abstract math then maybe it would have its place...but we are not. >That is really grasping at straws. Using set theory to weed out a >meaning you like from a the rewording of a statement. If we were in >the middle of an argument about abstract math then maybe it would have >its place...but we are not. You are not a programmer at heart. You would make a better lawyer. They get paid to deliberately misinterpret. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > >That is really grasping at straws. Using set theory to weed out a > >meaning you like from a the rewording of a statement. If we were in [quoted text clipped - 3 lines] > You are not a programmer at heart. You would make a better lawyer. > They get paid to deliberately misinterpret. Won't respond to your personal attack but I will respond to your claim I am purposfully misinterpreting your statements. QUOTE >Exactly how can the memory leak that cannot exist, be detected and >require a different solution? If you discovered a true leak, you have to create an SSCCE and submit that to the JVM vendor, or the AOT run time vendor. ENDQUOTE Both your original statement and your reply indicate that the non set theory interpretation of your words are in fact what you originally meant. Are you claiming otherwise? If so then perhaps you wish to reword YOURSELF instead of letting other attempt weed nuggets of insight on their own? There is at least one other person who interpreted what you said as I have so your meaning is obviously not as clear as you indicate. If I misinterpret your words it is because they are ambiguous at best...not because I do so on purpose. > Won't respond to your personal attack but I will respond to your claim > I am purposfully misinterpreting your statements. [quoted text clipped - 15 lines] > clear as you indicate. If I misinterpret your words it is because they > are ambiguous at best...not because I do so on purpose. His word are clear... for every one who familiar with java. Its just different levels. True leaks are just another level - they can appear only if JVM has a heavy bug. Only JVM vendor should/can fix such bugs. You can't fix JVM, you have to write SSCCE and send it to JVM vendor. Andrey Signaturehttp://uio.imagero.com Unified I/O for Java http://reader.imagero.com Java image reader http://jgui.imagero.com Java GUI components and utilities > His word are clear... for every one who familiar with java. > Its just different levels. And that is my interpretation. I don't go along with the null set interpretation of his statements. So apparently, if I am misinterpreting what he said then you are also and that makes at least three people now. > True leaks are just another level - they can appear only if JVM has a heavy > bug. > Only JVM vendor should/can fix such bugs. > You can't fix JVM, you have to write SSCCE and send it to JVM vendor. That is a pretty major can't but isn't so different I suppose than a buggy compiler. However, a buggy compiler could theoretically be fixed yourself if it is OS. On the other hand even fixing java on a single platform involves cooperation from Sun does it not? I know there are licensing issues I just don't know how controlling they are. You would also necessarily have to get all your users to switch to your fixed VM. Your fixed compiler just generates a now good executable you can pass on. That all depends on OS versions of the compilers and VMs involved...as is the case in any other proprietery system if you don't have the source you are at the mercy of the vendor...in other words f.cked. Anotehr point though is that with a buggy compiler you have a broken program, not a program that only breaks on one VM. >> True leaks are just another level - they can appear only if JVM has a >> heavy [quoted text clipped - 7 lines] > platform involves cooperation from Sun does it not? I know there are > licensing issues I just don't know how controlling they are. No, there's an open source JVM called SableVM. If you find a bug in SableVM, you can modify it to fix the bug, without dealing with Sun as an intermediate step. Note though that Sun owns the trademark "Java", and they allow you to use the term "Java" with your products as long as your products pass certain well defined tests. For example, if your product is supposed to be a Java virtual machine, then it must adhere to the appropriate specifications. SableVM does, so it is legally allowed to call itself a "JVM". If you modify SableVM so that it doesn't adhere to the specs, then you can't call your modified product a "JVM" anymore. > You would also necessarily have to get all your users to switch to your > fixed VM. Your fixed compiler just generates a now good executable you [quoted text clipped - 3 lines] > is the case in any other proprietery system if you don't have the > source you are at the mercy of the vendor...in other words f.cked. If there's a bug in a JVM which causes a memory leak, that's a bug in the JVM, and not a bug in the Java Compiler. I guess the equivalent in C++ (or other languages) would be a bug in the OS (Operating System, not Open Source). You write a C++ program which request the OS to allocate you some memory, and then you later request for the OS to deallocate that memory. If the OS doesn't deallocate that memory, then you're f.cked. If it's an open source OS (e.g. Linux), you could fix it, and then ask all your users to switch their OSes. If it's a closed source one (e.g. Windows), you could submit a bug report and hope for the best. - Oliver Hello, > Won't respond to your personal attack but I will respond to your claim > I am purposfully misinterpreting your statements. As a purely outside observer to this thread, I found this statement fairly amusing considering the following text that has appeared in this thread. > Ahhh yes, the last ditch attack from the weak. > Only one incapable of learning very simple techniques to make it a > non-issue. > ... > So, if your mind is boggled by memory and exception handling then you > better stick to simple problems. > Well since you can't read and/or comprehend what you are reading I > think it would be a waste of time and effort to offer any proof of > anything to you...besides being unwilling to prove something I didn't > bring up. > You need to have your mind reading ability rechecked. It isn't working > anymore. IMHO you shouldn't have grown to depend on it anyway. > > Your logical reasoning circuitry could use some work too... > This is just stupid...almost as stupid as > me having to point this out to you. > > I definately hear a vacuum... > Come back when you can understand. And perhaps my personal favorite: > Another totally unrelated ad hominem. You are obviously a very stupid > person. I base this on your method of argument, your inability to [quoted text clipped - 4 lines] > ...there is ample evidence in your own statements to support that you > are in fact an idiot. Sometimes the threads started by the trolls end up the most informative ... Good Luck, -TJW > > Another totally unrelated ad hominem. You are obviously a very stupid > > person. I base this on your method of argument, your inability to [quoted text clipped - 7 lines] > Sometimes the threads started by the trolls end up the most > informative ... You can come to any conclusion you want and provide whatever view you wish people to see if you quote people out of context. For example...the above (yes, I am taking liberty in my selection). That was in reply to someone telling me I'm a fundamentalist religious nut because my parents apparently are because my name is Noah. That is an incredibly stupid statement to make (which was just one more in a long line of incredibly stupid statements, generalizations, and ad hominems) and had nothing to do with anything. Everything in my reply fit, including the admision that the reply itself was a personal attack that was not on topic...something you neatly snipped from my post. Your post is no more informed, balanced, or interesting than the person's to whom that above quote replies to. > You can come to any conclusion you want and provide whatever view you > wish people to see if you quote people out of context. I can, and I often do. Seriously, I was not trying to insult you. > That was in reply to someone telling me I'm a fundamentalist religious > nut because my parents apparently are because my name is Noah. That is > an incredibly stupid statement to make > .... I totally agree, any such statement is inappropriate. I think my specific response to reading that statement was tempered however because I thought that the poster was joking. > Everything in my reply fit, including the admision that the reply > itself was a personal attack that was not on topic...something you > neatly snipped from my post. This is my error and was unintentional. I apologize, but this is not totally my point. My point was simply that the set of statements: { Statement 0: Ad-Hominem arguments are irrelevant and meaningless. Statements 1..n: Ad-Hominem argument (i) } is inconsistent. I saw a series of statements in this thread that match that pattern (qualified by the poster or not) which I found humorous. Nothing against you personally, just a comment on what the discussion had become. > Your post is no more informed, About the previous discussion on the costs/benefits of Java vs. C++, you are 100% correct. I never claimed to be qualified to engage in such a discussion. My comment however was on the thread itself, which was informed as I quoted numerous references for the single point I wanted to make. > balanced, Honestly, I'm not sure how this requirement applies in general to a group that discusses the use of a programming language, but if your referring to my omitted quote, again, I apologize. > or interesting than the person's to whom that above quote replies > to. Matter of opinion. I happen to disagree. I am way too new here to continue defending a mediocre joke, so I will make this my last post in this thread. Peace, -TJW > Hello, > [quoted text clipped - 4 lines] > statement fairly amusing considering the following text that has > appeared in this thread. snipped brilliantly researched response. v cool TJW. >> Hello, >> [quoted text clipped - 8 lines] > > v cool TJW. 100% ACK Andrey Signaturehttp://uio.imagero.com Unified I/O for Java http://reader.imagero.com Java image reader http://jgui.imagero.com Java GUI components and utilities >> Hello, >> [quoted text clipped - 8 lines] > > v cool TJW. Thank you ... I got lucky on this one, a post of mine actually made sense. :) Peace, TJW Remon van Vliet skrev: > I normally dont get involved with pissing contests, but there's only so much > bs in a single post i can take without replying... [quoted text clipped - 9 lines] > So, your entire reasoning behind preferring manual memory managment over > garbage collection is that "you feel in charge"? The problem is not as simple as that. The fact is that garbage collection is useful for one resource only: memory. All other resources must be handled explicitly in Java. Depending on your application, this might be a small or a large problem, but the fact is that RAII in C++ gives you a way to cope with all resources in a uniform way. > You should give assembly > language a go. Meanwhile, in the real world most recent garbage collectors > outperform manual memory managment in the vast majority of applications, and > as a bonus you get the complete lack of memory leaks and such. What do you mean with "and such"? I believe C++ is in the best position to guarantee the whole thing. Java gives you protection wrt memory-leaks and C++ gives you protection regardless of the resource. Also, most C++ programs can use garbage collection if they want to - if only they do not hide their pointers. This is old knowledge, so I assume that you are aware of this? Last but not least, the advantage of garbage collection over manual memory management is not so evident as you seem to imply. If you look at the newest, better performing collectors you should also compare this to the newest and smartest allocators. Also remember that C++ gives you choices - e.g. to use a specialised allocator or to simply use stackbased variables. > >> c) You don't have to decide about programming style. Sun provided > >> standard Java style. [quoted text clipped - 3 lines] > I'll grant you that it's a matter of taste, but no self respecting developer > will consider standards a bad thing. If you do, draw your conclusions. Well - there are plenty of standards around. You should use the standard that fits your purpose, thats what they are there for. Javas straight-jacket is not an advantage in my eyes. E.g. I do not understand why each class MUST have its own file (unless you make that class a secondary citizen). > >> d) You don't have to decide about naming of files and classes - they are > >> the same. [quoted text clipped - 3 lines] > And the ability to stick tons of classes in a single file with a non-related > name would be a good thing because....? Again, standards -> good Bad programming is far more than that. I do not see any correlation here. > >> e) Logical package directory structure is forced on you. > > [quoted text clipped - 11 lines] > > When was the last time you benchmarked Java strings vs. C++? There are three kinds of lies. Lies, statistics and benchmarks.... or so I've heard. The nice thing about C++ strings is that the number of characters in a string is a O(1) operation. In Java, you would have to check the number of surrogates making it a O(n) operation. Also C++ strings are more powerful than Java strings. All in all I believe I'd prefer using C++ strings, switching to some specialised class in the unlikely case string-handling did turn up to take a significand part of my programs execution time. > >> g) you don't have to choose between long int, unsigned int, WORD, DWORD, > >> size_t .... - close to optimal choice if forced on you. > > > > Just a question of style. I use the built-in tpyes for everything. > > It's freedom that doesnt add anything but confusion and hurts readability. Javas type system is not freedom but rather a jail. It has prevented porting of Java to several platforms, it gives cumbersome Unicode support and it forces Java to stick with inefficient 32-bit integers in a world that is soon turning to 64 bits. > >> i) You don't have to decide if you use methods or define new operators. > >> Java choice is sometimes more verbose, but usually more clear. [quoted text clipped - 24 lines] > a job based on their language skills and preferences, not the other way > around. I fully agree here. > Anyway. there's room for both, but most of your arguments in the post above > are flawed or outdated in my opinion, as i feel you're considering rather > obvious weaknesses of C++ to be benefits. And to the OP, anyone claiming C++ > programmers are somehow better than Java programmers is a tool. 90% of > skills related to being a "good developer" is completely unrelated to the > language you're using. And here too. Sort of at least! ;-) /Peter Very interesting post, Koch. I've snipped the parts I've agreed with, and am only including some concerns I have about C++ and clarifications on Java. > I do not > understand why each class MUST have its own file (unless you make that > class a secondary citizen). Actually, only the top level public classes should be in their own files. Private classes, or nested classes, can be within any file. I suspect the reason why is primarily a pragmatic one: So that the classloader can easily locate the file that contains the bytecode for the classes and load them. It has some nice side effects. When I'm given someone else's code base, and I have a qualified class name, I always immediately know the full path to the source code file. I don't even have to browse a directory listing or anything like that. > There are three kinds of lies. Lies, statistics and benchmarks.... or > so I've heard. The nice thing about C++ strings is that the number of [quoted text clipped - 4 lines] > unlikely case string-handling did turn up to take a significand part of > my programs execution time. I'm surprised unicode-stuff would appear as an advantage of C++ over Java. I won't dispute this, since I don't know enough about the state of C++ libraries, but I was under the impression that the lowest common denominator for C++ was ASCII, while the lowest common denominator for Java was the BMP (Basic Multilingual Plane) portion of unicode. I can't speak for others (e.g. archeologists, etc.), but I've never used characters characters outside the BMP. For example, while I am interested in writing text in English, French and Japanese, I am not interested in writing in cuneiform, cypriot, or byzantinne musical notation. So I've never had a problem with text in Java applications. However, I have had problems with C++ applications which assumed ASCII. WinAmp is one example. It has trouble handling the ID3 tags of my Japanese songs. iTunes seems a bit better at this. *SOMETIMES* it properly renders the kanji characters, but other times the track name will show up as a bunch of question marks. So I was under the impression that C++ support for unicode was behind Java, not ahead of it. I guess times have changed. > Javas type system is not freedom but rather a jail. It has prevented > porting of Java to several platforms, it gives cumbersome Unicode > support and it forces Java to stick with inefficient 32-bit integers in > a world that is soon turning to 64 bits. In its defense, I think the fact that the size of Java's primitive datatypes remains constant is a "good thing". If an when you want to use a 64 bit datatype, you'd simply use "long" instead of "int". And I don't think there's any technical reason why, in a few years from now, if 128 bit were desired, a new datatype couldn't be added to Java to support that, without breaking any previous code (except possibly via the addition of a new keyword, which could no longer be used as a variable or method name). The company I work at, Castor Technologies, makes some money by porting C code from 32 bit platforms to 64 bit platforms. The fact that we're making money must mean it's too painful for our clients to do the migration themselves. I don't know if this C situation applies to C++ as well. - Oliver >> c) You don't have to decide about programming style. Sun provided >> standard Java style. > > Juck! You don't like Sun Style? I find it not worse than any other, and it has advantage that most Java programmers use it. In C, for example, Linux core uses one style, and Gnu uses other, incompatible style, and Microsoft, of course, uses third. >> d) You don't have to decide about naming of files and classes - they >> are the same. > > no, they _have to be_ the same. Otherwise the compiler pukes. Of course everything I wrote here (style is exception) is enforced by compiler. That's what compiler is for. >> e) Logical package directory structure is forced on you. > > What about freedom of choice? My main idea in my post was that freedom of choice is often Bad. Anyway, I don't insist on this as a law, only as my personal preference. May be you value freedom of choice in programming more. Then C++ obviously has advantages for you. >> f) You don't have to choose between char *, string, CString ... - >> String is better (or same) than either of them and it is only [quoted text clipped - 3 lines] > dynamic strings, use char[] where you need static strings. You don't > have to - but you _can_! I benchmarked strings long time ago. My impression - C strings are much faster, STL/CStrings have about the same speed (I don't remember exactly) as Java strings. But C strings created their own (apparently very big) category of security breaches. Bottom line - you don't lose much, if anything, by sticking to Java strings. >> g) you don't have to choose between long int, unsigned int, WORD, >> DWORD, size_t .... - close to optimal choice if forced on you. > > Just a question of style. I use the built-in tpyes for everything. And I am a little bit sick of casting size_t to int. Or remembering what to use: long long or _int64. > Well, if you knew C++ as good as Java, you wouldn't say so I guess. I suspect it is not my fault that I better know Java than C++. I spend 10 years programming mostly on C++ and only 5 years mostly on Java. It is just more easy to learn Java. >>> c) You don't have to decide about programming style. Sun provided >>> standard Java style. [quoted text clipped - 5 lines] >core uses one style, and Gnu uses other, incompatible style, and >Microsoft, of course, uses third. 1. A Java shop can adopt Sun style which every new programmer knows since they have seen it ad nauseam in the Sun classes. 2. Or a shop can adopt its own more rigid super set of Sun rules. 3. Or a shop can adopt its own style. 4. Or a shop can adopt chaos and start blood feuds between programmers to poison the coffee of the programmers who reformat "their" code and deal with repository false deltas. How is a C++ shop better off having only choices 3 and 4? see http://mindprod.com/jgloss/codingconventions.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >I like new/delete. Makes me feel I'm in charge. Just my .02$ The problem is a bit like "feeling in charge" at a 747 control panel. You know you are not up to the job for any serious app. I used to use Numega to track leaks in a C/C++ team's code. It was not a matter of fixing them, but getting them down to a dull roar. Mixing exception handling and memory management boggles the human mind. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > Mixing exception handling and memory management boggles the human > mind. Only one incapable of learning very simple techniques to make it a non-issue. http://www.hackcraft.net/raii/ Note that this won't work in Java. You can't use this technique to clean up resources like handles and other resources that are not memory related as you can't depend on the deallocation of any object in your code; GC picks it up when it wants to. There are also the three exception guarantees, which are applicable in ANY language, that also make exception handling in C++ less risky. If you aren't capable of avoiding a memory leak in an exceptional situation then you can't handle any other kind of leak and believe me...the problem exists in ANY language that has exceptions as there are numerous resources that you gather and have to release that are not memory related and so you can't use GC as a crutch for that. So, if your mind is boggled by memory and exception handling then you better stick to simple problems. >> Mixing exception handling and memory management boggles the human >> mind. [quoted text clipped - 20 lines] > So, if your mind is boggled by memory and exception handling then you > better stick to simple problems. It's quite tricky to be really condecending and really wrong at the same time but hey, somehow you managed. Rather than question the intelligence and expertise of someone who offered perfectly valid points you may want to consider either actually having a look at Java instead of browing Java newsgroups ready to jump in on the first sigh of a troll. I'd be more than interested in even a single practical example of these resource/exception issues of Java you speak of that are so much easier in C++...just one.. * Remon van Vliet -> Noah Roberts > I'd be more than > interested in even a single practical example of these resource/exception > issues of Java you speak of that are so much easier in C++...just one.. All external resources. They're not "so much easier" to handle in C++. In fact they're /very difficult/ to handle correctly in C++. However, C++ offers facilities that make it practically possible to prevent such problems from arising. People who come from e.g. Java or C tend to not see those issues as problems, because in those languages there's just no hope of dealing preventively with fundamental resource leak issues, so the pragmatic approach of "if it becomes a real problem, let's deal with that concrete real problem" is applied instead of designing in any guarantee from the start. Pick up any C or Java code dealing with external resources of any kind, and more often than not, there's a potential resource leak staring the C++ programmer in the eye. However, the C++ programmer would be wrong to chastise the C or Java programmer for that, because most probably the resource leaks will be consequences of the intentional pragmatic approach to dealing with the languages' shortcomings: those potential leaks won't, in general, be actual problematic leaks. Add to that that C++ is so infernally huge and complex, like COBOL or PL/1, that it's seldom used correctly by the average programmer. And in sum that means that the C or Java code may actually have less relevant resource leaks than the equivalent average programmer's C++ code. Only for the critical support code written by an expert or experts does C++ shine. Because there the potential can be realized. SignatureA: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? >* Remon van Vliet -> Noah Roberts > > I'd be more than >> interested in even a single practical example of these resource/exception >> issues of Java you speak of that are so much easier in C++...just one.. > > All external resources. I think this is factually untrue. So, a practical example please? > They're not "so much easier" to handle in C++. In fact they're /very > difficult/ to handle correctly in C++. However, C++ offers facilities [quoted text clipped - 8 lines] > kind, and more often than not, there's a potential resource leak staring > the C++ programmer in the eye. Perhaps said C++ programmer just isnt overly familiar with Java. It seems to be the red line through these kind of threads. >However, the C++ programmer would be wrong to chastise the C or Java >programmer for that, because most probably the resource leaks will be [quoted text clipped - 4 lines] > Add to that that C++ is so infernally huge and complex, like COBOL or > PL/1, that it's seldom used correctly by the average programmer. Once again this sounds like a C++ developer with a superiority complex. "Average programmers" here and there. Fact remains i still need to hear of a external resource leak problem that's consistently easier to deal with in C++ compared to Java. > And in sum that means that the C or Java code may actually have less > relevant resource leaks than the equivalent average programmer's C++ code. > Only for the critical support code written by an expert or experts does > C++ shine. Because there the potential can be realized. "Critical support code"? like? Remon van Vliet skrev: > >* Remon van Vliet -> Noah Roberts > > > I'd be more than [quoted text clipped - 4 lines] > > I think this is factually untrue. So, a practical example please? Just one simple example, then: files. The lack of cleaning up of resources in Java is so common that the Java library calls the garbagecollector whenever opening a file fails. Often this solves the problem since the likely reason is that the program leaks this resource. You might argue that there's a solution to that problem, but the "solution" is a hack and it works less than well on a system that is truly multiuser. [snip] > > People who come from e.g. Java or C tend to not see those issues as > > problems, because in those languages there's just no hope of dealing [quoted text clipped - 7 lines] > Perhaps said C++ programmer just isnt overly familiar with Java. It seems to > be the red line through these kind of threads. Look at any reasonably sized Java program and look at the try ... finally constructs. Likely each of these is a place where resources are to be released. This is evidence that this handling of leaks is a manual process which makes the program more fragile. Also it causes the programs to be difficult to maintain. What happens - as an example - to a > >However, the C++ programmer would be wrong to chastise the C or Java > >programmer for that, because most probably the resource leaks will be [quoted text clipped - 9 lines] > external resource leak problem that's consistently easier to deal with in > C++ compared to Java. I do not understand you. So long as you encapsulate all resources in a class, there is no chance of leaks anymore. This is not the case for Java. > > And in sum that means that the C or Java code may actually have less > > relevant resource leaks than the equivalent average programmer's C++ code. > > Only for the critical support code written by an expert or experts does > > C++ shine. Because there the potential can be realized. > > "Critical support code"? like? I believe most large system out there in the real world relies on C or C++. Examples are numerous, but I could mention banking, telecommunication and database management systems. I doubt you will find any large product of this type in Java. There will be lots of Java in the "supporting" infrastructure of course - most likely my homebanking solution is Java. But all the "real" and "heavy" stuff is most likely C/C++. /Peter > I believe most large system out there in the real world relies on C or > C++. Examples are numerous, but I could mention banking, [quoted text clipped - 3 lines] > homebanking solution is Java. But all the "real" and "heavy" stuff is > most likely C/C++. Oh I think there are plenty of large projects using Java even if I can't think of one off the top of my head. Besides, any fact that lots of large stuff uses C or C++ can be written of as a legacy issue anyway. Millions and millions of lines of code don't get turned over to a different language just because it's better (assuming for the moment that Java is 'better') even if there has been over 10 years to do so. It just doesn't happen and anyone insisting that it should is going to be out of work really fast. > I believe most large system out there in the real world relies on C or > C++. Examples are numerous, but I could mention banking, [quoted text clipped - 3 lines] > homebanking solution is Java. But all the "real" and "heavy" stuff is > most likely C/C++. You're wrong. I don't know about telecommunication and DBMS, but for banking, insurance and other "large systems" in the "real world", it's mostly COBOL, and the businesses are looking to migrate their code to Java or .NET. The reason I know this is that I work for a porting and migration company (Castor Technologies) and we often get contracts from banks, insurance companies, educational institues and the governments asking to migrate their COBOL stuff to the above two platforms. For what it's worth, usually for educational institutes they want to switch to .NET, and everyone else wants to switch to Java. - Oliver * Remon van Vliet: >> * Remon van Vliet -> Noah Roberts >>> I'd be more than [quoted text clipped - 3 lines] > > I think this is factually untrue. So, a practical example please? Perhaps the most infamous was the earliest versions of the Swing library in Java. > isnt overly familiar with Java > superiority complex. > Fact remains i still need Keep to the technical, not the emotional, please, even in a trolling thread. > "Critical support code"? like? That's an ungood question, from the perspective of topicality. What's critical generally depends on the context (e.g. project, organization), and describing such a context fully, so that a troller can't take issue with it, isn't possible in a Usenet posting. However, the C++ standard library is one example of support code that's critical in any context. SignatureA: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? > > There are also the three exception guarantees, which are applicable in > > ANY language, that also make exception handling in C++ less risky. [quoted text clipped - 12 lines] > interested in even a single practical example of these resource/exception > issues of Java you speak of that are so much easier in C++...just one.. Well since you can't read and/or comprehend what you are reading I think it would be a waste of time and effort to offer any proof of anything to you...besides being unwilling to prove something I didn't bring up. Why do I question your ability to comprehend the written word? Because I _never_ said anything was easier in C++ than Java or the other way around. The one thing I did say that could even REMOTELY be considered such was to say that RAII won't work and I already gave the reason why - you can't depend on the timing of deallocation in Java and you have 0 control over it. I am more capable in C++ but that is because I rarely use Java. On the other hand, I am fully capable of coding in Java and have done so many times. >> Mixing exception handling and memory management boggles the human >> mind. [quoted text clipped - 3 lines] > > http://www.hackcraft.net/raii/ There's another way to do it - scope guard. Here's an article on it: http://www.digitalmars.com/d/exception-safe.html -Walter Bright www.digitalmars.com C, C++, D programming language compilers >>> Mixing exception handling and memory management boggles the human >>> mind. [quoted text clipped - 9 lines] > -Walter Bright > www.digitalmars.com C, C++, D programming language compilers What point am i missing if i mention the "finally" block in Java? > What point am i missing if i mention the "finally" block in Java? That nobody said it was impossible to release resources correctly in exceptional situations in Java. What was said is that memory management and exceptions are "mind boggling" issues and I made the point that you better be able to handle such things because the problem comes up in any language that has exceptions as there are other resources besides memory that need correct handling in exceptional situations. I also gave two examples of how C++ programmers deal with the problem from the ground up. Also, you could read that article above which shows some shortcommings of both RAII and finally. However, the "scope guard" appears to be a D language particular construct so is rather moot in this discussion. It is just another way to do the same thing...better or not, I pretend to know. > Also, you could read that article above which shows some shortcommings > of both RAII and finally. However, the "scope guard" appears to be a D > language particular construct so is rather moot in this discussion. There's a link at the end of the article with Andrei Alexandrescu's technique for doing a limited form of scope guard in C++. http://www.digitalmars.com/d/exception-safe.html -Walter Bright www.digitalmars.com C, C++, D programming language compilers * Walter Bright: >> Also, you could read that article above which shows some shortcommings >> of both RAII and finally. However, the "scope guard" appears to be a D [quoted text clipped - 4 lines] > > http://www.digitalmars.com/d/exception-safe.html I think you should get the attributions right (sorry, how could I put this in a more gentle way?): ScopeGuard was Petri Marginean's invention, and he co-authored the CUJ article with Andrei. SignatureA: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? > * Walter Bright: >>> Also, you could read that article above which shows some shortcommings [quoted text clipped - 9 lines] > this in a more gentle way?): ScopeGuard was Petri Marginean's invention, > and he co-authored the CUJ article with Andrei. You're right. I apologize for the error. > > Also, you could read that article above which shows some shortcommings > > of both RAII and finally. However, the "scope guard" appears to be a D > > language particular construct so is rather moot in this discussion. > > There's a link at the end of the article with Andrei Alexandrescu's > technique for doing a limited form of scope guard in C++. Well, that is on my list of things to read now; I am always up for learning new techniques...whether I use them or not is a different matter. At any rate, exception safety is not a C++ only problem. Any language that uses exceptions has exception safety issues and so far I haven't seen one that did any better than another in this regard. In comp.lang.java.advocacy, Remon van Vliet <remon@exmachina.nl> wrote on Thu, 27 Apr 2006 20:44:11 +0200 <44511104$0$31654$e4fe514c@news.xs4all.nl>: >>>> Mixing exception handling and memory management boggles the human >>>> mind. [quoted text clipped - 11 lines] > > What point am i missing if i mention the "finally" block in Java? "finally" is to RAII as manual transmission is to automatic, from the looks of things. Signature#191, ewill3@earthlink.net Windows Vista. Because it's time to refresh your hardware. Trust us. |
Enable EMail Alerts
Start New Thread
Reply to this Message