Ion Gaztañaga
Posts: 8
Nickname: igaztanaga
Registered: Jan, 2006
|
|
Re: A Brief Look at C++0x
|
Posted: Jan 5, 2006 3:20 PM
|
|
> I don't think garbage collector is needed at all. > > It is badly needed, but it should be an option. In most > large projects, a great deal of effort is spent chasing > pointers. > > I think that breaks C++ constructor/destructor model > (when are the destructors called?) > > Why does it matter when destructors are called? when using > garbage collection, destructors become almost irrelevant > for heap allocated objects. After all, C++ has RAII, which > is a much better way to release resources than any > destructor.
Well, RAII uses the destructor to release resources. And if I create an object via new that allocates resources (opens a communication, opens a file, or any other thing) I want to destroy it when I want because I want to close the file. Otherwise I have to close it by hand, and that's very error prone. > and that new smart pointers can avoid nearly all manual > memory management > > No, smart pointers are not that good. First of all, they > are much slower than GC; secondly, you can not use smart > pointers in situations with circular references, and that > rules out a lot of data structures.
¿Much slower than GC? A lot of GC are based also on shared_ptr/weak_ptr scheme. And the language has to trigger the GC to start looking freeable objects. The difference is that I KNOW what is the cost of shared_ptr (atomic increment for every copy) and I can avoid those copies if in my code that's critical. The problem with GC is that I don't know what's going on. I agree that perhaps GC is very useful and productive, but since I'm used to manage memory by hand, I don't find memory allocation is a productive burden. And I DO think that almost all manual allocation can be avoided, when move semantics are added to the language + smart pointers. But manual does not mean that I lose control over allocation, I know what I'm doing, it's just I'm avoiding typing and avoiding usual errors. That's because I know what std::string does, what std::vector does, what std::shared_ptr does and most importantly I know WHEN.
Now imagine another resource: shared memory, a file, a communication device... There is no garbage collector for this. You have to close the file, you have to release shared memory, you have to close the device. And there is no GC collecting open files to close them. Memory is just another resource that in C++ I can control uniformly using RAII, destructors or another scheme.
> And memory is not the only resource you have to manage, > so I don't know if garbage collector overhead is > justified. > > One of the best things in C++ is RAII...and that's because > C++ allows objects to live on the stack. When asking for > garbage collection, I do not mean that stack based > allocation should be abolished.
In my experience with languages with garbage collectors usually the perfomance is worse and the memory use, higher. Many times happens the same with manual management. But there is a difference in C++: I know what's happening. And I think that I can do it better than the GC (I'm not joking). Maybe some starter or medium programmers produces less buggier programs with GC, but when you know when memory is being allocated, and what the language is doing with every statement, no GC can't beat that.
For example: Java has garbage collector. I really think that you can do efficient programs in Java. But that isn't the norm. You just have to know where the performance win is. But since GC is going its own way, in another thread, enters when it wants (or in a low priority thread) you can't control that. You don't know if assigning a variable is allocating heap memory (and even less when is releasing it). Is not about features, it's about control. That's way every Java program I try needs huge memory quantities. And that really annoys me, because your program is not alone in the computer. If every program uses that much memory we could only start 10 processes in a computer. We are not alone in the world, and our application is not the only one running in the computer.
I'm not talking about benchmarks. Just take a text processor, a P2P client, a browser. Every Java program I use gets me sick because of the huge amount of resources it needs. There are unefficient C++ programs, but I can always find an efficient alternative. It's not about the programming language. I repeat: I'm sure you can program efficiently in Java. It's a problem of programmers. It's a problem of control. You know what's happening behind the curtains. You don't pay for you don't use. If you don't think about allocations, you lose control. And your program suffers, because memory allocation is not free. Maybe you will be more productive (but I doubt it if you are an experienced C++ programmer), and that can be fine in many areas, but not in others.
> I think C++ has a bright future > > In my company (more than 30 programmers), I am the only > one that knows and supports C++. There are some other guys > that knew C++, but have abandoned it...and having > participated in Java projects, I can tell you that > development with Java is waaay faster than C++...in fact, > experienced programmers usually get the code right in > their first try, something that is much less feasible in > C++...and there is much less headaches with Java on > finding libraries.
In my company everyone compiles in C++. Everyone. Some come from Java world. It's because we don't do web applications? Maybe yes. But we have programmers that can do web applications and program also embedded processors, using just a single language: C++. And do it efficienly. And some universities around here who changed from C++ to Java are now teaching C++ again, because they feel that students can't understand some basic programming concepts with Java.
We just need libraries. LOTS of them. That's the difference with Java/.NET. And I think we are doing great efforts with Boost.
|
|