On 23/09/2007, Dmitry Potapov <dpotapov@xxxxxxxxxx> wrote: > On Sun, Sep 23, 2007 at 09:54:10AM -0700, Linus Torvalds wrote: > > The same goes for things like memory allocation. Memory allocation issues > > are often some of the *biggest* performance issues, and that means that > > they have to be explicit. I'm actually a big fan of GC, but most languages > > that implement GC do it exactly the wrong way in my opinion: they make it > > a fundamental thing that covers everything, and it all happens implicitly, > > instead of making it explicit. > > Stroustrup was not a big fan of GC, so he made the language to be useful > in absence of any GC, and it allows to manage memory and some other > resources though not automatically, but with much less efforts than in C. The next version of C++ is going to have garbage collection that the user can enable, disable or remain neutral about. However, this is program-wide and has many traps that you could fall into. > > But other parts of C++ are just nasty. The whole OO layer seems designed > > to do a lot of things implicitly and in the wrong way. > > It could do a lot of things implicitly, but it does not force you, > except calling destructor when the control leaves the scope of > declaration, but I hardly can consider it as implicit. You have to add the explicit keyword to any constructor to prevent an automatic conversion. Therefore, the constructors that are called are implicit by default. If you have a conversion operator, this is always implicitly called when there is a match by the compiler. I agree with Linus here, there are a lot of things that happen implicily. > > I also disagree with exception handling, > > Perhaps, you look at it from the kernel point of view. Otherwise, I > would like to hear your arguments against it. In fact, I don't think > it is possible to write generic algorithms without exceptions. Of > course, if you write a program that can print an error to stderr and > exit, there is no much need for them. So, it may depend on the task. There are many issues with exceptions. Firstly, there is throwing an exception from a destructor, which is warned against in any good C++ book, but does not prevent you from doing so (even if it is inadvertantly)! If the program is in the process of handling an exception, the program is toast. More importantly though, is the loss of contextual information. Consider throwing the same exception on all calls to API that return the same error code type. The code that processes this may be anywhere in the system. This makes it impossible to do any sensible recovery (if possible), or error reporting. The exception can be rethrown or translated to another exception, making it impossible to find the originator of the exception. This makes it harder, if not impossible, to track the exception back to the source when you are at a breakpoint in the exception handler. Then there is dealing with caller boundaries. That is, when a callback or interface function in the application will return to the operating system (e.g. when handling a draw request from X11), or another language such as Python. Also, because different compiler vendors and versions handle exceptions differently, if you want to support different compilers (and you have resolved the name mangling incompatibilities), you need to handle exceptions correctly in these cases, or risk having major problems that would be impossible to trace. Not to mention that anywhere new, dynamic_cast and other language features are used may throw exceptions. - Reece - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
