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

Hi.

This is an attempt to use "The Better String Library"[1] in builtin-mailinfo.c

The patch doesn't pass all the tests in the testsuit yet, but I thought I'd send it out so people can decide if they like how the code looks.

I'm not sending a patch to add the library files at this time. I'll send that patch when this patch is working.

The changes required to make it pass the tests shouldn't be very large.

/Lukas

[1] http://bstring.sourceforge.net/

---
 builtin-mailinfo.c |  795 ++++++++++++++++++++++++++--------------------------
 1 files changed, 392 insertions(+), 403 deletions(-)

Lukas Sandström, Tue, Sep 04, 2007 22:50:08 +0200:

It looks uglier, but what are measurable merits? Object code size, perfomance hit/improvement, valgrind logs?

Every coder has a time in his life when he writes a string library... and a stream support for it.

On mar, sep 04, 2007 at 09:38:57 +0000, Alex Riesen wrote:

  Well I honestly believe that putting strbufs/bstrings in mailinfo.c
adds no value. I was going to give it a try to see how strbufs
performed, but it's just useless.

  The main problem mailinfo has, it's according to Junio that it may
sometimes truncate some things in buffers at 1000 octets, without dying
loudly. That is bad.

  _but_ there is no point in using arbitrary long string buffers to
parse a mail. Remember, a mail goes through SMTP, and SMTP is supposed
to limit its lines at 512 characters (without use of extensions at
least). Not to mention that an email address cannot be more than 64+256
chars long (or sth around that). So using variable lengths buffers is
just a waste.

  string buffers are not really (IMHO) supposed to help in parsing
tasks, and when you need to do some serious parsing, either do it by
hand or use lex, but nothing in between makes sense to me.

  OTOH, string buffers can be used in many places where git has (at
least 4 different to my current count, growing) many implementations of
always slightly different kind of buffers. I've some more patches
pending here than the one I already sent, and well, here is the
diffstat:

$ git diff --stat origin/master.. ^strbuf*
 archive-tar.c         |   67 ++++++++++++------------------------------------
 builtin-apply.c       |   29 ++++++---------------
 builtin-blame.c       |   34 ++++++++-----------------
 builtin-commit-tree.c |   59 +++++++++---------------------------------
 builtin-rerere.c      |   53 +++++++++++---------------------------
 cache-tree.c          |   57 ++++++++++++++---------------------------
 diff.c                |   25 ++++++------------
 fast-import.c         |   38 +++++++++++----------------
 mktree.c              |   26 ++++++-------------
 9 files changed, 116 insertions(+), 272 deletions(-)

  I mean, there is not even a need to show the diff to understand what
the gain is. And that was possible, because strbufs are straightforward,
and gives you the kind of controls git needs (tweaking how memory will
be allocated to avoid reallocs is part of the answer).

  A French author once said: “Il semble que la perfection soit atteinte
non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à
retrancher.” -- Antoine de St Éxupéry[0]. IMHO git will never need any
of the bstring splits, streaming functions, tokenization or whatever,
and supporting those has necessarily led the bstring library to make
some choices that may not fit git needs. I don't really like reinventing
the wheel, but OTOH buffers and strings are often of the critical path,
and having a nice fitting buffer API is priceless.

  [0] Perfection is achieved, not when there is nothing more to add, but
      when there is nothing left to take away.

On Tue, 2007-09-04 at 22:50 +0200, Lukas Sandström wrote:

Please, no. Let's not pull in a dependency for something as simple as a string library. How many distros have bstring pcakaged? The right version? Does it work on Windows? We already have strbuf.c, lets just consolidate the string manipulation code already in git under that interface.

Kristian

Kristian Høgsberg <krh@redhat.com> writes:

That's not a good argument. If dependancy is a problem, bsstring can easily be distributed as part of git. It's really small, so it wont make git bloated:

$ wc -l *.c *.h
    82 bsafe.c
  3462 bstest.c
  1134 bstraux.c
  2964 bstrlib.c
   358 testaux.c
    43 bsafe.h
   112 bstraux.h
   302 bstrlib.h
   442 bstrwrap.h
  8899 total

The library is totally stand alone, portable (known to work with gcc/g++, MSVC++, Intel C++, WATCOM C/C++, Turbo C, Borland C++, IBM's native CC compiler on Windows, Linux and Mac OS X)

The right question is: what does git need. One way to consolidate strbuf would be to simply

$ rm strbuf.{c,h} $ unzip bsstring.zip

and if people decide that git needs a non-trivial string library, writting/testing more code in strbuf.c would probably be more work than just reading what bsstring code does to become familiar enough with it to even be able to maintain it later.

If people decide that git needs a really trivial string library, then a few improvements to stbuf.c can be good.

I'd argue in favor of the first option. C strings are horrible, and I think doing something pleasant to use and safe is not completely trivial. But I'm not a big contributor enough to really decide in spite of others ;-).

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

of ugly though....

-Miles

[ snip ]

When I first looked at Git source code two things struck me as odd:
1. Pure C as opposed to C++. No idea why. Please don't talk about 
portability, it's BS.
2. Brute-force, direct string manipulation. It's both verbose and 
error-prone. This makes it hard to follow high-level code logic.

- Dmitry

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

Git's creator (Linus) codes in C, not C++. He has at various times stated reasons why he does not use C++. I'm sure one can find such messages with a bit of searching on mailing lists that he frequents. He has his reasons. I also happen to agree with at least some of them. :)

Git evolved from that initial prototype that Linus created. I'm not sure how much code survives from that initial few versions that Linus managed before Junio took over, but nobody wanted to rewrite things that already work so it just stayed in C. "If it works, don't fix it."

C works. We (now) have 83,215 lines of it. Its not going away anytime soon in Git. It is also a relatively simple language that a large number of open source programmers know. This makes it easy for them to get involved in the project. Instead of say Haskell, which has a smaller community. Or Tcl/Tk as we recently found out in the Git User Survey. :-\

Shawn O. Pearce wrote:

This is important. Git contains code from more than 300 people. I'm guessing you could cut that number by 2/3 if it had been written in C++.

Git is cheating a bit though. Its primary audience was (and is) the various integrators working on the Linux kernel, all of whom are fairly competent C programmers.

Andreas Ericsson <ae@op5.se> writes:

Do we still have a huge overlap with the kernel people? I had an impression that patches from the kernel folks, with notable exception from a handful (you know who you are), have petered out rapidly after the first several weeks.

Junio C Hamano wrote:

True, but the point I was trying to make is that because git is written in C, for an audience who are extremely at home with that particular language, it quickly attracted contributors.

git log --pretty=short | sed -n 's/^Author: \([^<]*\)<.*$/\1/p' | \
	sort | uniq | wc -l

reports 355 unique lines, although some authors are mentioned twice (Theodore Tso vs Theodore Ts'o). Cross-matching the kernel authors with the git authors shows that git and linux have 111 developers in common, again reporting some of them twice. A quick visual scan shows the figure to be 106, assuming no two authors have the same name (including email addresses produced more unique contributors as people change email more often than they change name).

It's not unreasonable to say that git got at least 106 C-programmers "for free" included in their userbase round about the same second Linus went public with his intentions of managing the linux kernel in git, all of which are obviously comfortable enough with C to poke around in the kernel.

Andreas Ericsson <ae@op5.se> writes:

C++ is a language without design discipline. Its set of features and syntactic elements is incontingent (for example, its templates started as a ripoff of Ada generics which would have been ok except for the completely braindead idea of taking the Ada angle bracket restriction syntax along with it), and it is the task of each programmer to choose a sane and manageable subset and style, and implement using that. As a consequence, every C++ programmer writes his own personal dialect of C++, and we have about 20 different incompatible implementations of multidimensional numeric arrays, making a complete mockery of the "code reuse" mantra: C++ _projects_ can't actually usefully achieve "multiple inheritance" on a design/meta level: once you start with one non-trivial design, fitting other separately evolved components with a different style causes retrofitting nightmares.

So going to C++ means cutting down the amount of people who find themselves comfortable with the actual design and layout down to maybe 10% of those who would actually feel ok with the actual _algorithms_ employed.

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

Just to piss you off.

-Miles

Hi,

On Thu, 6 Sep 2007, Miles Bader wrote:

Hehe.

FWIW I strongly disagree that it's BS. As others have stated, the reasons are easily found, and they are no weak arguments.

Ciao, Dscho

On Wed, 5 Sep 2007, Dmitry Kakurin wrote:

*YOU* are full of bullshit.

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said "to piss you off", but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to piss off, so that he doesn't come and screw up any project I'm involved with.

C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes:

 - infinite amounts of pain when they don't work (and anybody who tells me 
   that STL and especially Boost are stable and portable is just so full 
   of BS that it's not even funny)

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

So I'm sorry, but for something like git, where efficiency was a primary objective, the "advantages" of C++ is just a huge mistake. The fact that we also piss off people who cannot see that is just a big additional advantage.

If you want a VCS that is written in C++, go play with Monotone. Really. They use a "real database". They use "nice object-oriented libraries". They use "nice C++ abstractions". And quite frankly, as a result of all these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess.

But I'm sure you'd like it more than git.

			Linus

On 9/6/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:

nice

As dinosaurs (who code exclusively in C) are becoming extinct, you will soon find yourself alone with attitude like this.

Measuring number of people who contributed to Git is incorrect metric. Obviously C++ developers can contribute C code. But assuming that they prefer it that way is wrong.

I was coding in Assembly when there was no C. Then in C before C++ was created. Now days it's C++ and C#, and I have never looked back. Bad developers will write bad code in any language. But penalizing good developers for this illusive reason of repealing bad contributors is nonsense.

Anyway I don't mean to start a religious C vs. C++ war. It's a matter of beliefs and as such pointless. I just wanted to get a sense of how many people share this "Git should be in pure C" doctrine.

On Thu, 6 Sep 2007, Dmitry Kakurin wrote:

Unlike you, I actually gave reasons for my dislike of C++, and pointed to examples of the kinds of failures that it leads to.

You, on the other hand, have given no sane reasons *for* using C++.

The fact is, git is better than the other SCM's. And good taste (and C) is one of the reasons for that.

It has nothing to do with dinosaurs. Good taste doesn't go out of style, and comparing C to assembler just shows that you don't have a friggin idea about what you're talking about.

			Linus

On 9/6/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:

As I said, it's a matter of believes. As such, any reasoning and arguing will be endless and pointless, as for any other religious issue.

I'll give you reasons why to use C++ for Git (not why C++ is better for any project in general, as that again would be pointless):

1. Good String class will make code much more readable (and
significantly shorter)
2. Good Buffer class - same reason
3. Smart pointers and smart handles to manage memory and
file/socket/lock handles.

As it is right now, it's too hard to see the high-level logic thru this endless-busy-work of micro-managing strings and memory.

IMHO Git has a brilliant high-level design (object database, using hashes, simple and accessible storage for data and metadata). Kudos to you! The implementation: a mixture of C and shell scripts, command line interface that has evolved bottom-up is so-so.

I don't see myself comparing assembler to C anywhere. I was pointing out that I've been programming in different languages (many more actually) and observed bad developers writing bad code in all of them. So this quality "bad developer" is actually language-agnostic :-).

