
OpenBSD base now free of C++ - cannedprimates
http://undeadly.org/cgi?action=article&sid=20110314142734
======
16s
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.

~~~
tedunangst
g++ hasn't gone anywhere.

~~~
henryprecheur
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++.

~~~
alextingle
And what will they do when GCC moves over to C++?

~~~
16s
I believe they are working on pcc (for various reasons).

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

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

~~~
goalieca
> and its replacement is much faster in rendering manpages

Besides the build bloat, that certainly hints at it.

~~~
tzs
Mandoc is a tool specifically for formatting man pages. Groff is a general
typesetting tool. That probably accounts for most if not all of the difference
in speed.

~~~
jrockway
Probably a good choice. For a workstation, you might encounter the need for a
typesetting system. But for your router, you probably don't need it. So I
think OpenBSD made the right choice about what to ship in core.

~~~
JoachimSchipper
troff is technically a general-purpose typesetting system, but how many people
are still using it for anything other than formatting man pages? (La)TeX and
other formats have pretty much taken over.

~~~
wladimir
Indeed. I hope Linux distributions will follow with replacing Groff. It's a
huge, slow, ancient system and for the purpose of formatting manpages it can
be replaced by a 15-line Python script.

(this has _nothing_ to do with C++ versus C, simply with removing some bloated
UNIX legacy code)

~~~
JoachimSchipper
Well, 15 lines is a bit optimistic. mandoc is ~25 000 lines of C, and not yet
complete.

~~~
wladimir
I was figuratively speaking. In Python it'd be less lines than C, but still a
substantial project.

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

~~~
silentbicycle
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
Not being familiar with OpenBSD, what are some of the pain points you have
when using Debian that you don't experience with OpenBSD?

~~~
silentbicycle
I don't like apt-get. The way they break up packages is annoying and sometimes
leads to debian-specific forks. I also hoped that Debian's vastly larger
community would mean discovering several good packages apt-get (which I'd port
to OpenBSD), but there really hasn't been much that OpenBSD doesn't already
have. Disappointing.

GNU coreutils. The BSD userland (the core system) is much better integrated,
which affects a great many things. In particular, I _really_ prefer BSD top.

When I installed some recommended package so that closing my netbook's lid
would make it suspend, it didn't work. I read the source, and it was so
obviously broken (among other things, it was suspending on lid-close AND lid-
open) that I just wrote my own. Usually I contribute patches, but...eh. Other
stuff that tried to "automagically" configure itself, but didn't work quite
right, and interfered with manual configuration.

"This project only has a man page because we want to note that man pages suck,
look at the info page instead." I hate empty man pages, and it's particularly
annoying because the documentation on OpenBSD is phenomenal.

I prefer /etc/rc.conf to /etc/init.d/ , though that's fairly minor. (I usually
run daemons via runit anyway.)

There are probably several other things that don't come to mind at the moment.

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

~~~
protomyth
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).

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

~~~
protomyth
Since OpenBSD still compiles on a VAX, removing C++ from the build is a decent
feature. As you say, OpenBSD has function with bounds checking and that seems
to satisfy their requirements. Also, they haven't achieved language purity and
I don't think they are trying.

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

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

------
mhd
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…)

~~~
henryprecheur
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).

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

~~~
protomyth
Resources, need, and code audits are the reason to build a simple tool that
does the job you want.

------
j_baker
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
C++, especially template heavy code, is orders of magnitude slower in
compiling.

Clang and LLVM is faster but not that much faster.

