Linked by Thom Holwerda on Mon 5th Nov 2007 21:47 UTC, submitted by yourabi
FreeBSD The second beta of FreeBSD 7 has been released. "The 7.0-BETA2 builds have completed and are on many of the FreeBSD mirror sites. If you want to update an existing machine using cvsup use RELENG_7 as the branch tag. Instructions on using FreeBSD Update to perform a binary upgrade from FreeBSD 6.x to 7.0-BETA2 will be provided via the freebsd-stable list when available." Additionally, there's a discussion on supporting a subset of c++ in the FreeBSD kernel.
Thread beginning with comment 282942
To read all comments associated with this story, please click here.
why K/C++ for FreeBSD?
by project_2501 on Tue 6th Nov 2007 01:12 UTC
project_2501
Member since:
2006-03-20

The post mentions a proposal for the use of a subset f C++ (or K) http://wiki.freebsd.org/K

Before speaking of the evils of compiler dependency and pushing yourself out of the reach of programmers, I'd be interested in the reasons why they think plain and standard C is not good enough?

If its access to things like kernel data structures libraries like linked lists and queues then there's nothing wrong with a "collections" abstraction in C. There's also a danger that OS design follows the proposed K/C++ metaphors - minimising metaphors is better for OS evolution.

Reply Score: 2

RE: why K/C++ for FreeBSD?
by meianoite on Tue 6th Nov 2007 03:25 in reply to "why K/C++ for FreeBSD?"
meianoite Member since:
2006-04-05

Before speaking of the evils of compiler dependency and pushing yourself out of the reach of programmers, I'd be interested in the reasons why they think plain and standard C is not good enough?

If its access to things like kernel data structures libraries like linked lists and queues then there's nothing wrong with a "collections" abstraction in C. There's also a danger that OS design follows the proposed K/C++ metaphors - minimising metaphors is better for OS evolution.


I think I disagree with every point you made =P

First, plain C *is* good enough, as is any Turing-complete language. The point here is how to do it in a way that is less error-prone.

Some ways to make code less error-prone are by writing less code, making it easy to express ideas bearing higher levels of abstraction, and by enforcing reusability of code you know is both correct and efficient. And macros can only go so far. It's entirely possible to write object-oriented code in plain C, but it's just not convenient. At all. Ugh.

What they're going after resembles a lot the research on aspect oriented programming(*), in that you enlist the shielding requirements of a given piece of code, and just write the code and letting the compiler environment take care of the work. The prime example here is locking: if C directly supported the monitor locking model, most locking problems wouldn't exist. The fact that you must deal with it by hand causes errors and makes you spend a lot of effort on repetitive, almost boilerplate-like code that you must customise a little bit for every different situation.

The sheer mechanics of such tasks lead to subtle errors: forgetting to unlock on the right place, double locking, double unlocking, inverting locking order, not having a mechanism to release locks held by "rogue" processes... I could spend whole pages discussing those problems.



All in all, I believe that the ideal solution would be some bytecode, register-based, JIT-compiled scripting language that can be easily modified (read: instrumented) on symbolic form during runtime. If this sounds dangerously close to LISP or Lua (actually the Metalua variant) to you, you're spot on. The downside of those two is that the latter is different enough fom C to warrant justified arguments about barrier-to-entry and learning curves (despite the fact that Lua is probably the easiest-to-learn programming language I've ever encountered), and the former is different enough from everything else to warrant revisiting the remarks I made about Lua, only a thousand times worse.

But if leaving the job of producing kernel-oriented machine code to a JIT compiler gives you the creeps, an alternative would, again, write a customised preprocessor in Lua (which is small enough to make part of a compiler toolchain, and its interface to C is second to none) that takes the linguistic constructs they're after, and produces annotated C code afterwards, with all the plumbing in place (and for the love of God don't suggest preparsing the sources with Yacc/Lex, not this day and age!). It would make expressing stuff like shared areas very easy, while producing compilable code that uses the API that's already in place.