On Thu, 6 Sep 2007, 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.

The only really important part is the *design*. The fact that some of it is in a "prototyping language" is exactly because it wasn't the core parts, and it's slowly getting replaced. C++ would in *no* way have been able to replace the shell scripts or perl parts.

And C++ would in no way have made the truly core parts better. 

You made a very clear "assembler -> C -> C++/C#" progression nin your life, comparing my staying with C as a "dinosaur", as if it was some inescapable evolution towards a better/more modern language.

With zero basis for it, since in many ways C is much superior to C++ (and even more so C#) in both its portability and in its availability of interfaces and low-level support.

You can write bad code in any language. However, some languages, and especially some *mental* baggages that go with them are bad.

The very fact that you come in as a newbie, point to some absolutely *trivial* patches, and use that as an argument for a language that the original author doesn't like, is a sign of you being a person who should be disabused on any idiotic notions as soon as possible.

The things that actually *matter* for core git code is things like writing your own object allocator to make the footprint be as small as possible in order to be able to keep track of object flags for a million objects efficiently. It's writing a parser for the tree objects that is basically fairly optimal, because there *is* no abstraction. Absolutely all of it is at the raw memory byte level.

Can those kinds of things be written in other languages than C? Sure. But they can *not* be written by people who think the "high-level" capabilities of C++ string handling somehow matter.

The fact is, that is *exactly* the kinds of things that C excels at. Not just as a language, but as a required *mentality*. One of the great strengths of C is that it doesn't make you think of your program as anything high-level. It's what makes you apparently prefer other languages, but the thing is, from a git standpoint, "high level" is exactly the wrong thing.

		Linus

On 9/6/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:

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

Let me snip "C is better than C++" part ...

... and explain where I'm coming from: 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. The fact that Git is written in C does not really contribute to that goal. Suggestion to use C++ is the only alternative with existing C codebase. So while C++ may not be the best choice "academically speaking" it's pretty much the only practical choice.

"Democracy is the worst form of government except for all those others that have been tried." - Winston Churchill

Now, I realize that I'm a very infrequent contributor to Git, but I want my opinion to be heard. People who carry the main weight of developing and maintaining Git should make the call.

On 07/09/07, Dmitry Kakurin <dmitry.kakurin@gmail.com> wrote:

That's just it -- Git's goal isn't to make it as easy as possible for Git _users_ to fix it (thought that is a nice thing to have). Git's goal is to be a very good, very fast SCM. Bugs should be found and fixed, but that can most effectively be done by the people who are already knowledgeable about Git's codebase (i.e. its developers), not its users.

Dave.

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

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

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.

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

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@mit.edu> wrote in message news:20070907061554.GB30161@thunk.org...

Steven Burns wrote:

Not really. He said "It's way to easy for idiots to do something like this:" just prior to the line you quoted. I wholeheartedly agree, but in no way does anyone assume that everybody will use dumb string classes.

I'm sure it's perfectly possible to write properly functioning programs in C++. I know I use a few of them myself. That doesn't change the fact that it's an idiot-friendly language to write code in that's extremely annoying for competent programmers to fix up later.

Dmitry Kakurin wrote:

Coupled with what you said in an earlier mail, namely ---%<---%<---

---%<---%<---

Considering C appeared in 1972, and C++ appeared in 1985, you have been writing C code for 13 years. And you're telling me that git being written in C prevents you from contributing?

If you want to do something useful in C++ for git, make it easy for C++ programmers to write apps for it.

They already have, but every now and then someone comes along and suggest a complete rewrite in some other language. So far we've had Java (there's always one...), Python and now C++.

It happens to all projects, sooner or later. The funny thing is that all those people that want their favourite software to be rewritten in their favourite programming language always wants someone else to rewrite it for them.

On 9/6/07, Andreas Ericsson <ae@op5.se> wrote:

Since this "complete rewrite" was mentioned in multiple emails I'd like to rectify that: What I'm offering (for Git) is to use C++ as a "better C". Don't change any existing *working* code, but start introducing simple C++ constructs in the new code. Git is simple enough to not require any high-level abstractions. But some utility classes could make code much simpler.

And BTW, I don't even like C++ that much :-), I just like it much better than C. I've been saying that C++ is a legacy language for quite some time now. But we will use it for many years to come because the size of this legacy code is huge, so there will be plenty of C++ developers available (to contribute to Git :-). And C++ is the only way to move with existing C codebase.

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

You are aware that the Linux kernel was kept compilable under g++ for a while in its history? You'll need more than vague words to erase the memories from that experiment...

Just compiling under C++, with no source changes, is likely to impact performance and compile time rather badly, not to mention portability (you need the C++ runtime, for one thing).

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

This in fact is a very specific statement. Would you care to back it up with facts?

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

Read up on the Linux kernel history in the archives.

Dmitry Kakurin wrote:

There are far too many highly valuable contributors that have spoken against C++ for me to believe that C++ and C will ever co-exist in the official git repo. Good thing utility classes can be developed on top of the existing C-code, but in a separate repo, and packed into a library. That way, you get some hacking ground for your beloved C++ coderswhile the current git contributors can keep contributing in the language they like best.

The C code base is a lot larger and C++ will drop dead pretty fast if it's ever removed or left unmaintained. So much for dinosaurs...

Complete and utter BS. It can also stay in C, or get language bindings for Python/Perl/PHP/LUA(?)/whatever, or both.

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

Sorry, but for fixing things in C, I can look and work locally. For fixing things in C++, I first need to understand the class hierarchies used in the project.

Hi,

On Thu, 6 Sep 2007, Dmitry Kakurin wrote:

We are a happy little meritocracy here. Once you proved that you're not full of shit (some seem to try the opposite, you know who you are), you can go all caps. Before that, you'll have to show that you earn to be heard first.

Ciao, Dscho

Hi,

On Fri, 7 Sep 2007, Linus Torvalds wrote:

There is an important additional point: a language like C _holds_ you to a certain degree of diligence.

In my day-job I have to code in other languages, which make it "easy" to code. As a result, the code I have to work with is sloppy, ugly and buggy. By applying the same principles I am _forced_ to use in C, with Git, I produce better code.

Ciao, Dscho

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

But all of those are incompatible with another and require major headaches and/or interface code to get to run with one another. And then might use different interface styles, anyway.

On Fri, 7 Sep 2007, Linus Torvalds wrote:

To be very specific:
 - simple and clear core datastructures, with *very* lean and aggressive 
   code to manage them that takes the whole approach of "simplicity over 
   fancy" to the extreme.
 - a willingness to not abstract away the data structures and algorithms, 
   because those are the *whole*point* of core git. 

And if you want a fancier language, C++ is absolutely the worst one to choose. If you want real high-level, pick one that has true high-level features like garbage collection or a good system integration, rather than something that lacks both the sparseness and straightforwardness of C, *and* doesn't even have the high-level bindings to important concepts.

IOW, C++ is in that inconvenient spot where it doesn't help make things simple enough to be truly usable for prototyping or simple GUI programming, and yet isn't the lean system programming language that C is that actively encourags you to use simple and direct constructs.

				Linus

