Date: Tue, 30 Oct 2007 11:11:24 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Alfred Perlstein <alfred@freebsd.org> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Garance A Drosehn <gad@FreeBSD.org>, freebsd-arch@FreeBSD.org Subject: Re: C++ in the kernel Message-ID: <20071030181124.EC35B5B30@mail.bitblocks.com> In-Reply-To: Your message of "Tue, 30 Oct 2007 10:37:35 PDT." <20071030173734.GV33488@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> * Bakul Shah <bakul@bitblocks.com> [071030 09:36] wrote:
> >
> > The structured macro paper referenced on the K wiki page also
> > seems rather interesting. A powerful macro facility needs to
> > be well integrated with the language (much like Lisp or
> > Scheme's macros) so that you can write for instance
> >
> > critical_section(lock) {
> > ...
> > bar:
> > ...
> > if (cond1) break;
> > ...
> > if (cond2) goto foo;
> > ...
> > if (cond3) goto bar;
> > ...
> > if (cond4) return; // from enclosing function
> > ...
> > }
> > ...
> > foo:
>
>
> do you mean like C++:
>
> do {
> critical_object critical_instance();
>
>
>
>
> }
No idea but I can not see how that will do what I had in mind. A purely
lexical translation of the snippet I gave above would be something like:
/* struct mtx lock is a non local object */
{
mutex_lock(&lock);
...
bar:
...
if (cond1) goto _break11;
...
if (cond2) goto _foo12;
...
if (cond3) goto bar;
...
if (cond4) goto _return13; // from enclosing function
...
_break11:
mutex_unlock(&lock);
break;
_foo12:
mutex_unlock(&lock);
goto foo;
_return13:
mutex_unlock(&lock);
return;
}
...
foo:
This as an example of what *I would want* a macro facility to
do! Implementing such a facility would not be very hard
(after all it is just tree surgery) but coming up with a
macro language that is non-ugly is very hard and I do realize
that. One level up, this is *one way* to achieve writing
error free mutex code. Another is through some sort of
static analysis tool. A third is through code walkthroughs.
Each has different costs.
> Just wondering how much of this we want to roll on on our own.
So am I! But it is worth pursuing some of these threads at
the discussion level.
The more important point is the underlying "need" which we
can all agree on (I hope!), which is to be able to write such
code in an error free way. If we have such a list we can
figure out which ones to focus on and how to satisfy them.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071030181124.EC35B5B30>