C++ *for Git*

We've had this theoretical (and IMHO pointless) discussion C vs. C++ *in general*. In no way I want to restart it. But *very specifically*, and *for Git*: We already have strbuf "class" to do string/buffer manipulations. Kudos to Pierre Habouzit for doing the refactoring work! Now, what I fail to understand is how this:

static void write_global_extended_header(const unsigned char *sha1)
{
    struct strbuf ext_header;

    strbuf_init(&ext_header, 0);
    strbuf_append_ext_header(&ext_header, "comment", sha1_to_hex(sha1), 40);
    write_entry(NULL, NULL, 0, ext_header.buf, ext_header.len);
    strbuf_release(&ext_header);
}

is better than this:

static void write_global_extended_header(const unsigned char *sha1)
{
    strbuf ext_header;

    ext_header.append_ext_header("comment", sha1_to_hex(sha1), 40);
    write_entry(NULL, NULL, 0, ext_header.buf, ext_header.len);
}

?
Note, there is no Boost/multiple inheritance/template 
metaprogramming/std::string/whatever-else-scares-you-in-C++ in the second 
piece of code.
Just a very straight-forward usage of only 3 C++ features:
1. Constructors
2. Destructors
3. Better syntax (ext_header.append_ext_header vs. 
strbuf_append_ext_header(&ext_header, )

The generated code will be exactly the same. Yet the source code becomes more readable and MUCH less error prone. How is this not a win?

One (sensible) argument that I've heard in the previous discussion was: you let a little bit of C++ in and then it gets more and more complex and the code quality decreases. This problem is solved by having "quality gates". Again, *for Git* these quality gates already exist: only few people have "commit access". If/when somebody tries to be too fancy, what stops Junio from replying "we don't use Library-X/C++-feature-Y in Git, please change your code and resubmit" and throwing that fix away? Nothing.

- Dmitry

Dmitry Kakurin <dmitry.kakurin@gmail.com> writes:

Then don't.

It won't. It will _do_ exactly the same (modulo the tenfold likelihood of compiler bugs) but hardly using the same code.

Because it is just your claim that this is more readable.

Well, what stops him from replying "we don't use C++ in Git, please change your code and resubmit"?

Hi,

On Sat, 22 Sep 2007, Dmitry Kakurin wrote:

I think "pointless" is more to the point.

We don't want C++.  Why is that so hard to accept?

Ciao, Dscho

On 9/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Dmitry, I think what Johannes says in the above line is 100% the core point of this (sad) discussion.

You cannot force/convince someone to use something he hates. That's it. And there's no point in trying to do this.

git developers were also kind enough to give explanations on 'why' C++ is not a good language for them. Do you don't agree? do you find the arguments not totally satisfying for you? That's not their problem.

I like C++ (a my little git related GUI tool called qgit is done in C++) and at the same time I understand also much of the concerns that where expressed in the list.

Your position will never be successful for a number of reasons, some clear expressed other less clear but at the same time, perhaps more important. So I really don't understand why you insist.

Thanks Marco

P.S: The example you show is a pity for C++, it's like to advertise a 1000cc 200Hp motorbike saying "...and you will no have problems in parking in your box."

On 9/22/07, Marco Costalba <mcostalba@gmail.com> wrote:

Actually after a couple of responses to this thread I had a BFO (Blinding Flash of Obvious). I cannot believe I was so naive :-). Now I have my answer.

P.S. Mysteries like this could drive me crazy. Now I'm much happier.

You know, git *is* free software. Feel free to fork it and add all the C++ code you want.

FWIW, I am of the opinion that Python or Ruby (or god forbid, Perl) would have been a better choice for something like git that does lots of text processing... furthermore, I think the exception handling, garbage collection, and implicit object destruction provided by those languages (and by C++, as overwrought as it is) makes any codebase easier to understand and maintain.

But that's irrelevant: git is written in C. That's the way it is, and you should accept that or fork.

