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

David Brown [off-list ref] writes:

On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:

quoted

On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:

quoted

I'd say being forced to be explicit is a good thing here, so that the
programmer at least has some sort of good understanding of what is
going on, and chances are that if he doesn't really know, things just
won't work out (quite unlike a lot of other languages where this
programmer might actually end up with something half-assed that
"mostly" works).
For some reason it seems to me a lot harder to find bad programmers
surviving using C than a lot of the other languages.

Idiot-proofness-by-complexity is a myth IMHO. Idiots can be quite
persistent...

I work with plenty of them :-) It's all C.  All of the same things
happen, with management looking for magic bullets to solve problems
caused by bad programmers.

C++ is good for creating black boxes.  A black box that has been
fitted into its environment and that has good innards is fine.  A
black box with rotten innards, or not really being well-suited for the
job at hand, isn't.  For a project where people come and go, black
boxes might hide a lot about bad design and implementation.

In particular, changing an algorithm to require different black boxes
is something that is very unpleasant to do.

Having everything in the open is an advantage as long as the
complexity to be managed is at a reasonable level.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

On 9/23/07, David Kastrup [off-list ref] wrote:

David Brown [off-list ref] writes:

quoted

On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:

quoted

On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:

quoted

I'd say being forced to be explicit is a good thing here, so that the
programmer at least has some sort of good understanding of what is
going on, and chances are that if he doesn't really know, things just
won't work out (quite unlike a lot of other languages where this
programmer might actually end up with something half-assed that
"mostly" works).
For some reason it seems to me a lot harder to find bad programmers
surviving using C than a lot of the other languages.

Well, according to your reasoning assembly should be the gotha of
elite programmers, only very disciplined and meticulous programmers
survive, much more then in C.

Is this a good way to measure a language?

C++ is good for creating black boxes.

Object oriented languages creates black boxes: that's the reason why
object oriented exsists and also the reason why Linus hates it ;-)

Difference between C++ and other OO languages is mostly in the size of
the applications written in that language IMHO.

C++ noramlly has the bigger code bases, so problem you mention are
enanched and perhaps seem to depend on the language itself not on the
size of application. IOW a Python (Ruby) app probably does not have
the size of Firefox or Open Office, this _could_ induce the naive idea
that the python app is cleaner or easier to understand just becasue of
Python vc C++.

I really don't think so. I think this could be true for toy problems,
but for real, for big applications is the design of the appllcation,
not the language, that at 90% state the difference between clean and
crap.

A black box that has been
fitted into its environment and that has good innards is fine.  A
black box with rotten innards, or not really being well-suited for the
job at hand, isn't.

I really agree here. The biggset downside of OO is that for it to work
you should have a much deeper knowledge of the problem you want to
handle. OO force you to analyze more and know more because a bad
design normally means throwing everything in the trash can and start
again.

Procedural programming as C is more immune to this 'good problem
analysis'  dependency.

Marco

On Sun, Sep 23, 2007 at 09:29:45AM +0000, Marco Costalba wrote:

On 9/23/07, David Kastrup [off-list ref] wrote:

quoted

David Brown [off-list ref] writes:

quoted

On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:

quoted

On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:

quoted

I'd say being forced to be explicit is a good thing here, so that the
programmer at least has some sort of good understanding of what is
going on, and chances are that if he doesn't really know, things just
won't work out (quite unlike a lot of other languages where this
programmer might actually end up with something half-assed that
"mostly" works).
For some reason it seems to me a lot harder to find bad programmers
surviving using C than a lot of the other languages.

Well, according to your reasoning assembly should be the gotha of
elite programmers, only very disciplined and meticulous programmers
survive, much more then in C.

  This non argument was raised before in the recent thread we just had.
Could we at least wait say, a month, before spawning the same trolls
again and again ?

quoted

C++ is good for creating black boxes.

Object oriented languages creates black boxes: that's the reason why
object oriented exsists and also the reason why Linus hates it ;-)

  This is just nonsense. This has been proved, though I can't find the
paper about this anymore, than modules (or packages whichever name you
give them) plus abstract types are as good as OO languages at creating
black boxes. I mean it has been proved that it gives the exact same
amount of expressiveness. So please stop with this myth. And don't speak
for people, I would be very surprised that Linus would dislike "black
boxes". Abstractions are good, when used wisely, and I would be much
surprised to see Linus pretend otherwise.

  The real problem with big applications, is not that they are written