On Fri, 7 Sep 2007, Linus Torvalds wrote:

Not to mention try finding two C++ compilers that support the same language features. C is a known quantity. C++ depends on whos compiler you use and what class libraries you use. Trying to make those things work crossplatform is not an easy task. (Harder than it is in C at least.)

A number of years ago, a programmer who will not be named (and is not me), tried to port Perl to C++. It was a disaster. He found that every compiler handled something differently.

If you stuck to one compiler, it might work. But trying to get GCC to work like MS C++ or Borland C++ or whatever is just asking for pain.

Linus Torvalds wrote:

The D programming language is a different take than C++ has on growing C. I'm curious what your thoughts on that are (D has garbage collection, while still retaining the ability to directly manage memory). Can you enumerate what you feel are the important concepts?

Walter Bright <boost@digitalmars.com> writes:

A design is perfect not when there is no longer anything you can add to it, but if there is no longer anything you can take away.

David Kastrup wrote:

I like to phrase that a slightly different way: anyone can make something complicated, but it takes genius to make something simple.

A very big goal for D is to make what should be simple code, simple. It turns out that what's simple for a computer is complex for a human. So to design a language that is simple for programmers is (unfortunately) a rather complex problem. Or perhaps I'm just not smart enough <g>.

A canonical example is that of a loop. Consider a simple C loop over an array:

void foo(int array[10])
{
     for (int i = 0; i < 10; i++)
     {   int value = array[i];
         ... do something ...
     }
}

It's simple, but it has a lot of problems:

1) i should be size_t, not int
2) array is not checked for overflow
3) 10 may not be the actual array dimension
4) may be more efficient to step through the array with pointers, rather 
than indices
5) type of array may change, but the type of value may not get updated
6) crashes if array is NULL
7) only works with arrays and pointers

Since this thread is talking about C++, let's look at the C++ version:

void foo(std::vector<int> array)
{
   for (std::vector<int>::const_iterator
        i = array.begin();
        i != array.end();
        i++)
   {
     int value = *i;
     ... do something ...
   }
}

It has fewer latent bugs, but still:

1) type of array may change, but the type of value may not get updated
2) too darned much typing
3) it's more complicated, not simpler

Frankly, I don't want to write loops that way. I want to write them like this:

void foo(int[] array)
{
   foreach (value; array)
   {
     ... do something ...
   }
}

As a programmer, I'm specifying exactly what I want to happen without much extra puffery. It's less typing, simpler, and more resistant to bugs.

1) correct loop index type is selected based on the type of array
2) arrays carry with them their dimension, so foreach is guaranteed to 
step through the loop the correct number of times
3) implementation decides if pointers will do a better job than indices, 
based on the compilation target
4) type of value is inferred automatically from the type of array, so no 
worries if the type changes
5) Null arrays have 0 length, so no crashing
6) works with any collection type

