C++ *for Git*

6 messages, 5 authors, 2016-06-15 · open the first message on its own page

C++ *for Git*

From: Dmitry Kakurin <hidden>
Date: 2016-06-15 22:43:36

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

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

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

is better than this:

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

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

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

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

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

- Dmitry

Re: C++ *for Git*

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:43:36

Hi,

On Sat, 22 Sep 2007, Dmitry Kakurin wrote:
We've had this theoretical (and IMHO pointless) discussion C vs. C++ *in
general*.
I think "pointless" is more to the point.

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

Ciao,
Dscho

Re: C++ *for Git*

From: Kyle Rose <hidden>
Date: 2016-06-15 22:43:36

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

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

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

Kyle

Dmitry Kakurin wrote:
We've had this theoretical (and IMHO pointless) discussion C vs. C++ *in
general*.
In no way I want to restart it.

Re: C++ *for Git*

From: Marco Costalba <hidden>
Date: 2016-06-15 22:43:36

On 9/22/07, Johannes Schindelin [off-list ref] wrote:
We don't want C++.  Why is that so hard to accept?
Dmitry, I think what Johannes says in the above line is 100% the core
point of this (sad) discussion.

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

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

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

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

Thanks
Marco


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

Re: C++ *for Git*

From: Martin Langhoff <hidden>
Date: 2016-06-15 22:43:36

On 9/23/07, Kyle Rose [off-list ref] wrote:
But that's irrelevant: git is written in C.  That's the way it is, and
you should accept that or fork.
Or - as Marco's done - write complementary bits to git. I'm a
Perl-head, and I've ended up writing bits of Perl for git, some of
them have been reimplemented in C, some have stayed in Perl.

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

Codefest > Flamefest

cheers,



m

Re: C++ *for Git*

From: Dmitry Kakurin <hidden>
Date: 2016-06-15 22:43:36

On 9/22/07, Marco Costalba [off-list ref] wrote:
On 9/22/07, Johannes Schindelin [off-list ref] wrote:
quoted
We don't want C++.  Why is that so hard to accept?
Dmitry, I think what Johannes says in the above line is 100% the core
point of this (sad) discussion.
Actually after a couple of responses to this thread I had a BFO
(Blinding Flash of Obvious). I cannot believe I was so naive :-). Now
I have my answer.

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

-- 
- Dmitry
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help