Re: [OT] Re: C++ *for Git*

["Reece Dunn" <msclrhd@googlemail.com>]

On 23/09/2007, Dmitry Potapov <dpotapov@nbs-eng.ru> 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