[This example is extracted from a presentation I've made.]

------ Walter Bright http://www.digitalmars.com C, C++, D programming language compilers http://www.astoriaseminar.com Extraordinary C++

Walter Bright <boost@digitalmars.com> writes:

Wrong. size_t is for holding the size of memory objects in bytes, not in terms of indices. For indices, the best variable is of the same type as the declared index maximum size, so here it is typeof(10), namely int.

Why should it?

Your point is?

No. It is a beginners' and advanced users' mistake to think using pointers for access is a good idea. Trivial optimizations are what a compiler is best at, not the user. Using pointer manipulation will more often than not break loop unrolling, loop reversal, strength reduction and other things.

Huh?

Certainly.  Your point being?

Since there are only arrays and pointers in C, not really a restriction.

Where is my barf bag?

Most of those are toy concerns. They prevent problems that don't actually occur much in practice.

David Kastrup wrote:

The easiest way to show the error is consider the code being ported to a typical 64 bit C compiler. int's are still 32 bits, yet the array can be larger than 32 bits. You're right in that what we want to be able to do is typeof(array dimension), but there is no way to do that automatically in C, which is my point. If the array dimension changes, you have to carefully check to make sure every loop dependency on the type is updated, too.

size_t will always work, however, making it a better choice than int, at least for C.

Because the 10 array dimension is not statically checked in C. I could pass it a pointer to 3 ints without the compiler complaining. This makes it a potential maintenance problem. Also, the maintenance programmer may change the array dimension in the function signature, but overlook changing it in the for loop. Again, a maintenance problem.

Array buffer overflow errors are commonplace in C, because array dimensions are not automatically checked at either compile or run time. This is an expensive problem. Some C APIs try to deal with this by passing a second argument for arrays giving the dimension (snprintf, for example), but this tends to be sporadic, not conventional. It being extra work for the programmer inevitably means it doesn't get done.

C compilers vary widely in the optimizations they'll do for simple loops. I see often enough attempts by programmers to take such matters into their own hands. I agree with you on that - and suggest the language should not tempt the user to do such optimizations.

Let's say our fearless maintenance programmer decides to make it an array of longs, not an array of ints. He overlooks changing the type of value in the loop. Suddenly, things subtly break because of overflows. Or maybe he changed the int to an unsigned, now the divides in the loop give different answers. Etc. There really isn't any compiler/language help in finding these kinds of problems.

I consider an array that is NULL to have no members, so instead of crashing the loop should execute 0 times.

C has structs, too, as well as more complicated user defined collections. Essentially, you cannot (simply) write generic algorithms in C, because you cannot (simply) generically express iteration. Of course, you can still express anything in C if you're willing to work hard enough to get it. Me, I'm too lazy <g>. It's like why I can't play chess - everytime I try to play it instead I think about writing a program to do the hard work for me.

I beg to differ - buffer overflow bugs are common and expensive. The nice thing about the D loop is it is LESS typing than the C one - you get the extra robustness for free.

Let's look at the code gen for the inner loop for C:

L8:             push    [EBX*4][ESI]
                 call    near ptr _bar
                 inc     EBX
                 add     ESP,4
                 cmp     EBX,0Ah
                 jb      L8

and for D:

LE:            mov     EAX,[EBX]
                call    near ptr _D4test3barFiZv
                add     EBX,4
                cmp     EBX,ESI
                jb      LE

I think you can see that performance isn't an impediment.

Walter Bright <boost@digitalmars.com> writes:

Not if it is an array declared of size 10. And if it isn't, you have no business stating so in the function prototype.

Willfully obfuscate programming does not prove anything.

Nonsense.  Again, C won't keep you from shooting yourself in the foot.

No, because programmers get things wrong. You can tell C compilers to check all array accesses, but that is a performance issue. For gcc, we have

`-fmudflap -fmudflapth -fmudflapir'
     For front-ends that support it (C and C++), instrument all risky
     pointer/array dereferencing operations, some standard library
     string/heap functions, and some other associated constructs with
     range/validity tests.  Modules so instrumented should be immune to
     buffer overflows, invalid heap use, and some other classes of C/C++
     programming errors.  The instrumentation relies on a separate
     runtime library (`libmudflap'), which will be linked into a
     program if `-fmudflap' is given at link time.  Run-time behavior
     of the instrumented program is controlled by the `MUDFLAP_OPTIONS'
     environment variable.  See `env MUDFLAP_OPTIONS=-help a.out' for
     its options.

Why isn't it the default?  Because it is a performance issue.

Again: C does not prevent you from shooting yourself in the foot.

Nobody else does that.

If the loop count is zero, this is what will happen.

Of course you can.  Macros exist.

Then compile your program with appropriate options. The key word is "option". You don't have to take the performance hit if you don't want or need it.

David Kastrup wrote:

Right, it won't. A good systems language should do what it can to prevent the programmer from *inadvertently* shooting himself in the foot, while allowing him to *deliberately* shoot himself in the foot.

In the example loop, the cases I pointed out were ones where, if one changes part of the code (such as the array dimension, or the array type, etc.), then there are multiple places in the source that must be updated to reflect it. The reality of human programmers is we update one or two places, and overlook the third place, and we now have a bug. Saying that one should just be a better programmer and not make such mistakes is a pipe dream.

Ideally, each facet of the design of the code should have a single point where it can be changed, and then all dependencies on that design should be automatically updated. That way, nothing gets overlooked. Doing this in C, such as using a #define for the array dimension, involves extra work.

It's a truism that if it involves extra work, then it often gets omitted.

Doesn't "A design is perfect not when there is no longer anything you can add to it, but if there is no longer anything you can take away." apply here? Going from:

  void foo(int array[10])
  {
     for (int i = 0; i < 10; i++)
     {   int value = array[i];
         ... do something ...
     }
  }

to:

  void foo(int[] array)
  {
    foreach (value; array)
    {
      ... do something ...
    }
  }

takes a lot of frankly unnecessary things away, each of which is a potential source of error when maintaining the code.

Exactly. That goes back to my point that a good language should help prevent inadvertent errors, while still allowing deliberate choices. D approaches this by making the correct approach essentially be the one with minimal typing effort. To deliberately shoot yourself in the foot usually requires extra typing. For our loop example, we can still write the C style loop (with all its potential problems) in D, but it requires extra effort to put in those potential problems. The easier, simpler way doesn't have the problems.

(The issue I have with C++'s fixes to various problems is they require extra typing (like the loop example), so guess what, people being people tend to not use them. This results in endless attempts to try and push C++ programmers into using the more verbose forms, a strategy I suspect will be ultimately futile.)

Runtime checking of arrays in D is a performance issue too, so it is selectable via a command line switch. But more importantly,

1) Static type checking of fixed size arrays works, so errors can be 
caught at compile time.

2) For dynamically sized arrays, the dimension of the array is carried 
with the array, so loops automatically loop the correct number of times. 
No runtime check is necessary, and it's easier for the code reviewer to 
visually check the code for correctness.

------ Walter Bright http://www.digitalmars.com C, C++, D programming language compilers http://www.astoriaseminar.com Extraordinary C++

Walter Bright <boost@digitalmars.com> writes:

The problem is a toy problem: in real applications, you'll need to access several data structures using the same index, and you'll need to be able to assign index values to temporary variables and so on. So being able to hide the type of an index in one very specific application (looping through a single array completely) at one place is not going to buy you much.

Anyway, D is pretty much irrelevant as a perspective for git, so you should take it to a language advocacy group.

David Kastrup wrote:

Necessarily, to make an example suitable for a n.g. post, I ruthlessly cut down the size of it. This can have the inadvertent effect of making it appear trivial.

The index is available:

	foreach (index, value; array)
	{
		writefln("array[%s] = %s", index, value);
	}

and it isn't necessary to worry about what the correct type for index is, as it is inferred.

  foreach'ing over a subset (i.e. slice) of an array:

	foreach (value; array[5 .. $])
		... loop from 5 to the end ...

Experience with foreach in real code shows that the for loop is what becomes a rarity. Simple as it is, foreach is one of the best liked improvements D has. And I speak as one who has written so many for loops that spewing out:

	for (int i = 0; i < 10; i++)

is a 'finger' macro for me, i.e. my fingers blit it out without even thinking about it.

 > Anyway, D is pretty much irrelevant as a perspective for git, so you
 > should take it to a language advocacy group.

I wished to answer your specific comments in this post.

Walter Bright wrote:

No, a good systems language should do exactly what it's told. Supporting tools should tell the programmer if he's risking shooting himself in the foot.

Same as in C then.

But this introduces handy but, strictly speaking, unnecessary overhead as well, meaning, in short; 'D is slower than C, but easier to write code in'.

So in essence, it's a bit like Python, but a teensy bit faster and a lot easier to shoot yourself in the foot with.

What was the niche you were going for when you thought up D? It can't have been systems programming, because *any* extra baggage is baggage one would like to get rid of. If it was application programming I fail to see how one more language would help, as there will be portability problems galore and it's still considerably slower to develop in than fe Python, while at the same time being considerably easier to mess up in.

On Sat, Sep 08, 2007 at 11:50:34PM +0000, Andreas Ericsson wrote:

  I beg to differ. I mean, knowing enough of D, I think that what Walter
tries to say is that a good language should provide constructions that
when used prevent the programmer to shoot himself in both foot at the
same time.

  D supports most of the C constructions, so when you want to juggle
with razor blades, you're free to do so in D. Though, the language
provides idioms that prevent you to write stupid mistakes when used. And
that is great.

  D is not Java, you have pointers, you can deal with memory
explicitely, you can do whatever you can do in C with no or very little
overhead. Or you can use higher level D, at your own discretion.

  HAHAHAHAHAHA. Please, who do you try to convince here ? Except in the
local scope, there is few differences between a foo* and a foo[] in C.

  That's BS. See the strbuf API I've been pushing recently ? It has
simplified git's code a lot, because each time git had to deal with a
growing string, it had to deal with at least three variables: the buffer
pointer, the current occupied length, and its allocated size. That was
three thing to have variable names for, and to pass to functions.

  Now instead, it's just one struct. D gives that gratis. There is no
performance loss because you _need_ to do the same. How do you deal with
dynamic arrays if you dont't store their lenght and size somewhere ? Or
are you the kind of programmer that write:

  /* 640kb should be enough for everyone… */
  some_type *array = malloc(640 << 10);

  Right now I'm just laughing. There is for sure overheads in some
places of D, but the example you take, and what you try to attack in D
is definitely not where you lose any kind of performance. You could have
attacked the GC instead (which is after all an easy classical target).

  Just to evaluate the silliness of your arguments:
  * http://www.digitalmars.com/d/comparison.html so that you can tell
    what the D features really are,
  * http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
    so that you can know what the D performance really is about. Of
    course those are only micro benchmarks, but well, python is "just"
    15 times slower than D, and D seems to be 10% slower. Well then I'm
    okay with D, I'm ready to buy 10% faster CPUs and avoid a lot of
    painful debugging time. In my world, 10% faster hardware is cheaper
    by many orders of magnitude than skilled programmers, but YMMV.

Pierre Habouzit wrote:

"Runtime checking of arrays is a performance issue." It's true whether it's done manually by the coder or by the compiler. The difference is that in C, you get to choose where it should be done.

Yup. I applaud your efforts, but it does come with a slight overhead, except where it replaces faulty code. In practice, it's probably better to use the api for all the string-handling, as none of it is performance- critical.

No, but it would depend on what I am to do with it.

I was asking what role D was designed to fill. I didn't mean it as an attack, but re-reading what I wrote earlier I see it came off a bit harsh.

You may notice that the feature-list is being provided by the creators and marketeers of the D language. Walter Bright certainly seems like a nice enough person, but it's possible it's a tad biased.

I get it to 7.7xC and 1.2xC, respectively, but whatever. It still means performance-critical apps will be written in C, while insert-script-language-of-choice will still be used for prototyping and not-so performance-critical apps.

I'm curious as to how many fewer bugs D developers write compared to C programmers. I guess it's hard to do a fair test given the comparatively shallow pool of D gurus around, but it'd still be interesting to see a practical test. 20% increase in runtime is certainly acceptable for never having to see a bug again, but is it acceptable for 10% fewer bugs? Or 20% fewer?

El 7/9/2007, a las 9:40, David Kastrup escribió:

Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher. Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Ch. III: L'Avion, p. 60

<http://en.wikiquote.org/wiki/Exupery>

On Fri, Sep 07, 2007 at 05:09:26AM +0000, Walter Bright wrote:

  Well, to me D has two significant drawbacks to be "ready to use". The
first one is that it doesn't has bit-fields. I often deal with bit-fields
on structures that have a _lot_ of instances in my program, and the
bit-field is chosen for code readability _and_ structure size efficiency.
I know you pretend that using masks manually often generates better
code. But in my case, speed does not matter _that_ much. I mean it does,
but not that this micro-level as access to the bit-field is not my
inner-loop.

  The other second issue I have, is that there is no way to do:
  import (C) "foo.h"

  And this is a big no-go (maybe not for git, but as a general issue)
because it impedes the use of external libraries with a C interface a
_lot_. E.g. I'd really like to use it to use some GNU libc extensions,
but I can't because it has too many dependencies (some async getaddrinfo
interface, that need me to import all the signal events and so on
extensions in the libc, with bitfields, wich send us back to the first
point).

  I also have a third, but non critical issue, I absolutely don't like
phobos :) Though I'm obviously free to chose another library. D has
definitely many many many real advances over C (like the .init, .size,
... and so on fields, known types, and whatever portability nightmare
the C impose us). In fact I like to use D like I code in C, using
modules and functions, and very few classes, as few as I can. And even
(under- ?) using D like this, it is a real pleasure to work with. I'm
really eager to see gdc be more stable.

Pierre Habouzit wrote:

I'm surprised this is such an important issue. Others have mentioned it, but regard it as a minor thing. Interestingly, the htod program (which converts C .h files to D import files) will convert bit fields to inline functions, giving equivalent functionality.

D does come with htod, which converts C .h files to D files. It's not possible to do a perfect job (because of macros), but it comes pretty darned close. The reason htod gets so close is because it is actually a real C compiler front end, not a perl or regex string processing hack.

Because it (may) require a little hand tweaking of the results (again, 
because C headers may include awful things like:
	#define BEGIN {
	#define print printf(
), it's a separate program rather than built-in.

You're not the only one <g>. But I'll add that access to the standard C runtime library *is* a part of D, so at some level it can't be worse than C. There's also another runtime library available, Tango, which is very popular.

There are a lot of people hard at work on D to make it more stable and increase the breadth and depth of tools available. I am fully aware that there may be non-technical issues to using D in a project like git, like availability of other D programmers, tradition, etc., but in this thread I'm concerned mainly with technical issues.

P.S. I'm also NOT suggesting that git be converted to D. Translating a working, debugged, 80,000 line codebase from one language to another is usually a fool's errand.

Thanks for taking the time to post your thoughts.

----------- Walter Bright http://www.digitalmars.com C, C++, D programming language compilers http://www.astoriaseminar.com Extraordinary C++

Walter Bright <boost@digitalmars.com> writes:

In my opinion there is basically one area which C has botched up seriously in order to be useful as a general purpose language, and that is conflating pointers and arrays, and allowing pointer arithmetic. The consequences are absolutely awful with regard to compilers being able to optimize, and it is pretty much the primary reason that Fortran is still quite in use for numerical work.

C has no usable two-dimensional (never mind higher dimensions) array concept that would allow passing multidimensional arrays of runtime-determined size into functions. Period.

Add to that the pointer aliasing problems affecting compilers, and C is useless for serious portable readable numerical work.

Fortran libraries like blas and lapack are ubiquitous after decades because the language can deal with multiple-dimension arrays sensibly, and could do so in the sixties already.

C99 helps a bit. But messing around with restrict pointers and similar means that to wring equal performance out of some trivial code piece (or permitting the compiler to do so without having to take aliasing into account) is a lot of work and leads to ugly and inscrutable code.

That's the one thing that has seriously hampered C: the lack of a true array type on its own, decoupled from pointers. It does not need to carry its dimensions with it or other hide-the-implementation-from-the-programmer niceties: C is, after all, a low-level language, and Fortran did not suffer from not having array dimensions packed into the arrays as well.

But that's water down the drawbridge. This single major deficiency is not anything that would hamper git development.

David Kastrup wrote:

I agree. It's one of those things that probably sounded like a good idea at the time. The consequences were not foreseen. All languages have a few of these (C++ has the infamous use of < > for template arguments).

On Fri, Sep 07, 2007 at 07:03:24PM +0000, Walter Bright wrote:

  Well htod does that, but it's very impractical to write them from
scratch. Especially if you want to benefit from the fact that padding
and integer sizes are very well defined to map e.g. structs onto a raw
stream, avoiding deserialization and so on. And for that bit-fields are
a really really fast and simple way to describe things.

  I mean, take your classical example of the foreach loop. Your whole
point is that it's way shorter, and safer. And now you are saying that
people should instead of sth like:

  struct my_struct {
    unsigned some_field : 2;
    unsigned has_this_property : 1;
    unsigned is_in_this_state  : 1;
    unsigned priority_level    : 2;
    ...
  }

  people should write (IIRC it works since ->some_field = 2 calls
->some_field(2) if the member does not exists, or maybe it's
set_some_field, it's not very relevant anyway):

  struct my_struct {
    unsigned some_field() {
      return this->real_field >> 30;
    }

    void some_field(unsigned value) {
      this->real_field |= (value & 3) << 30;
    }

    ...

  private:
    unsigned real_field;
  }

  Please it has to be a joke: there is 42 ways for people to write it
wrong (wrong shifts, wrong masks, and so on), it's horribly obfuscated,
hence needs a lot of comments, whereas the bitfield is 90% self
documented, and the syntax is _very_ clear, you cannot beat that. I
would be absolutely fine with it being syntactical sugar for some kind
of template call though.

  Not to mention that the usual C idiom:

  union {
    unsigned flags;
    struct {
      // many bitfields
    };
  };

  Would need an explicit copy_flags(const my_struct foo) function to
work. Not pretty, not straightforward.

  Really, I feel this is a big lack, for a language that aims at
simplicity, conciseness _and_ correctness.

  OK, maybe I'm biased, I work with networks protocols all day long, so
I often need bitfields, but still, a lot of people deal with network
protocols, it's not a niche.

  Last time I checked it was only available on windows, and closed
source, both are an impediment for many people. It's definitely clear
that gcc being opensource and available on so many platforms helped to
make C what it is today. Lacking portable and free (as in speech) tools
are an impediment to the succes of a language. Right now, for D, only
gdc exists, it lags behind dmd quite a lot afaict, and there is no other
toolchain helpers yet.

  Yeah I'm fine with that, but sadly it's not available everywhere like
I said.

  I completely agree, and I knew about Tango, and anyways, I'm so used
to C, and D has so few to bring to my code style when I deal with low
level system functions, that I'm totally fine with std.c.* anyways :)

  For the record I wasn't suggesting to rewrite git in D at all. I just
happened to see your post, and being very interested in where D is going
because I feel it's an excellent langage, and saw an opportunity to
mention a few quirks I feel it has, so, well, I answered :)

Pierre Habouzit <madcoder@debian.org> writes:

[bit fields]

And strictly speaking, C bitfields are completely useless for that purpose since the compiler is free to use whatever method he wants for allocating bit fields. So if you want to write a portable program, you are back to making the masks yourself.

Where bit fields work reliably is when you are not interchanging data with other applications, but just laying out your internals.

On Fri, Sep 07, 2007 at 07:51:11PM +0000, David Kastrup wrote:

  The point is (1) D is not C, (2) we all know that linux e.g. does that
in many places using the fact that it knows how the supported compilers
(gcc icc tcc maybe some other) do their packing.

  The discussion is about D. D solves the infamous problem with longs
not having the same size everywhere, I don't see why it couldn't solve
the bitfield issue either.

  Thank you for the _C_ lesson.

Pierre Habouzit wrote:

True. I haven't tried yet (nobody else seems to care about it as much as you do!), but I think this could be automated fairly easily with a template.

I should point out that inline functions are inlined, and there is no speed difference in the result.

I'm not following this. To copy a union, you just copy it with the assignment operator:

	U a, b;
	a = b;		// copies all the bit fields, too!

You're right on both counts. It's because htod is built out of a fork of the Digital Mars C compiler. Something similar could be done with gcc, but I'm not the person to do it. I should also get off my lazy tail and port htod to linux.

GDC was just released for D 1.020, which is behind D 1.021, but 1.021 was released just a couple days ago <g>.

And it's nice to hear your perspective, which is why I dropped by this thread.

On Fri, Sep 07, 2007 at 08:40:56PM +0000, Walter Bright wrote:

  I know that, and that's why I said I was totally fine with the
bitfield notation to be only syntactic sugar on a template thingy if
that's the simplest way to have that it's OKay.

  That was the point indeed. But if you don't have bitfields, you can't
do the union. And if the bitfield is just syntactic sugar, it may be
unpossible to have such a union. But I may be wrong.

  Sure, but it does not works on amd64 properly (and it's the
architecture I care about) and is not ready for the current gcc (4.2,
only 4.1 builds) and so on. It's not as stable as DMD is. It does not
lags too much version-wise, it lags in maturity. But well, youth has a
cure: time :)

Pierre Habouzit wrote:

Yes, and the more people use it, the better it will get. These are all environmental problems, not technical limitations of the language.

Linus Torvalds <torvalds <at> linux-foundation.org> writes:

I want code that is Correct, Explicit, Fast, and in that order.

I'm 23 years old and learned C++ when I was 13. Back then, my compiler didn't even support "bleeding edge" C++ language features like namespaces. I'm not a C++ expert, and I don't have the ego to call myself a superb programmer. The largest program I've written is 10K SLOC in C. Yet, I'd like to participate in this discussion, if that is OKay =)

I do think I am capable of an honest critique of the downside of C++:

_Problems_ _With_ _C++_

 *size*
    On my bookshelf, most recent editions of the canonical C++ _books_:
        Accelerated C++: Practical Programming by Example (336 pages)
        The C++ Standard Template Library: A Tutorial and Reference (832 pages)
        Effective C++: 50 Specific Ways to Improve Your Programs and Design (288
pages)
        More Effective C++: 35 New Ways to Improve Your Programs and Designs
(336 pages)
        Exceptional C++: 47 Engineering Puzzles, Programming Problems, and
Solutions (240 pages)
        More Exceptional C++: 40 New Engineering Puzzles, Programming Problems,
and Solutions (304 pages) 
        The C++ Programming Language (1030 pages)
        Modern C++ Design: Generic Programming and Design Patterns Applied (352
pages)
        C++ Templates: The Complete Guide (552 pages)

    Altogether, that is 3918 pages.  K&R, the canonical C _book_, is 272 pages.
 Becoming a C++ language lawyer is much harder than becoming a C language
lawyer.  Language lawyers know "how not to hang oneself" while programming in
the language.  I don't know how many of these titles are translated to other
languages, however, I am sure the *effort* required to translate all of them is
significant.  Open source is more successful if there is a lingua franca for
programming, and that is C.  Now, it may move away from C over time, but it will
*never* be C++ because it's encyclopedic.

 *hidden complexity*
    (1) it's hard to say what code will compile down to.  viz., constructors can
be elided, but there is no fitness warranty; profiling your compiler to find out
whether it is elided is tedious and "searching for secrets" that should be
_explicit_
    (2) people don't understand static polymorphism and compile-time dispatch;
people are used to objects sending messages dynamically (run-time dispatch)
    (3) coercion
    (4) networks of objects are not explicitly laid out, hiding quadratically
complex patterns of communication between objects
    (5) data structure and data flow come before algorithms.  Sometimes, data
structure dictates data flow (ad-hoc networks of objects); sometimes, data flow
dictates data structure (one of life's most disagreeable tasks - waiting in line
- is characterized as FIFO).  This, I feel, is the most important point, because
the first rule of programming is to figure out what you want to say before you
figure out how to say it.  In C++, ad-hoc networks of objects with cyclic
message paths are all too easy to create [see (4)] which means _code_ _is_ _not_
_explicit_ and as a result _code_ _is_ _not_ _fast_.

 *transfer semantics on objects are not robust*
    this ties into (1) in hidden complexity
    the code author needs to specify a lot of boilerplate to achieve desired
transfer semantics on objects.  Similarly, the code audience, be it reviewer,
maintainer or merger, needs to read a lot of boilerplate to understand how
objects get moved around in memory.  Moreover, most of these concepts are
intuitively declarative in nature, such as a parent object/child object relation.

 *poor re-use of effort*
    "code re-use" is a misnomer; when programmers speak of code-reuse they mean
re-use of effort.  There is no benefit to polymorphism if effort cannot be
consolidated easily.

 *C++ Standard iffy*
    Some things just disappear quickly for *frantic* reasons (strstream was
removed for aesthetics), indicating not enough foresight into what is important.
 I do not want to pick a language where I have to worry about features in it's
"standard library" becoming deprecated mainly for aesthetics.  As Dijkstra
preached, programming is _not_ supposed to be a frantic exercise.

 *usually, better options*
    See C++??: A Critique of C++ and Programing and Language Trends in the 1990s
 by Ian Joyner http://web.mac.com/joynerian/iWeb/Ian%20Joyner/CPPCritique.pdf
(Somewhat outdated, but many of the points are intrinsic and will forever be
relevant).  You can add to the list of better options D 1.0.

John 'Z-Bo' Zabroski <johnzabroski@yahoo.com> writes:

One beef I have with C++ is its automatic conversion rules. They were obviously designed with two goals:

a) behave as C when not using user-defined types.  That's ok.

b) behave like Fortran in mixed-type expressions involving "complex"
   when using C++ (with any arbitrary user-defined type taking the
   role of "complex").

And b is just madness. Not every user-defined arithmetic type is complex. I did some work using modular arithmetic (GF(65521) and similar) and it was some hard work to keep values going through the wrong arithmetic conversions. Basically trial and error and reading the generated assembly code and head scratching and standard-reading.

In short: the automatic conversions made it hard to express what one wanted to get done, both for compiler as well as programmer.

To me, the only thing that C++ has that all other mentioned languages lack is the power you get from the templates and generic programming. Sorting will always be faster if you can call the comparison function directly without using a function pointer, and the only way you can create a generic sorting algorithm is that way.

Thinking about it with a cold head, most things to hate about C++ are not in the language but in its libraries. The only feature I hate from the language itself is the preprocessor (macros), which you get in C too.

And maybe I also hate the fact that C++ allows for unexperienced programmers to create a bunch of classes and hierarchies that make sense to nobody but them. Or even worse, unexperienced programmers start writing their own frameworks, wrapping and re-wrapping, the same good old C function one thousand times.

I guess that is why most C++ based projects out there have a strict list of rules and conventions, you cannot have a stable project without them.

But, nothing prevents anybody from programming in C++ the way you describe, using simple and clear core structures with some basic methods that complement them (not obscure them) and make it easier to write the algorithms. Sadly, once you start using std::string, their overly complicated and fancy iostreams, and bulky classes that hide too much from you, I have no other choice than to agree and call the whole thing a mess.

Steven Burns

"Linus Torvalds" <torvalds@linux-foundation.org> wrote in message news:alpine.LFD.0.999.0709070203200.5626@evo.linux-foundation.org...

El 7/9/2007, a las 2:21, Dmitry Kakurin escribió:

Count me as one of them. Git is all about speed, and C is the best choice for speed, especially in context of Git's workload.

Cheers, Wincent

Wincent Colaiuta <win <at> wincent.com> writes:

I concur, but I also feel that D, Clean and OCaml are viable alternatives.

On Fri, 7 Sep 2007, Paul Wankadia wrote:

I happen to have zero experience with any of those, so if Git development was done with one of them, you'd have to count me out.

C is simply the lingua franca when it comes to programming, and it happens to be the fastest amongst portable languages too.

Nicolas

El 7/9/2007, a las 6:06, Paul Wankadia escribió:

Yes, they have reputation for speed[1], but also a smaller number of people know them[2].

[1] <http://shootout.alioth.debian.org/gp4/benchmark.php? test=all&lang=all> [2] <http://www.tiobe.com/tpci.htm>

Cheers, Wincent

Wincent Colaiuta wrote:

Nono, hand-optimized assembly is the best choice for speed. C is just a little more portable ;-)

Hi,

On Fri, 7 Sep 2007, Andreas Ericsson wrote:

I have a buck here that says that you cannot hand-optimise assembly (on modern processors at least) as good as even gcc.

Ciao, Dscho

Johannes Schindelin wrote:

http://www.gelato.unsw.edu.au/archives/git/0504/1746.html

I win. Donate $1 to FSF next time you get the opportunity ;-)

Hand-optimized asm is faster because the optimizer in the compiler is a general-purpose one that has to guess and make assumptions about the code and its input to make the correct decisions. While it gets things right in as many as 80% of the cases, there's still the 20% where it doesn't. A human can, with sufficient research and effort, make the same optimizations where they are correct but avoid the 20% erroneous ones.

If the compiler gets it wrong inside your innermost loop, it might be worth shaving those extra 0.0001 seconds off of each iteration, because in the long run, world-wide, it might save several weeks worth of CPU-time every day.

El 7/9/2007, a las 13:54, Andreas Ericsson escribió:

Well, you picked a very specific algorithm amenable to that kind of optimization: small, manageable, with a minimal and well-defined performance critical section that could be written in assembly. Note how a good chunk of the implementation was still in C. At most I'd give you 75 cents for that one. ;-)

Wincent

On 2007-09-07 14:33:42 +0200, Wincent Colaiuta wrote:

And this is of course exactly the kind of spot where you _would_ use assembly in the real world. 99.99% of code is better written in C than assembler, but there is that 0.01% where hand-coded assembler is a better choice.

Wincent Colaiuta wrote:

Yes, but that's what I said in the original email as well. C is just so much more pleasant to write in that the only place you'd (sanely) use asm is in exactly these tight loops, where the code is likely to be used and reused until the algorithm it describes is no longer a viable option for doing what it was originally designed to do.

It still proves the point though, as surely as n+1 > n for any value of n: Hand-optimized assembly is faster than compiler-optimized C code.

It might be harder to do properly on some architectures than others (RISC comes to mind), but it's still possible.

El 7/9/2007, a las 15:58, Andreas Ericsson escribió:

In a theoretical ideal world, yes; no one would argue that C is faster than fine-tuned assembly.

But in the *real world* rewriting Git in assembly would be like painting a house using a single horse hair instead of a paint brush or roller. Your SHA-1 example is a perfect example of where you benefit from doing a tiny embellished detail using the single hair (assembly) and leave all the rest in C.

In the real world and not the theoretical ideal world, it's not just about the diminishing returns you get from writing more and more of a code base in assembly instead of just the performance-critical bottlenecks; it's that you're more likely to make subtle mistakes or even make things slower. GCC does a remarkable job of optimizing in a huge number of use cases, and best of all, it does it for free. Personal opinion, of course, but that's the way I think it is.

Cheers, Wincent

Wincent Colaiuta wrote:

The discussion was theoretical from the beginning. Nobody's arguing that git should be rewritten in asm, and you've been preaching to the choir far too long now. I'll just drop this thread.

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

That assumes that the original task can even expressed well in C. Multiple precision arithmetic, for example, requires access to the carry bit. You can code around this, for example by writing something like

unsigned a,b,carry;

[...]

carry = (a+b) < a;

but the problem is that those are ad-hoc idioms with a variety of possibilities, and thus the compilers are not made to recognize them. Another thing is mixed-precision multiplications and divisions: those are _natural_ operations on a normal CPU, but have no representation in assembly language.

As a consequence, most high performance multiple-precision packages contain assembly language in some form or other.

gcc's assembly language template are excellent in that they actually cooperate nicely with the optimizer, so the optimizer can do all the address calculations and register assignments and opcode reorderings, and then the actual operations that are not expressible in C can be done by the programmer.

But anyway, I have worked as a graphics driver programmer for some amount of time, and bit-stuffing memory-mapped areas with data was still something where hand assembly was best.

I have also done BIOS terminal emulators, and being able to write something like

ld b,whatever myloop: push bc push hl call nextchar pop hl pop bc ld (hl),a inc hl djnz myloop

in order to suspend the terminal driver until the application comes up with the next `whatever' output characters in an escape sequence is _wagonloads_ more maintainable than using a state machine or whatever else for distributing material delivered into the driver.

But this requires that nextchar can do something like
nextchar: ld (driverstack),sp
  ld sp,(appstack)
  ret

and the entrypoint, in contrast, does

outchar: ld (appstack),sp
  ld sp,(driverstack)
  ret

Cheap and expedient. You just need to set up a small stack, and presto: coroutines, at absolutely negligible cost. I know that there are some "portable" coroutine implementations that use setjmp/longjmp in a rather horrific way, but those are way more unnatural.

El 7/9/2007, a las 8:25, Andreas Ericsson escribió:

Funny thing is, GCC almost certainly produces better-optimized assembly than most programmers could... ;-)

