OpenBSD base now free of C++

You can still add g++, boost and other high-quality C++ libraries to OpenBSD via ports/packages. They just prefer plain C in the base install. Plain C is inline with their "keep it simple" philosophy.

What an interesting development. The year is 2011 and we are proudly announcing removal of C++ due to bloat.

I write more C++ than C, but this still makes me happy.<p>Some people set an objective, for whatever reason, and accomplished it. Other people seem happy with the result.<p>I'd call that a positive outcome for OpenBSD and all the developers involved. Cheers!

Wow, another reason to check back in with OpenBSD. Regardless of the meta debate on C++'s virtues or issues, having the core system build with just C would seem to help in simplifying things.<p>I am perhaps in the minority but I would really like a straight forward to build and maintain UNIX derivative and perhaps this can be it.

Language purity for a project is never bad, it makes it easier to contribute to a project. However, this is barely a feature, given that C is weakly typed and common C functions do not use boundary checks<i>.<p>For an operating system that aims to be secure, one would expect a more progressive stance, and heavy (intellectual) investment in a language that makes safety easier.<p></i> Yes, I know that OpenBSD prefers more secure variants of common functions.

It's funny, they are so proud of it. Groff is so ancient, you can't seriously claim it's written in C++. It's written in C++ circa 1988. Pre-template collections, no Standard library, no namespaces, no exceptions, practically plain C code. Well, not plain exactly, C with classes and virtual functions. I guess, OpenBSD folks didn't like virtual functions...

It'd probably be too much to hope that this catches on and becomes a trend.

So they replaced a generic roff system with a specialized man page viewer? Why? I mean, if you're rewriting everything <i>and</i> include a bevvy of output formats, why not make it a proper replacement? Would be quite a bit more unix-y. Yes, maybe a bit more work in the end, but you could always have "oroff 0.1" which only supports a -man subset evolve into a full-fledged implementation. Going from mandoc to "oroff" seems less likely.<p>(Or I'm just the only one who still occasionally uses ms/tbl/pic…)

I'm curious if someone can elaborate more on this. Is C++ in general <i>that</i> much more time-consuming to compile than C code? Or is it just an issue with gcc vs g++? Or is this issue unique to Groff?