> At this point I think some people see "more effective" as > your opinion and how effective or not RAII is in this sort > of context depends a lot on the system architecture, > granularity of classes, etc. All the things you describe > can be done in C++.
I never meant to imply that this was not possible in C++. Clearly anything that is possible in Java can be done in C++. The point was that the lack of this feature is not the huge burden it is often purported to be. Unfortunately too few Java developers employ such techniques and resort to uglier solutions like depending on GC and finally blocks all over the code. This is the only solution to the issue that I know of in Java.
> In the case you describe I would say > that RAII buys you some insurance because in addition to > your own methods managing the connection, if things go to > hell in a handbasket the constructors should clean up the > resources anyway.
You can do that in Java with the destructors. They just don't fire immediately. But generally I use a fail-fast technique so if things go to hell, the app will generally die. I prefer that to spending days trying to repair corrupted data.
> > One problem with auto-pointers that I've heard > mentioned > > is that you can have a sudden pointer-tree collapse > that > > causes the application to stall. Is this a common > problem? > > I've never actually seen it. I can see how it can be done > if things are improperly scoped, but then I would think > this is indicative of a bigger problem. It would be a > symptom of, in my opinion, of a badly flawed design. > > Is there a reason something similar but much more subtle > couldn't happen in a java or C# app? A pointer collapse > would be caused by a root pointer being deallocated and > having its constituents not be allocated which would > result in leaked resources and all kinds of other > nastiness. If you disposed of a root class but still had > valid references to its constituents, wouldn't you > possibly end up with a case where the container got > garbage collected but you were able to still access > objects that used to belong to the container?
Memory leaks as they exist in C++ do not occur in Java. Or, if you prefer, they happen all the time. The precise condition for a memory leak in C++ is what makes an Object collectable in Java (I assume C#) is the same. You can't really dispose of a class per se (without getting into some really esoteric and proprietary stuff). There are a root set of references which IIRC are references currently on the stacks of all live threads or something like that. Anything that can be reached from these root references is 'reachable' and all other Objects are garbage.
So, yes, you can reach things where the original parent has been collected but there can't be any references to the parent so it can't cause an issue.
People will talk about 'memory leaks' in Java but really i believe the correct term is 'space leak' which is essentially that something is still reachable when it really should be collected. Unfortunately it takes a developer to make that distinction. Of course this can happen in C++ too.
> If that just > isn't possible, great. If it is, I could see that leading > to some really hard to diagnose and fix bugs whereas the > C++ app would most likely fail miserably. > > Which one of those outcomes can be argued to death and I > don't see one side convincing the other that their way is > "right". They are both bad. Personally I'd rather have the > dramatic crash and burn vs. the app limping along, but > that's just me. Don't waste your breath trying to convince > me otherwise. I've dealt with both situations too many > times to count and the dramatic crash and burn has, > without fail, been easier for me to diagnose and fix. The > users are more annoyed initially but their problems are > fixed much more quickly and in the long run, in my > experience, they have been happier.
I'm not sure which two outcomes you mean. The most common Java 'death exception' is a NullPointerException which no one really attempts to handle except in an application server or similar type of design where you are really running applications inside of applications and you can't crash the whole server because one crappy web-app fails. In any event a NullPointerException is exactly what it sounds like. Perhaps that's the kind of thing you are talking about?
> I can't believe this long discussion about nothing. > > I'll make it easy: > > "In thousands of years we still make wheels that break. > Why can't we make a wheel that doesn't break? Why do we > e have to reinvent it? Why can't we just invent the > perfect wheel? Wheels have been around for so long...what > is the problem? How do we fix it?"
Oh, you are right! The wheels on my car are just like ancient Egyptian chariot wheels! Absolutely indistinguishable! What were we thinking!?
> > > Because of the problem with RAII that you have still > > > failed to address. > > > ... which I still fail to see. > > The results. The results from the query have to survive > the scope of the connection. The results can be used from > 100 different points within the application. They are > basically cached. Not reference counted. When do they go > away? How do you avoid running out of memory? > > It's possible in C++ (I have written it .. many tens of > thousands of lines of code). > > It's a no-op in Java or C# or any other memory-managed > language. >
You know better than anyone else that the general issues of caching are not primarily a language thing. Neither Java nor C# make this a no-op or you would be out of business. There are garbage collectors for C++. There are caching frameworks for C++, so those tens of thousands of lines of code have already been written for reuse. You know very well, that garbage collection makes the most frequent and most simple cases easier, but it doesn't solve all the problems connected to the management of cached resources.
Having said that, I agree that garbage collection has made life easier. That's probably why C++ is used very often in combination with garbage collected scripting languages to write stuff that has to be very fast and where direct control of memory management is needed. Java takes that power away from us and that's one reason why the memory consumption of many Java apps is so outrageous. That's why the garbage collector needs to use processor cycles and a largeish memory cache to manage a huge number of heap allocated objects that should really have been allocated on the stack.
Using Java for software that processes a lot of data in memory is simply not productive. It's much easier to optimise memory consumption with C/C++ and there is a whole range of software where optimisation of memory use is crucial. There aren't many widely used DBMS or BI engines written in Java, and that's for a reason. I recently tried to optimise a special purpose query engine written in Java. The starting point in terms of memory was high and many hours of optimisation didn't release anywhere near the amount of memory that an ad hoc port to C++ delivered instantly.
For me, that only shows that BS's differntiation between systems programming and application programming still holds. Java is unfortunately somwhere in the middle. It's a bad systems programming language because it takes so much control over resources away from you. And it's a mediocre applications language because it doesn't have many features for high level abstraction that languages like Python do have, AND most surprisingly, it has absolutely awful string processing capabilities.
> Using Java for software that processes a lot of data in > memory is simply not productive. It's much easier to > optimise memory consumption with C/C++ and there is a > whole range of software where optimisation of memory use > is crucial. There aren't many widely used DBMS or BI > engines written in Java, and that's for a reason. I > recently tried to optimise a special purpose query engine > written in Java. The starting point in terms of memory was > high and many hours of optimisation didn't release > anywhere near the amount of memory that an ad hoc port to > C++ delivered instantly.
I've written and seen a good bit of Java and every time I've dealt with high memory consumption, it's been the fault of the developer or the design of the application. There is nothing inherent about Java that makes it use a lot of memory unless you consider the VM overhead to be a large amount of memory. I will agree that a lot of code written in Java consumes way more memory than is necessary (I've struggled with such programs myself.) I believe the problems you describe come from a number of really poor design ideas that were fomented during the early years of Java and have been questioned by far too few developers since.
> For me, that only shows that BS's differntiation between > systems programming and application programming still > holds. Java is unfortunately somwhere in the middle. It's > a bad systems programming language because it takes so > much control over resources away from you. And it's a > mediocre applications language because it doesn't have > many features for high level abstraction that languages > like Python do have, AND most surprisingly, it has > absolutely awful string processing capabilities.
I fully agree with this differentiation between systems and application programming, and also think that there is a big difference between "internal" applications and ones for the mass market.
As for Java, it is my impression that it is not the language itself that attracts enterprise application programmers, but rather the technologies that come with it.
> AND most surprisingly, it has > absolutely awful string processing capabilities.
Why do you say that they are awful? I would say that Java provides a great plethora of String utilities but I've found the regex library to perform fairly well.
> Having said that, I agree that garbage collection has made > life easier. That's probably why C++ is used very often in > combination with garbage collected scripting languages to > write stuff that has to be very fast and where direct > control of memory management is needed. Java takes that > power away from us and that's one reason why the memory > consumption of many Java apps is so outrageous.
You are repeating a common misconception. GC doesn't increase memory usage. The normal mode of a JVM is to use trade memory for performance. That is, as long as there is more available space, put off GC until there the load drops. If your app is using too much memory, you can just limit the maximum heap size and the GC will be forced to run when it hits the limit. If your app blows the heap at that lower limit, you either need to redesign or bump up the limit. It's not Java that does these things, it's the developer.
The biggest problem I find with a lot of Java apps and memory usage is that a loft of developers don't understand what makes something collectible. They spend a lot of time setting variables to null and think that's what will cause the Object to be collected. They also often think that running the GC more often will prevent OutOfMemoryExceptions, which is absolutely false except in very specific circumstances with concurrent collectors.
> That's why > the garbage collector needs to use processor cycles and a > largeish memory cache to manage a huge number of heap > allocated objects that should really have been allocated > on the stack.
This is also a little FUDish. Modern VMs use generational heaps such that searching is minimized. Short lived Objects cost almost nothing to create and destroy. This strategy also eliminates memory fragmentation as all Objects are (for most all intents and purposes) allocated in contiguous space.
One potential future feature of JVMs is escape detection which will enable stack allocation without any change to the language syntax.
> > AND most surprisingly, it has > > absolutely awful string processing capabilities. > > Why do you say that they are awful? I would say that Java > provides a great plethora of String utilities but I've > found the regex library to perform fairly well.
Typo:
I would not say that Java provides a great plethora...
> Using Java for software that processes a lot of data in > memory is simply not productive.
This is a very wide generalization that doesn't add much to the debate if it's not substantiated...
> It's much easier to > optimise memory consumption with C/C++
This ease comes at a very expensive price (manual memory management) that a lot of developers have a very hard time to keep under control. Not because they are bad developers, but because applications have become so complex these days with objects traveling back and forth between software layers, processes and sometimes CPU's and even machines, that manual memory management is sometimes simply not possible. Memory leaks can take down entire applications, and if the price to pay to solve this problem means that my applications will consume a little bit more memory, I'll gladly sign off on the purchase a few more memory sticks.
> and there is a > whole range of software where optimisation of memory use > is crucial.
I wouldn't call that range "wide".
> There aren't many widely used DBMS or BI > engines written in Java
Are you serious? JDBC, Hibernate and EJB3 are recognized as being the best DB bindings that were ever conceived to date (yes, even better than Active Record, that would come as a distant second).
And as Cameron mentioned earlier in this thread, the very nature of these frameworks means that objects retrieved through these layers can have arbitrarily long lifetimes, and managing their lifecycle manually is simply not an option.
> and that's for a reason. I > recently tried to optimise a special purpose query engine > written in Java. The starting point in terms of memory was > high and many hours of optimisation didn't release > anywhere near the amount of memory that an ad hoc port to > C++ delivered instantly.
Fine, but please don't generalize your experience on this particular project to the state of the art in Java object-relational mappings.
Cedric, it might seem like I'm going through this discussion and picking out your posts to comment on, but I'm really not. (I lazily look at the latest post and don't look back much further.)
> There aren't many widely used DBMS or BI > engines written in Java
Are you serious? JDBC, Hibernate and EJB3 are recognized as being the best DB bindings...
Seems like a simple misunderstanding - as you say JDBC, Hibernate and EJB3 are DB bindings - they are not DBMS or BI engines.
> > It's much easier to > > optimise memory consumption with C/C++ > > This ease comes at a very expensive price (manual memory > management) that a lot of developers have a very hard time > to keep under control. Not because they are bad > developers, but because applications have become so > complex these days with objects traveling back and forth > between software layers, processes and sometimes CPU's and > even machines, that manual memory management is sometimes > simply not possible. Memory leaks can take down entire > applications, and if the price to pay to solve this > problem means that my applications will consume a little > bit more memory, I'll gladly sign off on the purchase a > few more memory sticks. >
I will just repeat here what other C++ developers already said: you guys are still talking about 1990's C++. It is not only possible, but also very easy to automatically manage memory without a non-deterministic garbage collector, even in the most complex applications. Sometimes (depending on the design) the price is that you need to copy data a little more.
And you can't "gladly sign off on the purchase a few more memory sticks" if you are selling your software to the customers; that works only for internal development.
> Seems like a simple misunderstanding - as you say JDBC, > Hibernate and EJB3 are DB bindings - they are not > DBMS or BI engines.
My mistake. I'm not sure what BI is (Business Integration? Can you name a few examples?) but DBMS definitely fall in the category of software where every byte counts and where a programming language with manual memory management is probably the only reasonable option.
I might provide a reference for whether Java is appropriate for the task (I have no opinion either way.) I would propose that it's possible that no widely-used DBMS is written in Java because people believe it is not appropriate and not necessarily because it is true.
My wife is using a new tool that seems to have a really good engine under the hood but is constantly crashing because of what appears to be bugs in the gui. I have a sneaking suspicion that the gui is written in C++, because of the way it looks and especially because of the way it crashes (with illegal access problems.) Looking at this tool, there's absolutely no reason the gui should be written in C++. It could be written in VB or Java or whatever. But people do these things because they are so sure that C++ is the ultimate language.
On that thought, it seems to me that the people leaning towards Java in this discussion know a lot more about C++ than the people leaning towards C++ know about Java. I could be wrong but that's the impression I get.
> > I will just repeat here what other C++ developers > already > > said: you guys are still talking about 1990's C++. > > And 'you guys' are talking about 1997's Java.
I am not talking about Java at all (last worked with it in 2000) - just trying to explain some basic facts about modern C++.
Flat View: This topic has 212 replies
on 15 pages
[
«
|
789101112131415
|
»
]
Previous Topic
