In DragonFly, there’s only a few places C++ is used. If you wanted to make sure DragonFly was pure C, Samuel Greear lists those remaining nooks and crannies.
10 Replies to “Ways to eliminate C++”
Comments are closed.
A running description of activity related to DragonFly BSD.
whats the point in that? C has its own problems
The point is remove bloatware
Edward, it would allow self-hosting with a compiler that does not support C++, like pcc. GCC would still be necessary for third-party software, of course.
What about Clang which is a modern compiler. I dont understand what is so good about ppc?
I think there are bigger fish to fry. Clang and llvm is a modern, self hosting, BSD license compiler that does both c/c++ . I hardly think c++ is going anywhere.
Oh btw, I recently compiled (last week) dragonfly with clang, it builds (with some nasty looking pointer conversion warnings) however it panics at boot.
Unfortunately I was unable to get a trace that made sense to me.
It is not about the technology, it is about maintainability.
The developers of DragonFly are all C coders, not C++. Hardly any of the committers are competent in C++. A C-only compiler has the potential virtue of being simple and able to be understood and worked on (debugged, at least) by the majority of the committers.
clang is an amazing piece of software architecture and an awesome compiler. But it is entirely written in C++ (which as pointed out, nobody knows how to work on), it is huge, it takes substantial resources to compile and it is a fast-moving target. DragonFly supports clang through /etc/compilers.conf and hopefully things will work well enough at some point that anyone who wants to do so can use clang as their only compiler. For aforementioned reasons, however, I feel clang to be totally unsuitable for inclusion into base. I could see it potentially being distributed alongside a C-only compiler along with snapshots and releases as a binary package at some point in the future, though, if the project heads that direction. At a bare minimum any C-only base compiler would have to be able to bootstrap a proper C++ compiler from pkgsrc.
Maintainability is about the biggest deal there is in a project like this. GCC, for instance, has gone significantly out of date more than once in the history of DragonFly in large part because it is such a complex piece of software to update.
Mdocml/mandoc isn’t groff replacement per se. It doesn’t support troff almost at all and that is by design. It is man/mdoc formater and I would say mandoc is better than groff in this task already.
Besides removing C++ you get fast, clean formater with quality output and promise of better searching capabilities. Developers are also very helpful and Kristaps even took his time to write great guide about writing man pages using mdoc macros (search for “Practical UNIX Manuals”).
We do already have mdocml in the tree.
blinkkin, the only use-case for groff in the tree is for the manpages.
I guess I should point out that I am not necessarily advocating that the project proceed in this particular direction so much as pointing it out and providing rationale in the event that DragonFly does move in a new direction wrt the compiler infrastructure. I don’t see any clear path that involves dropping gcc in the nearer-term.