with C, C++, D, APL or Perl, but that they are big. Most of the time,
big means that many people are not able to grok the big picture, and you
end up with 102 implementations of base64, 10 string libraries, 4
general purpose buffers, and at least half of the common lisp
features[0]. And for the record git is _not_ big. It's around 100k
slocs, which rougly the size of postfix or mutt.

  I for one do believe that bad programmers will write bad code
whichever language they use, and that what is wrong is to end with code
bases in one monolithic thing like in [1]. OO design patterns and other
craps of the like helps you generate insane amount of codelines, and
hide all the simplicity under huge loads of proxies and interfaces. In
C, when your API suck, you usually need to refactor it under the
pressure of the huge amount of code you have to repeat each time you use
the API. in an OO language, you add a new class for that purpose. In C++
it's even worse, you just hide it in a copy constructor, or an operator
so that when you write:

  Foo a = b;

  Instead of a simple memcpy, you end up with an horrible pile of crap
to be started and run behind your back. C++ is very good at hiding bad
code. At least in C, when someone writes bad code, it's obvious to any
reader. C has many many quirks, I don't discuss that, but OO programming
solves none of them, and the problems OO addresses are not the one that
may interfere in the git development. I mean, the two really interesting
things in OO (that haven't a tremendous cost in return) are member
overloading and inheritance. I see very few places where git would
benefit from that, and believe me, I looked at git's code with
refactoring in mind and only that.

  Can we go back to git now ?



  [0] http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule

  [1] http://www.ohloh.net/projects/29/analyses/latest

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

On 9/23/07, Pierre Habouzit [off-list ref] wrote:

quoted

Object oriented languages creates black boxes: that's the reason why
object oriented exsists and also the reason why Linus hates it ;-)

  This is just nonsense. This has been proved, though I can't find the
paper about this anymore, than modules (or packages whichever name you
give them) plus abstract types are as good as OO languages at creating
black boxes. I mean it has been proved that it gives the exact same
amount of expressiveness. So please stop with this myth. And don't speak
for people, I would be very surprised that Linus would dislike "black
boxes". Abstractions are good, when used wisely, and I would be much
surprised to see Linus pretend otherwise.

From a Linus recent thread:

- inefficient abstracted programming models where two years down the road
 you notice that some abstraction wasn't very efficient, but now all
  your code depends on all the nice object models around it, and you
  cannot fix it without rewriting your app.

In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.

Perhaps I have misunderstood, but the idea I got is that for Linus OO
brings in more problems than what it tries to fix.

  The real problem with big applications, is not that they are written
with C, C++, D, APL or Perl, but that they are big.

I have said exactly this, I don't understand where's your point in
repeating the same concept.

C has many many quirks, I don't discuss that, but OO programming
solves none of them, and the problems OO addresses are not the one that
may interfere in the git development.

I really don't get how you made up your mind I'm advocating OO ? The
only comment I made on OO until now was to highlight one of its
downsides.

