Slashdot Mirror

I want to like C++, heck, it was the first language I learned. But after so many hours of memory leaks and pointer-induced errors...

perhaps you didn't learn it very well. Check out RAII for one way round your problem, learn about references and destructors for another, and learn about auto_ptr/shared_ptr if you still have difficulties.

If you absolutely must have a GC, put one in. Mono uses this one, so I assume they think its quite good. Stroustrup says that GC has a place in memory management, but it should be the last resort not the first. I agree - if you can't program without getting so lost you lose memory all over the place, GC will not magically help you* as you'll end up losing track of other non-memory resources instead**.

* - unless you're an ex-VB programmer, in which case you need all the help you can get :-)

** - eg. you create an object that opens a file, if you 'leak' that object, the GC will collect it for you when it feels like it, so you may end up trying to reopen that file only to find that its still in use. There's still 'soft leaks' that the GC will not manage where your objects are still referenced even though you think they aren't.

If they really are dying... I'd say only one thing:

FINALLY!

There is no finally! That's what destructors and the RAII idiom are for, duh.

If you can't correctly manage memory in C++, it's pretty much guaranteed you can't write a sychronization correct multithreaded application.

Amen!

To add to that: If you can't correctly manage memory in C++, you probably can't correctly manage any other resources an average program has to deal with:

• open file handles (close when you're done)
• open network connections (close when you're done)
• database connections (close when you're done) or transactions (always commit or rollback, regardless of exit path)
• external temporary files (unlink when you're done)
• external configuration files (more complex, because you need transactional programming: what if your program crashes while you're re-writing the config file?)

Python and C++ (and probably Perl), make these tasks easy by using deterministic object destruction (RAII FTW!). In Java, this is about the same level of complexity as malloc/new and free/delete, so you're back to square one on resource management.

Java will exceed the speed of a C++ program in many cases nowadays. I worked for a large insurance company and we had to prove to them using benchmarks that Java was faster.

Yes... and I was implicitly asking readers to provide me with better information... which you sort-of have. But I'd really like to be able to see some side-by-side comparisons (if one isn't strictly faster than the other, then where are the differences showing up?).

You're avoiding the issues of real-world development also. What is the expense of a memory leak? You can claim that they also can exist in Java but as we all know in C++ they are a constant problem--especially for the newbie programmers.

No, I believe I explicitly addressed that the strengths of Java weren't technical strengths. We're agreeing on this point, really. Though, I am a firm believer in the RAII idiom in C++, which really makes C++ a lot simpler once you get used to it... but yes, it's a higher bar to start with, especially for newbie programmers. And it's certainly something I never heard about in school (whereas I learned about garbage collection algorithms as a freshman).

Are you proud that it's so easy to create a memory leak in C++?

Nope. But there are strengths to using C++'s model that Java users tend to ignore. RAII allows you to manage any resources, not just memory. I think Python has the best setup, though: garbage collection with deterministic destruction, which lets you use RAII without forcing you to manage your memory (though you still have to think about it, since the GC isn't as advanced as Java's, and gets stuck on cycles when destructors exist unless you explicitly use weak references, IIRC).

90% of the time, when you call an init() function, you're going to call a free() function too. Let C++ do the grunt work for you. Use the RAII pattern.

Heck I don't even like C++ for fogging-over-functionality with inheritance, virtual functions and overloading.

You don't have to use those C++ features if you don't want to. You can program in C-style in C++ if you wish. virtual and inheritance are optional. These days templates do most of what inheritance and virtual functions can do. And I don't understand why you would dislike overloading. Aren't you tired of thinking up names for functions that do the same thing, but just take different number of arguments?

You didn't say that. You explicitely said that you have never seen a java app with lots of casts. Don't try to change what you've said.

What I did say was "can't imagine a Java program full of casts" meaning casts on every line or near that. If I wasn't clear I apologize but I'm not changing things here.
About RAII, yes it's not applicable to Java or other GC languages. But if you can write a C++ program without memory leaks you will have no problem closing every resource :-) Seriously, this may require a redesign depending of how resources are managed.

And why is it a drawback?

Because if there are less people trained to do a thing you have to search harder/pay more/train more before things get done. OTOH Java have this problem also, just there is a difference in the class of knowledge usually found on each language.
On your example I agree with you on that there are apps that are better (or easier, or even could only be) implemented in the other language (be Java, C++ or basic). I'm just not ruling out that someone else could make an implementation that works good enough to satisfy the requirements in language X (where X could be Java).

fortran
I'm not a Fortran programmer, if you say so, let it be.

Java is good in numerical computation
I don't understand what is your point here. You first seemed to support the idea that Java was to slow to do this, now the opossite. Or where just mentioning the article? I'm a little lost here.

Eventually, Java will be equal to C++
I think that Java will always be slower (even a little) than C++. But I remember when most programs were made in assembler and C was the slow new language. C winned in the because it was easier (that subjetive concept) to write programs in, rather that because of it's speed.

there are very good garbage collectors for C++
While automatic GC is possible in C++ I don't found the concept appealing. C++ just wasn't designed for this.

Garbage Collection is not necessarily incompatible with RAII.

If the only way in which objects are destroyed is through an unpredictable garbage collector then yes, RAII isn't possible.

If you have reference-counting based garbage collection then RAII is possible (though reference-counting brings its own issues).

If you have garbage collection for heap objects, but automatic collection for stack objects then RAII is possible (and indeed little different to RAII in plain C++).

C#'s garbage collection rules out RAII per se, but the same techniques can be transferred into its use of "using" statements like in this RAII article's note on .NET