Cheers, Wincent

Wincent Colaiuta wrote:

I can appreciate that. I originally got into writing compilers because my game (Empire) ran too slowly and I thought the existing compilers could be dramatically improved.

And technically, yes, you can write code in C that is >= the speed of any other language (other than asm). But practically, this isn't necessarily so, for the following reasons:

1) You wind up having to implement the complex, dirty details of things 
yourself. The consequences of this are:

    a) you pick a simpler algorithm (which is likely less efficient - I 
run across bubble sorts all the time in code)

    b) once you implement, tune, and squeeze all the bugs out of those 
complex, dirty details, you're reluctant to change it. You're reluctant 
to try a different algorithm to see if it's faster. I've seen this 
effect a lot in my own code. (I translated a large body of my own C++ 
code that I'd spent months tuning to D, and quickly managed to get 
significantly more speed out of it, because it was much simpler to try 
out different algorithms/data structures.)

2) Garbage collection has an interesting and counterintuitive 
consequence. If you compare n malloc/free's with n gcnew/collections, 
the malloc/free will come out faster, and you conclude that gc is slow. 
But that misses one huge speed advantage of gc - you can do FAR fewer 
allocations! For example, I've done a lot of string manipulating 
programs in C. The basic problem is keeping track of who owns each 
string. This is done by, when in doubt, make a copy of the string.