Kyle

Dmitry Kakurin wrote:

Kyle Rose <krose@krose.org> writes:

Of course, some of the most horrid unreadable source code I've ever seen is in one of git's competitors -- written in python....

-Miles

Miles Bader wrote:

Indeed. :-)

At the office, people constantly badmouth Perl, which has some admittedly evil syntax (especially around exception handling). My view is that good Perl programmers can produce good, readable, maintainable Perl programs, while bad Perl programmers can produce spaghetti the likes of which can't be found outside Italy.

OTOH, I think it is much harder to hang one's self with Python, though admittedly possible, as it is when you combine a bad coder with *any* language. Still, typical bad programmer + Perl is much worse than typical bad programmer + Python.

C++ is in the same category as Perl IMO: too easy to produce unreadable code. I contend that C is pretty much just as bad, though in a different way: while C lacks C++'s ability to bury code in multiple layers of opaque abstractions, C makes up for it by providing absolutely no GC-type structures (i.e., I do this now, you clean it up later when I'm no longer interested in it). C is all explicit, which is nice when you have a good handle on everything that is going on *or* an explicit system for remembering to do those types of cleanup tasks that is well-understood by all developers involved.

I like Ruby, except for the performance problems. Once they have those worked out, Ruby will be "Perl done right." ;-)

Kyle

Kyle Rose <krose@krose.org> writes:

Since Perl has agglomerated pretty much _every_ syntax, it is not surprising that evil syntax is included.

Not quite. Perl gives you a hundred illegible ways to _say_ the same thing, C++ gives you a hundred illegible ways to _achieve_ the same thing, but using different means.

Ruby again is in the "throw every syntactical idiom I can think of together" ballpark. I find that a design mistake in Perl, a design mistake in Ruby, and even in C++ (Ada syntax for templates was just stupid, but at least there is no alternative syntax for it).

That's one of the things I like about Lua: its syntax fits on one page in the reference manual. And the reference manual has a paper size of about A5. While the syntax for Lisp would probably fit in the margin, it does so at a cost in legibility.

On 9/22/07, Kyle Rose <krose@krose.org> wrote:

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.

Alex

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

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

Gruesse,

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

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.

Dave

David Brown <git@davidb.org> writes:

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.

On 9/23/07, David Kastrup <dak@gnu.org> wrote:

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?

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.

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

"Marco Costalba" <mcostalba@gmail.com> writes:

Who is "you"? You are replying to a post of mine, yet commenting on Alex.

I am neither disciplined nor meticulous, yet have designed and programmed applications and complete systems in assembly language. Programmers can easily survive assembly language without being disciplined or meticulous. Their projects can't: they get tied to the programmers. Porting an assembly language application to a different processor might be easier than porting it to another programmer.

It is a good way to measure programmers, at least concerning some interesting metrics.

On 9/23/07, David Kastrup <dak@gnu.org> wrote:

Sorry, you are right, I'm not meticolus either ;-)

Marco

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

  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 ?

  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

On 9/23/07, Pierre Habouzit <madcoder@debian.org> 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.

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

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.

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.

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

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

Thanks Marco

On Sun, 23 Sep 2007, Marco Costalba 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.

Nicolas

On 9/23/07, Nicolas Pitre <nico@cam.org> wrote:

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

"Marco Costalba" <mcostalba@gmail.com> writes:

I read that as OO bringing in more programmers capable of creating problems than those capable of fixing them.

It is not the fault of OO in itself, but it is the bottom line that counts: if it draws the wrong audience for the wrong reasons, it better had great benefits to offset that. Not quite unsimilar with communism: the idea is great in principle, but the idea has no built-in self-check. Capitalism, in contrast, is a distasteful idea at its heart, but it is rooted soundly in individual egoism. Which does not make it any less distasteful, but at least it tends to work.

On 9/23/07, David Kastrup <dak@gnu.org> wrote:

