OpenBSD base now free of C++

http://undeadly.org/cgi?action=article&sid=20110314142734

by cannedprimates • 15 years ago

121 47 15 years ago

goalieca2• 15 years ago

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

troutwine• 15 years ago

I didn't catch the word "bloat" in the linked article, nor really any hint of such a complaint. Rather, it seems like the OpenBSD has happily announced the removal of C++ in their base because of compilation speed issues.

> Groff was also one of the slowest parts in a full build...

C++ compilers might be many things, but zippy they are not.

dchest• 15 years ago

Well, C++ compiler is bloat, as is standard library. There's an effort to use Portable C Compiler (which recently reached 1.0 http://pcc.ludd.ltu.se/news/) to compile OpenBSD.

Plus, from mandoc website (http://mdocml.bsd.lv/):

Why? groff amounts to over 5 MB of source code, ...

goalieca2• 15 years ago

> and its replacement is much faster in rendering manpages

Besides the build bloat, that certainly hints at it.

jckarter3• 15 years ago

Orthogonal to bloat, libstdc++ is a large, ugly, and hard-to-audit attack surface that I'm sure OpenBSD is glad to push out of core.

tedunangst7• 15 years ago

libstdc++ remains as much a part of core as it ever was.

16s2• 15 years ago

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.

tedunangst7• 15 years ago

g++ hasn't gone anywhere.

henryprecheur2• 15 years ago

Indeed, just to make it clear: There's no more C++ code in the OpenBSD's base, but g++ the C++ compiler is still present.

I don't think that g++ will be removed. Too many things are written in C++. And as long as GCC is present in OpenBSD, there's no reason to remove G++.

mhd2• 15 years ago

So they replaced a generic roff system with a specialized man page viewer? Why? I mean, if you're rewriting everything and 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.

(Or I'm just the only one who still occasionally uses ms/tbl/pic…)

henryprecheur2• 15 years ago

The main reasons for replacing groff were:

1. Groff is buggy

2. Groff is slow to compile & execute

3. Groff is not BSD licensed

mandoc has none of these problems. If you want a "generic" roff system, groff is available as a package.

According to http://mdocml.bsd.lv/

> groff amounts to over 5 MB of source code, most of which is C++ and all of which is GPL. It runs slowly, produces uncertain output, and varies in operation from system to system. mdocml strives to fix this (respectively small, C, ISC-licensed, fast and regular).

mhd2• 15 years ago

Those are reason why you wouldn't use groff, it still doesn't explain why – if you're taking the effort – you're not building a proper roff replacement, but some subset bastard program. And then hack stuff like tbl into the main executable. (Never mind that there's Plan 9 roff or the heirloom version)

I get it, nobody really seems to use non-man roff anymore. Still, subsetting and reinventing the wheel (partially) seems a odd solution for this.

dexen• 15 years ago

This isn't the program you are looking for [[ http://man.cat-v.org/plan_9/1/troff ]]

__david__• 15 years ago

> So they replaced a generic roff system with a specialized man page viewer? Why?

Because no one uses roff format for anything other than man pages any more. And even then, it's extremely common to use it only as "object code", output from some higher level/cleaner input format (perldoc, pydoc, docbook/asciidoc). I like that they have high level output formats (pdf, html, ascii) and hope that the package becomes an option in Debian at some point.

rch• 15 years ago

I write more C++ than C, but this still makes me happy.

Some people set an objective, for whatever reason, and accomplished it. Other people seem happy with the result.

I'd call that a positive outcome for OpenBSD and all the developers involved. Cheers!

ChuckMcM• 15 years ago

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.

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.

silentbicycle2• 15 years ago

I know I'm just one data point, but I've been quite happy with OpenBSD as my primary OS for over 7 years.

I'm running Debian on a spare laptop for "common Linux distro" testing purposes, but am continually annoyed by it.

adbge• 15 years ago

Not being familiar with OpenBSD, what are some of the pain points you have when using Debian that you don't experience with OpenBSD?

microtonal2• 15 years ago

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.

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.

Yes, I know that OpenBSD prefers more secure variants of common functions.

protomyth3• 15 years ago

When you only have 1 program using another language and it slows the builds, you tend to want to replace it. There are still scripts and such in different languages (ksh and I do believe some perl).

microtonal2• 15 years ago

Right, just as I said, it is always a good idea to make a project more (language) uniform. But that wasn't my main point.

sliverstorm• 15 years ago

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

j_baker2• 15 years ago

I'm curious if someone can elaborate more on this. Is C++ in general that 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?

theatrus2• 15 years ago

C++, especially template heavy code, is orders of magnitude slower in compiling.

Clang and LLVM is faster but not that much faster.

alexeiz• 15 years ago

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...

OpenBSD base now free of C++

Related Stories