> 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" <tytso@xxxxxxx> wrote in message news:20070907061554.GB30161@xxxxxxxxxxxx > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