Perhaps I'm wrong, but I think one of the advantages of big projects written in C vs comparable size projects in an OO language (read C++) it's exactly the opposite.

Because C lets a random developer to understand, quickly enough, and do little local modifications also to big projects like Linux, it attracts a lot of developers that have the possibility to start with some janitorial work or some little patch without incurring in the very steep learning curve you have understanding the object hierarchy of a big C++ code base, an almost mandatory step, before to start hacking as example in Firefox.

This is, IMHO, a big advantage: fresh meat is always welcomed, the damage it can potentially create is more then compensated by the long term benefit of a large and live developer community.

Marco

To me the methods that an OO class defines is the same thing as an API. And you can screw up an API whether it is C++ or C. Both give you the same opportunity to screw up the model and create code that needs to be re-written.

Paul Franz

David Kastrup wrote:

On Sun, 23 Sep 2007, Marco Costalba wrote:

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 <torvalds@linux-foundation.org> wrote:

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

"Marco Costalba" <mcostalba@gmail.com> writes:

Not really. The difference is that the first generates new (and optimized) code for every type which is something you can only do using macros in C. Class programming is similar to opaque pointers (in particular concerning the generated code) but templates are really more like macros, as their instantiation generates specialized code, not at all like the handling of opaque pointers.

While I tend to agree that templates are probably the one thing actually worth having, it was stupid to lift the restrictions syntax along with the concept of generics from the Ada shop. Borrowing syntax along with features is such a Perlesque approach.

On 9/23/07, David Kastrup <dak@gnu.org> wrote:

Probably if I had written like this was more clear:

template <typename T>  int some_function(T* p);

And regarding 'new' code for each type I would like to remember that template instantations of different types can be removed by compiler/linker when the instantations are the same (i.e. produce the same binary instuctions), this could happen for function templates that handle pointers, as example.

Marco

"Marco Costalba" <mcostalba@gmail.com> writes:

Huh? How is this supposed to support your point? There is nothing like an opaque pointer involved here. The point of opaque pointers is that they can stand for a variety of types, whereas each template instantiation can only substitute a single type.

Hardly. The type constraints/virtual function tables of any called function depending on T will be different. And if indeed nothing depends on T at all inside of the template, it is pointless not to declare it as void *p in the first place: the type of *p will never be used then.

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

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.

user_ptr<somestruct> p;

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

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.

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.

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.

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.

Dmitry Potapov <dpotapov@nbs-eng.ru> writes:

It has been some time since I last looked, but the lifetime of objects constructed in return statements was a moving target through several standards. The last standard I bothered looking at had the object survive until the statement with the function call expression ended: quite a strange synchronization point with regard to language design.

Mostly objects are alive as long as you can refer to them. Not really complicated.

söndag 23 september 2007 skrev David Kastrup:

The idea is that you should be able to use temporaries by reference and trust them to be valid over function calls end even function returns, so you can write efficient matrix math libraries that do not copy data much while retaining value semantics with overloaded operators. It is a purely practical matter, what actually works and is efficient, not dogmatic language "design".

Earlier versions failed to make up something useful here.

What could be simpler, besides all static variables.

-- robin

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

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.

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:

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.

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.

Conversation operator should be written only if you do want an implicit conversation, and that may be useful sometimes, albeit very rarely.

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.

Do you think that an error code contains much more contextual information?

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.

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.

You named some interoperability issues with C++ (and there are many of them), but it is not an argument against exceptions per se.

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

On 9/23/07, Kyle Rose <krose@krose.org> wrote:

Or - as Marco's done - write complementary bits to git. I'm a Perl-head, and I've ended up writing bits of Perl for git, some of them have been reimplemented in C, some have stayed in Perl.

Arguing is a waste of time -- code! Help Marco, or write something new and glorious. Make it useful for people who don't care what it's written in, and beautiful so that the infidels are enlightened with how elegant C++ can be.

Codefest > Flamefest

cheers,

m