Re: [OT] Re: C++ *for Git*

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sun, 23 Sep 2007, Marco Costalba wrote:
> 
> Perhaps I have misunderstood, but the idea I got is that for Linus OO
> brings in more problems than what it tries to fix.

Not really.

I'm a huge believer in OO, and if you look at the kernel, for example, 
there's just a ton of interfaces that are basically object-oriented. All 
the VFS is, for example, is really just a object model around low-level 
filesystems. The same largely goes for virtual memory mappings, or indeed 
for things like the interrupt or DMA controller abstractions, the network 
packet filtering etc etc etc.

But I'm also a huge believer in *explicit*syntax*. People should see what 
is going on, and the abstraction should be explicit.

[ Honesty in advertising: we do end up often hiding *some* abstractions. 

  Sometimes it happens for historical reasons: if the code didn't have any 
  indirection/abstraction initially, we may end up using macros and inline 
  functions to hide the fact that it now is actually going through an 
  indirect object-oriented interface.

  And sometimes it happens because the thing is *so* common or *so* 
  obvious that making the indirection explicit is just syntactically too 
  intrusive. ]

And we do all of this in C. There is no need to go to C++ for any "object 
oriented principles". It really is just a syntactic issue, and in many 
ways the syntax "advantage" of C++ is actually a big *disadvantage*.

I'm one of those people who think that interactions should be *locally* 
visible. If you need to understand the "big picture" in order to 
understand what a line of code does, that's usually a bad idea. So 
syntactic tricks that hide what is actually going on are bad.

You can see some of my opinions on C in the extensions I did for sparse. I 
think the C type system is a bit too sloppy, and much of what sparse does 
is more totally static type checking. Things like being able to decorate 
types statically, and having to explicitly carry those decorations around 
is a *good* thing - because it does the opposite of hiding. Having to say

	struct somestruct __user *p

to explicitly say that it's a pointer to user space - and then having 
every function that takes that pointer have to have that "__user" there is 
a VERY GOOD THING.

That's very different from having "accessor functions" and making "p" an 
abstract type, and having the compiler automatically generate the right 
kind of access. That kind of stuff is TOTAL CRAP, and it's an example of 
how C++ has a horrible design, where you carry around _implicit_ knowledge 
instead of making the knowledge explicit and visible locally too.

(And no, C doesn't do it very well. The C type system makes it too hard to 
add explicit markers that get statically checked, and you generally have 
to do it by making the code unreadable by turning things into special 
structures, one for each use, or something like that).

The same goes for things like memory allocation. Memory allocation issues 
are often some of the *biggest* performance issues, and that means that 
they have to be explicit. I'm actually a big fan of GC, but most languages 
that implement GC do it exactly the wrong way in my opinion: they make it 
a fundamental thing that covers everything, and it all happens implicitly, 
instead of making it explicit.

I don't know how many people have noticed that git internally actually 
does do some garbage collection. It's just that we call it "caches", and 
we do it explicitly. I'd love to have a language that helps me with that, 
but I would *hate* to have a language that does it for everything. As it 
is, we *could* do garbage collection much more, but we don't, just because 
it's a bit too painful.

In practice, it means that I'm considering writing some helper routines in 
C, which actually would do exactly what I want them to do: make the 
(reasonably few) data structures that want to have a dynamic cache use 
that dynamic cache explicitly, the way we now do for delta caching etc.

There are a few features of C++ that I really really like. For example, I 
think the C preprocessor is absolutely horrid, and a preprocessor that is 
built into the language - and integrates with the syntax - would be 
wonderful. And while C++ doesn't improve on that, at least templates are 
an example of something like that. Not perfect, but that's the kind of 
feature that C really would like.

In the kernel, we (ab-)use the C preprocessor a lot for things like that. 
Some of our macros are really disgusting. I'm not proud, but it works 
well, and together with gcc extensions like "__typeof__" and thigns like 
"__builtin_constant_p()" you can do some rather powerful things.

But other parts of C++ are just nasty. The whole OO layer seems designed 
to do a lot of things implicitly and in the wrong way. I also disagree 
with exception handling, and the "new" keyword kind of exemplifies a lot 
of what is wrong in C++.

So in short:

 - the one big feature that I think really makes a huge difference to 
   people, C++ does not have: garbage collection. Yes, there are GC 
   modules, but let's face it, you can do that equally well in C too, it's 
   just slightly different syntax.

 - the stuff C++ *does* have is usually nasty. Implicit initializers and 
   destructors and the magic lifetime rules of objects etc are all just a 
   piece of incredible bogosity. And that all comes from the OO stuff that 
   is totally worthless, because it's really just syntactic fluff that can 
   be done easily in C.

 - the C preprocessor really is horrible, and every single language beats 
   C handily in this area. Except for C++, which didn't fix anything at 
   all in that area.

   Even assemblers have macro languages that allow conditionals, 
   repetition, nesting, etc etc.  C and C++? Not so much. (Some languages 
   don't need it, because the language itself is dynamic and you can do 
   everything from within the language - ie you just evaluate an 
   expression that you built up dynamically as in LISP etc).

   (And don't tell me about m4. It's a better preprocessor, but it's not 
   syntactically integrated, and it's too complex, imho)

There are other problems in C. The implicit type conversions should at 
least have some way to be disabled on a type-for-type basis.

		Linus