But if you have gc, you don't worry about who owns the string. You just make another pointer to it. D takes this a step further with the concept of array slicing, where one creates windows on existing arrays, or windows on windows on windows, and no allocations are ever done. It's just pointer fiddling.

------ Walter Bright http://www.digitalmars.com C, C++, D programming language compilers http://www.astoriaseminar.com Extraordinary C++

Walter Bright wrote:

I haven't seen this in the development of git, although to be fair, you didn't mention the number of developers that were simultaneously working on your project. If it was you alone, I can imagine you were reluctant to change it just to see if something is faster.

Opensource projects with many contributors (git, linux) work differently, since one or a few among the plethora of authors will almost always be a true expert at the problem being solved.

The current pack-format and how it's read is one such example. It was done once, by the combined efforts of Linus and Junio (this is all off the top of my head and I cba to go looking up the details, so bear with me if there are errors). Linus and Junio are both very good C-programmers, but the handling of packfiles was not what you'd call their specialty. Along came Nicolas Pitre, another excellent C programmer, who probably has done some similar work before. He constructed a better algorithm, eventually resulting in the ultimate performance win with a net gain in both time and size (gj, Nicolas).

The point is that, given enough developers, *someone* is bound to find an algorithm that works so well that it's no longer worth investing time to even discuss if anything else would work better, either because it moves the performance bottleneck to somewhere else (where further speedups would no longer produce humanly measurable improvements), or because the action seems instantanous to the user (further improvements simply aren't worth it, because no valuable resource will be saved from it).

