Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.

[Theodore Tso <tytso@mit.edu>]

On Thu, Sep 06, 2007 at 08:09:23PM -0700, Dmitry Kakurin wrote:
> > Total BS. The string/memory management is not at all relevant. Look at the
> > code (I bet you didn't). This isn't the important, or complex part.
> 
> Not only have I looked at the code, I've also debugged it quite a bit.
> Granted most of my problems had to do with handling paths on Windows
> (i.e. string manipulations).

I consider string manipulation to be one of the places where C++ is a
total disaster.  It's way to easy for idiots to do something like this:

	a = b + "/share/" + c + serial_num;

where you can have absolutely no idea how many memory allocations are
done, due to type coercions, overloaded operators (good God, you can
overload the comma operator in C++!!!), and then when something like
that ends up in an inner loop, the result is a disaster from a
performance point of view, and it's not even obvious *why*!

> My goal is to *use* Git. When something does not work *for me* I want
> to be able to fix it (and contribute the fix) in *shortest time
> possible* and with *minimal efforts*. As for me it's a diversion from
> my main activities.

Yes, and if you contribute something the shortest time possible, and
it ends up being crap, who gets to rewrite it and fix it?  I've seen
too many C++ programs which get this kind of crap added, and it's not
noticed right away (because C++ is really good at hiding such
performance killers so they are not visible), and then later on, it's
even harder to find the performance problems and fix them.

> Now, I realize that I'm a very infrequent contributor to Git, but I
> want my opinion to be heard.

And if git were written in C++, it's precisely the infrequent
contributors (who are in a hurry, who only care about the quick hack
to get them going, and not about the long-term maintainability and
performance of the package) that are be in the position to do the
most damage...

						- Ted