Moving the kernel to modern C

Posted Mar 4, 2022 6:27 UTC (Fri) by marcH (subscriber, #57642)
In reply to: Moving the kernel to modern C by dvdeug
Parent article: Moving the kernel to modern C

> > But operator overloading and inheritance are very different: with them you don't know _which source tab in your own editor you should look at_! In other words, you get lost in _your own code_.

> Ultimately, if it's your own code, you should know what type is getting passed in and where to look for that code.

I should not have written _your own code_, I meant: you get lost _in the code base that you are working on_ as opposed to some external library, compiler or other abstraction you don't care about.

Most developers spend most of their time reading and debugging code they did not write themselves. Which is _exactly_ why kernel maintainers don't want C++

> If you don't believe that OO is useful for GUIs

I was just rephrasing you.

Moving the kernel to modern C

Posted Mar 4, 2022 14:57 UTC (Fri) by dvdeug (guest, #10998) [Link] (3 responses)

> I should not have written _your own code_, I meant: you get lost _in the code base that you are working on_

And it still stands; if it's the code base that you are working on, you should know what type is getting passed in and where to look for that code. Assuming you're not using Ruby, the type of the variable should be named nearby in the code.

And again, "I can't find which source tab to look at" is weird coming from someone bashing Java. In a.b(...), the code is found in file named after the type of a. In C, the definition of the function may be found in one of the files you #included in this code (or not; you can always declare external functions directly), but that header file name may have no relation to the file where the code is written. Of course, with the handy -D option to the C compiler, who knows what the function is actually named.

Moving the kernel to modern C

Posted Mar 4, 2022 17:28 UTC (Fri) by marcH (subscriber, #57642) [Link] (2 responses)

> Assuming you're not using Ruby, the type of the variable should be named nearby in the code. [...] In a.b(...), the code is found in file named after the type of a.

The type of the variable does not provide vtable resolution. That's done only at run-time. Same problem for explicit .ops function pointers in C. You cannot just "grep" through vtables / .ops because they're resolved at run-time. That's the whole OO proposition.

> Assuming you're not using Ruby, the type of the variable should be named nearby in the code.

Afraid you lost me there.

> In C, the definition of the function may be found in one of the files you #included in this code (or not; you can always declare external functions directly), but that header file name may have no relation to the file where the code is written.

Code indexers can do a surprisingly good job most of the time. For the rest there is always git grep. It works as long as nothing is resolved at run-time.

> Of course, with the handy -D option to the C compiler, who knows what the function is actually named.

I've seen many -D and I've never seen one redefining function names. As already wrote above, no one like the pre-processor and its abuse is very easily and routinely caught at code review. The entire problem with C++ is "where do you draw the line?". That's really not a problem with the pre-processor: it's always very obvious whether you use it or not and I've seen "no pre-processor here" review comments countless times.

Moving the kernel to modern C

Posted Mar 4, 2022 20:22 UTC (Fri) by marcH (subscriber, #57642) [Link]

BTW a great trick to unravel (evil) cpp macros is to deliberately insert a compilation error. gcc then shows the entire stack of macros involved. Much easier than cc -E or something.

Same trick with build systems and many other situations with "too many layers of indirections": deliberately injecting errors is often a great shortcut.

(none of that available at run-time of course)

Moving the kernel to modern C

Posted Mar 5, 2022 2:42 UTC (Sat) by dvdeug (guest, #10998) [Link]

> The entire problem with C++ is "where do you draw the line?".

That's a problem with C++, not operator overloading or object orientation.

> That's really not a problem with the pre-processor: it's always very obvious whether you use it or not and I've seen "no pre-processor here" review comments countless times.

It is quite similar to operator overloading; you can see where the macro or operator is defined, but not necessarily where it is used.