Andreas Ericsson wrote:

On my project, one. But I've seen this problem repeatedly in other projects that had multiple developers. For example, I used to use version 1 of an assembler. It was itself written entirely in assembler. It ran *incredibly* slowly on large asm files. But it was written in assembler, which is very fast, so how could that be?

Turns out, the symbol table used internally was a linear one. A linear symbol table is easy to implement, but doesn't scale well at all. A linear symbol table was implemented because it was just harder to do more advanced symbol table algorithms in assembler. In this case, a higher level language re-implementation made the assembler much faster, even though that implementation was SLOWER in every detail. It was faster overall, because it was easier to develop faster algorithms.

My point was that when I reimplemented it in D, the cost of changing the algorithms got much lower, so I was much more tempted to muck around trying out different ones. The result was I found faster ones.

That is a nice advantage. I don't think many projects can rely on having the best in the business working on them, though <g>.

Sure, but I suggest that few projects reach this maxima. Case in point: ld, the gnu linker. It's terribly slow. To see how slow it is, compare it to optlink (the 15 years old one that comes with D for Windows). So I don't believe there is anything inherent about linking that should make ld so slow. There's some huge leverage possible in speeding up ld (spreading out that saved time among all the gnu developers).

So while git may have reached a maxima in performance, I don't think this principle is applicable in general, even for very widely used open source projects that would profit greatly from improved performance.

------ Walter Bright http://www.digitalmars.com C, C++, D programming language compilers http://www.astoriaseminar.com Extraordinary C++

Walter Bright <boost@digitalmars.com> writes:

Well, my first system was a Z80 computer with an editor/assembler in ROM (4kb). At one time I tried figuring out the size requirements of symbols. It was two bytes for each symbol. Namely the value. The "symbol table" was located behind the source code. Whenever this marvel of technology encountered a label, it searched the source code from the beginning for the definition of the label, keeping count of all label definitions in between. When it found the definition, the count corresponded to the position in the symbol table.

So compilation times were O(ns), with n the number of symbol uses and s the size of the source code.

Implementing in a higher language would not have helped: memory efficiency was what dictated this layout. Given that the whole available memory was perhaps 50kB, assembly language modules could not get so large that scale issues were deadly. But the assembly times did get annoying sometimes.

Walter Bright wrote:

Well, when the ease-of-coding vs the exec-speed of D vs C is that of C vs asm, C will be dead fairly soon. However, since C is so ingrained in every language designer's head, I find that unlikely to happen any time soon.

True that. I know a fair few projects that could have done with borrowing one or two proper gurus, but even opensource programmers are selfish in that we usually only work for something that benefits ourselves.

True again, but given what I said above holds, it would be madness to move from the lingua franca of oss hacking to a less common one, as it would mean fewer eyes on the code.

Interesting. I recently did a spot of work comparing various string-hashing algorithms. Perhaps I should head over to the ld camp and see if I can help.

Walter Bright <boost <at> digitalmars.com> writes:

http://en.wikipedia.org/wiki/Gold_(linker)

Note that gold is written in C++; the wikipedia quasi-stub article doesn't make this clear. Normally that wouldn't be relevant, but in this branch of the thread it is. Its C++-ness seems to be making an argument, but I don't know on which side!

El 7/9/2007, a las 10:36, Walter Bright escribió:

While I accept that this is generally true, I think Git is somewhat of a special case. From a design perspective the data structures and algorithms are remarkably simple -- therein lies its elegance. I think it's precisely the kind of problem that can be tackled well with a close-to-the-metal language like C.

This mirrors my experience in desktop application development. Despite GC being "slower" the app actually runs faster and a lot of nasty problems (shared resources, locking etc) just magically go away. Development is easier too.

But once again I think Git falls into a special category where the design makes the "hassle" of developing in C worth it.

Wincent

Wincent Colaiuta wrote:

That may very well be true. I've never looked at the source code for git, so I'm not in any position to judge it. Nor do I suggest translating a debugged, working, 80,000 line project into another language.

My comments here are in more general terms.

Another reason GC is sometimes surprisingly faster is not only you end up allocating less times like you mention, but because some GC are compacting garbage collectors and that simplyfies allocations dramatically because allocating memory is just increasing a pointer. Compare that to the way most C++ heaps get implemented. I don't know if that's the case with D's GC though.

I completely understand what you say about the strings and who owns it, I've ran into the same situation a hundred times, not only with strings but with vectors, matrixes, lists, etc.

After reading your post, I think I will have to revisit D sometime. I read about it a few years ago and I got the impression some syntax decisions had been made to ease the writing of the compiler as opposed to favoring the end user/programmer, but it's been a while and maybe I was too quick to judge.

Steven

"Walter Bright" <boost@digitalmars.com> wrote in message news:fbr2iv$ugg$1@sea.gmane.org...

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

As long as TeX, Emacs and vi are around, I would not worry too much about dinosaurs in general. But C++ is a cancerous dinosaur. It has growths that just don't belong on a C body.

The problem with C++ is that every C++ developer has his own style, and reuse is an illusion within that style. Take a look at classes implementing matrix arithmetic: there are as many around as the day is long, and all of them are incompatible with one another.

With regard to programming styles, C++ does not support multiple inheritance. For a single project grown from a single start, you can get reasonable solutions. But combining stuff is creating maintenance messes.

With C, the situation is not dissimilar, but you spent less time fighting the illusion that you don't need to reimplement, anyway.

What nonsense. Large parts of git already are shell scripts, so obviously there is no such doctrine. Just because C++ is not a sane proposition does not mean that others might not work.

On Friday 2007 September 07, David Kastrup wrote:

(Disclaimer: I'm certainly not joining the "C++ for git" chant; this reply is merely to the statements made about C++ in David's message).

One could say the same about any API. "Take a look at that C library libXYZ - it does exactly the same thing as libPQR but all the function calls and structures are different. Conclusion: C is shit". Obviously nonsense.

Multiple inheritance is the spawn of the devil, but C++ _does_ support it.

Forgetting about the terrible STL, to me there really is no difference between C and C++; you can be object oriented in C. Take a look at the Linux kernel, it should be printed out, rolled up and used to beat the ideas into students learning C++/Java/C#. Object oriented design is a choice, and if you really wanted you could do it in assembly.