(*) And seeing how Sun made it with DTrace, I think my suggestion is no way far off from reality. WTF, they wrapped self-modifying code on a C-like scripting language!


Edit: typo, and brought the points about Yacc/Lex (I still have bad dreams about these two =P)

Edited 2007-11-06 03:33

Reply Parent Score: 5

RE[2]: why K/C++ for FreeBSD?
by meianoite on Tue 6th Nov 2007 04:19 in reply to "RE: why K/C++ for FreeBSD?"
meianoite Member since:
2006-04-05

Replying myself:

All in all, I believe that the ideal solution would be some bytecode, register-based, JIT-compiled scripting language that can be easily modified (read: instrumented) on symbolic form during runtime.


That is, assuming that, for various reasons, they won't go C++. RAII is a mighty powerful idiom for resource management.

Brilliant message on the benefits of C++:
http://lists.freebsd.org/pipermail/freebsd-arch/2007-October/007003...

Reply Parent Score: 3

RE: why K/C++ for FreeBSD?
by Brandybuck on Tue 6th Nov 2007 04:12 in reply to "why K/C++ for FreeBSD?"
Brandybuck Member since:
2006-08-27

Before speaking of the evils of compiler dependency and pushing yourself out of the reach of programmers, I'd be interested in the reasons why they think plain and standard C is not good enough?

Pushing out of the reach of programmers? Sounds like pretty poor programmers! While C++ is certainly "meatier" than C, it's not going to be pushing any competent developer away.

I haven't yet read their article, but C tends to be suitable for low level systems programming, while C++ is more suitable for high level applications programming. The fact that they are considering it, tells me that the want (not need, but want) a higher level of abstraction. Namely objects. You can do OO programming in C, but so what? You can do OO programming in assembly! You use C++ because it makes the OO easier!

Reply Parent Score: 1

RE: why K/C++ for FreeBSD?
by kaiwai on Tue 6th Nov 2007 04:20 in reply to "why K/C++ for FreeBSD?"
kaiwai Member since:
2005-07-06

Read up on Apple's C++ subset and their driver framework; there are a few things which Apple do right - especially in the highly technical area, its sad that other projects don't take advantage of these opensource components.

Atleast if the BSD's stanardised on the I/O Kit (http://en.wikipedia.org/wiki/I/O_Kit) it would also reduce the barrier for driver writers - and the bonus of having an elegant driver API as a cherry ontop.

Edit: Although the above was probably so far off topic, it isn't funny - the main point I was trying to get at is this; lets stop the C++ hate. What I see is the hate spread by those who either have never used it or when they have used it, they've done so in such a bad manner it gives nightmares.

I've dabbled in C and C++ (and funny enough found that C++ was easier to learn/understand than VisualBasic). To blame the language for the stupidity of the programmer is short sighted at best.

Edited 2007-11-06 04:23

Reply Parent Score: 2

RE[2]: why K/C++ for FreeBSD?
by meianoite on Tue 6th Nov 2007 04:40 in reply to "RE: why K/C++ for FreeBSD?"
meianoite Member since:
2006-04-05

Edit: Although the above was probably so far off topic, it isn't funny - the main point I was trying to get at is this; lets stop the C++ hate. What I see is the hate spread by those who either have never used it or when they have used it, they've done so in such a bad manner it gives nightmares.


They're not avoiding C++ for the (hypothetical) ugliness of it, but for
1) the potential for misusing language features;
2) the availability of suitable compilers for whichever architectures FreeBSD may support. Specifically, PHK seems to be wary of depending on a GPLv3 compiler.

Now, 2) is a much more of a political than technical decision, but it is theirs to make. 1) is really about education; aside from the danger of falsely believing some clever C++ trick actually works on kernel-land as well as it does on user-land, some C++ code is a joy to read, while some is like having your wrists slit by a rusty blade, while actually imploring to have your eyes slashed out (by said rusty blade).

*shivers*

Reply Parent Score: 2