Thread (1 message) 1 message, 1 author, 2016-06-15
  • (off-list ancestor, not in this archive)
  • Re: C++ *for Git* · David Kastrup <hidden> · 2016-06-15

Re: C++ *for Git*

From: David Kastrup <hidden>
Date: 2016-06-15 22:43:36

Dmitry Kakurin [off-list ref] writes:
We've had this theoretical (and IMHO pointless) discussion C vs. C++
*in general*.
In no way I want to restart it.
Then don't.
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.
It won't.  It will _do_ exactly the same (modulo the tenfold
likelihood of compiler bugs) but hardly using the same code.
Yet the source code becomes more readable and MUCH less error
prone. How is this not a win?
Because it is just your claim that this is more readable.
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.
Well, what stops him from replying "we don't use C++ in Git, please
change your code and resubmit"?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help