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

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.

quoted

quoted

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.

quoted

quoted

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