Re: weeding out c++ keywords from sys/sys

From: Andriy Gapon <avg_at_icyb.net.ua>
Date: Sun, 15 Feb 2009 20:53:33 +0200
on 15/02/2009 19:50 Marcel Moolenaar said the following:
> 
> On Feb 15, 2009, at 7:33 AM, Christoph Mallon wrote:
>> More robust error handling and less tedious resouce management 
>> directly come to mind:
>> Just look at normal C functions which allocate resources and have 
>> multiple points which can fail. They are the usual mess of if()s, goto 
>> error and lots of cleanup code. Further all this code looks pretty 
>> much the same in several modules. In C++ you write the resource 
>> handling code once (constructors/destructors) and then you cannot 
>> forget to clean up, because thanks to scoping and defined life ranges 
>> it happens automatically.
> 
> While on the surface this looks better, under the hood
> it's just the same. Worse in most likelihood, because
> with C the programmer writes the logic that is known to
> be needed (assuming no bugs). With C++ it's the compiler
> that generates code that handles all possible scenarios,
> and goes beyond what is strictly needed -- as such the
> cost tends to be higher, even when there are no errors
> or exceptions.

Then maybe we should stick to assembly? Just thinking about how I have 
two use two operators "/", "%" where I can do with only one x86 assembly 
instruction makes me mad - not.

I.e. this is not to say that I am against assembly - there are many 
places in our kernel that would be plain impossible to code with C.
And not to say that I am against C. This is only to say that there are 
certain things that are much easier, and safer too, to code in C++ that 
in C. And that might be in kernel too.

> I'm not saying this is a problem. All I'm saying is that
> you move responsibility from the programmer to the compiler
> and in general this comes at a (runtime_ cost. One we may
> very well accept, mind you...
> 


-- 
Andriy Gapon
Received on Sun Feb 15 2009 - 17:53:41 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:42 UTC