I mean, the two really interesting
things in OO (that haven't a tremendous cost in return) are member
overloading and inheritance.

You have listed two things that are a world apart one from each other.

member overload is just syntactic sugar for name mangling, while
inheritance and the _strictly_ related virtual member functions (AKA
polymorphism) is what opens the gates to all the stuff you have deeply
blamed in your post.

I see very few places where git would
benefit from that

Instead I see none. But probably you have looked at git code better then me.

  Can we go back to git now ?

You are not forced to follow this thread if this bores you.

Thanks
Marco

On Sun, 23 Sep 2007, Marco Costalba wrote:

From a Linus recent thread:

quoted

- inefficient abstracted programming models where two years down the road
 you notice that some abstraction wasn't very efficient, but now all
  your code depends on all the nice object models around it, and you
  cannot fix it without rewriting your app.

In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.

Perhaps I have misunderstood, but the idea I got is that for Linus OO
brings in more problems than what it tries to fix.

You must have misunderstood.  Why?  The linux kernel is itself very 
heavily "object oriented" already, even if it is written in C.  You 
don't need C++ for that.


Nicolas

On 9/23/07, Nicolas Pitre [off-list ref] wrote:

You must have misunderstood.  Why?  The linux kernel is itself very
heavily "object oriented" already, even if it is written in C.  You
don't need C++ for that.

Yes it's true, you don't need it. Object oriented in C is achived
using function pointers.

In C you fill a struct of function pointers with proper values instead
of inherithing from an (abstract) base class as you would do in C++.
The results are more or less the same modulo some type safe.


Marco

On Sun, 23 Sep 2007, Marco Costalba wrote:

Perhaps I have misunderstood, but the idea I got is that for Linus OO
brings in more problems than what it tries to fix.

Not really.

I'm a huge believer in OO, and if you look at the kernel, for example, 
there's just a ton of interfaces that are basically object-oriented. All 
the VFS is, for example, is really just a object model around low-level 
filesystems. The same largely goes for virtual memory mappings, or indeed 
for things like the interrupt or DMA controller abstractions, the network 
packet filtering etc etc etc.

But I'm also a huge believer in *explicit*syntax*. People should see what 
is going on, and the abstraction should be explicit.

[ Honesty in advertising: we do end up often hiding *some* abstractions. 

  Sometimes it happens for historical reasons: if the code didn't have any 
  indirection/abstraction initially, we may end up using macros and inline 
  functions to hide the fact that it now is actually going through an 
  indirect object-oriented interface.

  And sometimes it happens because the thing is *so* common or *so* 
  obvious that making the indirection explicit is just syntactically too 
  intrusive. ]

And we do all of this in C. There is no need to go to C++ for any "object 
oriented principles". It really is just a syntactic issue, and in many 
ways the syntax "advantage" of C++ is actually a big *disadvantage*.

I'm one of those people who think that interactions should be *locally* 
visible. If you need to understand the "big picture" in order to 
understand what a line of code does, that's usually a bad idea. So 
syntactic tricks that hide what is actually going on are bad.

You can see some of my opinions on C in the extensions I did for sparse. I 
think the C type system is a bit too sloppy, and much of what sparse does 
is more totally static type checking. Things like being able to decorate 
types statically, and having to explicitly carry those decorations around 
is a *good* thing - because it does the opposite of hiding. Having to say

	struct somestruct __user *p

to explicitly say that it's a pointer to user space - and then having 
every function that takes that pointer have to have that "__user" there is 
a VERY GOOD THING.

That's very different from having "accessor functions" and making "p" an 
abstract type, and having the compiler automatically generate the right 
kind of access. That kind of stuff is TOTAL CRAP, and it's an example of 
how C++ has a horrible design, where you carry around _implicit_ knowledge 
instead of making the knowledge explicit and visible locally too.

(And no, C doesn't do it very well. The C type system makes it too hard to 
add explicit markers that get statically checked, and you generally have 
to do it by making the code unreadable by turning things into special 
structures, one for each use, or something like that).

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.

I don't know how many people have noticed that git internally actually 
does do some garbage collection. It's just that we call it "caches", and 
we do it explicitly. I'd love to have a language that helps me with that, 
but I would *hate* to have a language that does it for everything. As it 
is, we *could* do garbage collection much more, but we don't, just because 
it's a bit too painful.

In practice, it means that I'm considering writing some helper routines in 
C, which actually would do exactly what I want them to do: make the 
(reasonably few) data structures that want to have a dynamic cache use 
that dynamic cache explicitly, the way we now do for delta caching etc.

There are a few features of C++ that I really really like. For example, I 
think the C preprocessor is absolutely horrid, and a preprocessor that is 
built into the language - and integrates with the syntax - would be 
wonderful. And while C++ doesn't improve on that, at least templates are 
an example of something like that. Not perfect, but that's the kind of 
feature that C really would like.

In the kernel, we (ab-)use the C preprocessor a lot for things like that. 
Some of our macros are really disgusting. I'm not proud, but it works 
well, and together with gcc extensions like "__typeof__" and thigns like 
"__builtin_constant_p()" you can do some rather powerful things.

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. I also disagree 
with exception handling, and the "new" keyword kind of exemplifies a lot 
of what is wrong in C++.

So in short:

 - the one big feature that I think really makes a huge difference to 
   people, C++ does not have: garbage collection. Yes, there are GC 
   modules, but let's face it, you can do that equally well in C too, it's 
   just slightly different syntax.

 - the stuff C++ *does* have is usually nasty. Implicit initializers and 
   destructors and the magic lifetime rules of objects etc are all just a 
   piece of incredible bogosity. And that all comes from the OO stuff that 
   is totally worthless, because it's really just syntactic fluff that can 
   be done easily in C.

 - the C preprocessor really is horrible, and every single language beats 
   C handily in this area. Except for C++, which didn't fix anything at 
   all in that area.

   Even assemblers have macro languages that allow conditionals, 
   repetition, nesting, etc etc.  C and C++? Not so much. (Some languages 
   don't need it, because the language itself is dynamic and you can do 
   everything from within the language - ie you just evaluate an 
   expression that you built up dynamically as in LISP etc).

   (And don't tell me about m4. It's a better preprocessor, but it's not 
   syntactically integrated, and it's too complex, imho)

There are other problems in C. The implicit type conversions should at 
least have some way to be disabled on a type-for-type basis.

		Linus

On 9/23/07, Linus Torvalds [off-list ref] wrote:

There are a few features of C++ that I really really like. For example, I
think the C preprocessor is absolutely horrid, and a preprocessor that is
built into the language - and integrates with the syntax - would be
wonderful. And while C++ doesn't improve on that, at least templates are
an example of something like that. Not perfect, but that's the kind of
feature that C really would like.

Yes, I really agree. IMO templates are the thing that more resembles
procedural programming, a common way of using them is to split data
structures (containers) from functions that operates on them
(algorithms). I find them very similar to the struct + functions
classical approach of C.

And BTW

template <typename T>

is the thing in C++ that more remembers me of opaque pointers and
their use in C, the difference is that the first is fully type
checked.

Marco

On Sun, Sep 23, 2007 at 09:54:10AM -0700, Linus Torvalds wrote:

And we do all of this in C. There is no need to go to C++ for any "object 
oriented principles". It really is just a syntactic issue, and in many 
ways the syntax "advantage" of C++ is actually a big *disadvantage*.

Certainly, in this respect, C++ provides only syntactic sugar over C,
and there is a real danger of abuse, which leads to horrible programs.
This is especially likely to happen to those who think that the evil
of C++ is lying in templates, exceptions, or something other feature
of C++, because they start to abuse the only "good" feature they know
and inevitably end up with horrible code.

	struct somestruct __user *p

to explicitly say that it's a pointer to user space - and then having 
every function that takes that pointer have to have that "__user" there is 
a VERY GOOD THING.

user_ptr<somestruct> p;

That's very different from having "accessor functions" and making "p" an 
abstract type, and having the compiler automatically generate the right 
kind of access. That kind of stuff is TOTAL CRAP, and it's an example of 
how C++ has a horrible design, where you carry around _implicit_ knowledge 
instead of making the knowledge explicit and visible locally too.

Whether it will convert to something or not depends entirely on the
definition of user_ptr. So, it can be as explicit as you wish, or
completely implicit. C++ does not impose anything on you here. So,
the problem is not in C++ but in the crappy mentality -- "let's hide
everything behind 'higher' abstraction" or "let's hide this thing too
because we can". Yes, these people end up with total crap. And yes,
those people tend to prefer C++ over C, just because C++ is better at
hiding. But I don't think that C++ forces anyone to do that...

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.

Maybe, your idea of more explicit GC is better than what C++ offers. It
is difficult for me to say without trying, but as you said most languages
implement GC in the wrong way in your opinion, so I don't think I will
have a chance to try any language that does it right. As to "caches" in
Git, it works really nicely, but Git is not a programming language.

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.

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.

 - the stuff C++ *does* have is usually nasty. Implicit initializers and 
   destructors and the magic lifetime rules of objects etc

I am not sure what is wrong with initializers and destructors in C++,
but certainly there is no magic lifetime rules in C++, as it is fully
determined by the scope. In fact, other high level languages that use
GC have much more unpredictable lifetime rules for objects.


Dmitry Potapov

PS Please, do not confuse me with Dmitry Kakurin, who started this
thread, because my position is opposite to his. Though I like C++,
I fully understand most of your consideration in choosing C for Git.

On 23/09/2007, Dmitry Potapov [off-list ref] wrote:

On Sun, Sep 23, 2007 at 09:54:10AM -0700, Linus Torvalds wrote:

quoted

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.

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. 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.

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)! 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

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