On Sun, Sep 23, 2007 at 11:25:01PM +0100, Reece Dunn wrote: > 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. Sure. C++ has not been design to be garbage collection friendly, in fact, even now, you can use some GC with C++, but it can be painful. I don't think that the new standard will change much in this respect. > > > 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. Yes, I would prefer if it were opposite by default, but it was an initial mistake in design, and you cannot change it without breaking a lot of people code. > If you have a conversion operator, this is always > implicitly called when there is a match by the compiler. Conversation operator should be written only if you do want an implicit conversation, and that may be useful sometimes, albeit very rarely. > > 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)! In general, the compiler does not have all information to know whether a destructor can or cannot throw an exception, and even less it knows about your real intentions. There are many ways to write something that will not work. You can create an infinite recursion, but I don't think it is a good argument against recursion. > > More importantly though, is the loss of contextual information. Do you think that an error code contains much more contextual information? > Consider throwing the same exception on all calls to API that return > the same error code type. I did not mean that all error codes should be returned as an exception. Exception in C++ is something that should not normally happen, like failure to allocate memory. So, you usually do not want to handle this situation immediate. > 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. In gdb, you can catch all exception when thrown using "catch throw". And again, I don't see how it is better when a program returns an error code, especially if this error code is recoded couple times in the process of returning. So the problem is not with exceptions, but usually with bad design. > 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. You named some interoperability issues with C++ (and there are many of them), but it is not an argument against exceptions per se. > Not to mention that anywhere new, dynamic_cast and other > language features are used may throw exceptions. dynamic_cast throws an exception only for references, but not for pointers, and there is a good reason for that -- references should not be NULL; and if you want to avoid bad_alloc exception, you can use "T* p = new (std::nothrow) T;" but it is rarely needed. Dmitry Potapov - 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