I would imagine the reason people often turn up wanting to rewrite Linux and git in C++ is because they are so object oriented in nature already and it's natural to think "wouldn't this be even better if I wrote it in an object oriented language"? Maybe, maybe not, but why bother?

Andy

Andy Parkins <andyparkins@gmail.com> writes:

The difference is that you can pass structures from one library into another with tolerable efficiency. Because there are only basically 2 ways to lay out a two-dimensional array of floats.

What about "With regard to programming styles" did you not understand? I was not talking about a technical feature at class level, but about code merging from multiple sources.

Maintainability and extensibility certainly are valid arguments for rewrites. But C++ does not really shine in that regard.

Hi,

On Thu, 6 Sep 2007, Dmitry Kakurin wrote:

You have a very strange way of not meaning to start a C vs. C++ war.

No, it's not. As has been shown by some very good _arguments_. Once you have facts to back up your claims, it is not any belief any longer.

Ciao, Dscho

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

I honestly didn't. I didn't even think it's possible. In the environment of mainstream commercial software development the last war on this subj was over 8-10 years ago. Even wars like "do we use exceptions/templates/stl" are pretty much over. Now days it's "do we use Boost", or "do we use template metaprogramming". But even more often it's Java/C# vs. C++.

That's why I was wondering how come C was chosen for Git.

Well I've heard *opinions* and anecdotal evidence. No facts though. And it's not surprising. There could be no hard facts in such a matter. It always boils down to "most of all, I want my software to be X" where X is different for different people (fast,maintainable,quick to market, scalable, beautiful, etc ... to name a few). With different values of X any debate is pointless. And X is exactly the matter of believes.

Anyway my curiosity is satisfied (thru the roof so to speak) and I think it's enough on the subj. It has reminded me of good old times though.

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

Anecdotal evidence _is_ hard facts. That's what experience is all about.

Dmitry Kakurin, Sat, Sep 08, 2007 02:32:09 +0200:

It is because the "environment of mainstream commercial software development" is stuck in "8-10" back from now.

Now that's a stupid argument to bring up. Commercial software development is were the most stupid mistakes are done and repeated.

"Just to annoy mainstream commercial software developers" would be a good reason.

http://www.research.att.com/~bs/applications.html

just as Bjarne once wrote in his TC++PL, its hard to teach an old dog new tricks. Its even harder to give quality education about how to use something to someone who doesnt want to learn.

you hate high level, then continue programming operative systems, please NEVER DO something else. C++ was designed to give programmers high level tools and still being able to take care about performance.

portability wont be possible after a standard is published and some couple of years given to the compiler developers. C++ had its standard in 1998, and add two or three years for compiler development = 2002. "Quite recently", way more recently that your last use of C++ I can bet.

figo <rcc_dark@hotmail.com> writes:

Care to explain why there are still not two numerical C++ libraries with compatible matrix classes?

What use is talking about portability and high level when a basic interoperability feature that has been available since the sixties (more than 4 decades ago) in Fortran has not yet managed to make it into C++? C++ by now more or less offers a (somewhat deficient) standardized way to work with complex numbers, but matrices are still not standardized in any manner, and libraries won't interoperate.

So C++ should get its head wrapped around the _low_ level problems first. It is a bloody shame that it still has not caught up with Fortran IV (or even Fortran II) with regard to usefulness for numerical libraries.

It is not a matter of "hating high level" to see that C++ is mostly focused about addressing the wrong kinds of problems in the wrong ways. The pain/gain ratio is just bad.

The C++ community in general suffers a lot from the NIH Syndrome. Matrixes, Strings, Vectors, everybody creates their own which are always, or course, superior to what's already available.

Again, is not the language's fault, a language is just a language. It's the way it has been driven.

My two cents.

"David Kastrup" <dak@gnu.org> wrote in message news:86odfstbc6.fsf@lola.quinscape.zz...

"Steven Burns" <royalstream@hotmail.com> writes:

Having loose wires instead of a brake pedal in a car because the user might prefer to brake with his teeth or by wiggling his backside or building any other contraption of his own invention is a design mistake. Especially when we are talking about public transportation with changing drivers.

Making a language huge and bloated in order to be able to use the language itself for defining a set of basic data types is just masturbation. C++ has the most complicated set of implicit conversions from any language in the world, and what for? It is modeled for being able to create a user-defined "complex" type which behaves almost as well as Fortran's. Too bad that this mostly means everybody will define his own type (well, at least we have seen two or three different library "standards" by now), and that the implicit conversion rules and chains are appallingly wrong for a number of other possible user-defined arithmetic types.

Linus Torvalds <torvalds <at> linux-foundation.org> writes:

C++ has one weakness that is ABI compatibility among compilers. Other than that Object Model does not make things horrible. I have seen 15 years old C++ application library which still uses old implementation to implement new enhancement/features that just works seamlessly and even an old dog can learn this old library written in C++.

I have seen C programmers constantly trying how they can mimic poly-morphism, inheritance and encapsulation in their C. This is just *BS* - if you dont want C++ then dont use poly-morphism, inheritance and encapsulation in your C code! Or else just use C++ or Jave or C#.

Regards Please note: I am really a Fan of Linus Torvalds since ever :) Syed Raihan

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

Word to the wise... you effectively just told one of *the* best known programmers of all time that they are talking BS... nice one. Hope you've got some flameproof undies. Whats that? no? ah well...

I smell a troll, but since everyone else has had a go...

Heres some comments picked out from the thread, in no particular order...

Really? I dont know what planet you're from, but this 'war' has been raging for decades, and will probably continue until one side or the other gets round to using tactical nukes.

And besides, this *isn't* the commercial (closed) software world - we've moved on. We no longer depend on closed companies handing out features like orphans in the Victorian times...

Sadly. Thats always been one of the things I found annoying in C. There are times when you want access to the types the hardware itself uses, and there are times when you want to know your int is 32 bits long, and there isnt really a standardised way of doing that. Of course, its worked around in practice, but it all seems so unnecessary.

The above comment is pure epic win :-)

On another note, some people talked about code reuse...

IMHO Sourcecode reuse is something of a myth in any language. Sure, some small algorithms get reused, but thats really not a language dependent characteristic. As soon as you build something much bigger than an algorithm, it starts to need an interface, and at that point you may as well turn it into a library. Thats where the REAL code reuse happens. And as it happens at runtime, its good for users - bugfixes help everyone.

On to language choice...

I have NEVER understood why people seem to think theres some kind of hierarchy in either ease of coding or speed. You see it all the time, people think that:

assembler is faster than c is faster than c++ is faster than perl etc.

WHY? I've seen some truely braindamaged assembler that could be outperformed by BASIC on a BBC micro. I've seen 'handcrafted' C and C++ that looked like it was written during a skydive whilst on crack.

languages are *tools*. Pick the most appropriate. Use two. Embrace the power of and...

Linux make good use of C and assembler, both compiled/assembled seperately and inline. Some stuff like accessing weird registers with oddball opcodes is actually impossible under C. But (say) write a filesystem in assembler? no thanks! (not that it hasn't been done, but for the love of god, why?)

So, anyway, why do these kind of threads never go away? because opinions are like arseholes. Everyones got one. As you grow older, you learn stuff. You hopefully dont repeat the mistakes of ones youth. (theres at least one ill-conceived C string library out there which I'm embarrased to admit is my fault (hopefully it'll never leave the company I was at when I wrote it...). These threads are where the n00bs meet the pros. Usually, the n00bs just need to suck it up and admit it when they've been dumb. Its a very rare day when something truely radical comes along, and its even rarer when its born of total inexperience.

Nothing to see here...

All the best,

-Ian

PS. ironically, in order to post this, gmane required me to enter a word. That word was "restraint". Gotta love karma.

Ian Molton <ian.molton@collabora.co.uk> writes:

No gain from C++.

Also, I don't know when Dmitri written his post, but git uses its own
string manipulation mini-library, named strbuf, at least since end of 2007
(Documentation/technical/api-strbuf.txt was added as stub on 2007-11-24).
 

Sidenote: block-sha1 implementation is C plus smidgeon of assembly via
'asm'.

On Fri, Jun 11, 2010 at 9:23 AM, Jakub Narebski <jnareb@gmail.com> wrote:

An interesting point, Dmitri written this post on September 2007... why the flamewar continuation? just curiosity...

Now, as a resume of flames and concepts, the 'better' things in the string library (also the first excuse for C++ apologists, as a repetitive piece of youknowwhat) are pure algorithms and data structures, easy to code in C. The goal isn't in the OO design or abstraction itself, or in the language...

Personally, I use C++ almost every day at work and I found it stupid. I love pure C.

Cheers, Dario (argentina)

On Tue, 2007-09-04 at 22:50 +0200, Lukas Sandström wrote:

Please, no. Let's not pull in a dependency for something as simple as a string library. How many distros have bstring pcakaged? The right version? Does it work on Windows? We already have strbuf.c, lets just consolidate the string manipulation code already in git under that interface.

Kristian

Lukas Sandström wrote:

Unfortunatley, I haven't had any time inte the last few days to code, nor read mail. I'm assuming that there is no point in me finishing the patch and that git will go with the strbuf solution?

/Lukas