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

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

You are assuming (incorrectly) everybody will use dumb string classes like 
that.

It is very possible to create a string class that instead of allocating all
those strings simply concatenates tiny temporary objects and performs one
single operation in the end. Not to mention those temporaries are optimized
away by any decent compiler and you end up with code that runs at the same
speed as your C code.
I've done it, many other programmers have. As a reference, I'd like to
mention Matthew Wilson's chapter on efficient string concatenation in his
book "Imperfect C++". He uses expression templates (that's the technique I
just described) and gets impressive results.

With that said, your point is valid. 90% of C++ programmers will use string
classes that are very inefficient for concatenation, starting with
std::string which I hate for that reason (and many other reasons, e.g. you 
have to
resort to Boost for mundane things like trimming)

Steven Burns

"Theodore Tso" [off-list ref] wrote in message 
news:20070907061554.GB30161@thunk.org...

On Thu, Sep 06, 2007 at 08:09:23PM -0700, Dmitry Kakurin wrote:

quoted

quoted

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

quoted

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.

quoted

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