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

Bruce Simpson wrote:
> Gary Jennejohn wrote:
> ...
>> It isn't exactly confidence building that all the links on this page
>> are invalid.
>>   
> 
> I was able to access all of the links on that page without problems from 
> archive.org.
> The original content has moved, this seems to be due to a 
> re-organisation within the university concerned.
> Can you mention exactly which links were invalid for you?
> 
>> This is all from 2005 and AFAICT has languished since then.  I'm not 
>> aware of
>> any movement within the Linux community to bring C++ support into the 
>> kernel.
>>   
> Not much changes in an established programming language in 3-4 years, 
> unless it is still mutating (e.g. C#, Python).
> 
> This is pure speculation on my part, however: I wager the patches had 
> bit-rotted for no good reason other than lack of interest or ignorance, 
> certainly not from active opposition, perhaps apart from Linus Torvalds 
> who had weighed in against C++ in other threads.
> 
> FreeBSD is not Linux, however, and the jury's still out on this one.
> 
>> I haven't been paying much attention to this thread, but I can't recall
>> having read any persuasive arguments for using C++ in the kernel.
>>   
> 
> Kernel-like systems are built with C++, this is just a fact of life. 
> Think games, think embedded systems.
> 
> You personally may not be writing systems to run fast and low-level in 
> C++, but I can think of at least 3 people I know personally who have 
> done and continue to do so. Given, they are folk who have spent a long 
> time learning C++ -- the tool has a steep learning curve, and Bjarne 
> Stroustrup himself would no doubt be the first to admit this.
> 
> Whilst code such as the Standard Template Library (STL) may not be an 
> appropriate fit for all low-level uses, the fact of the matter is, 
> something from <algorithms> has had many pairs of eyeballs on it. Having 
> to hand-code stuff like set symmetric difference is tedious if you don't 
> actually have to do it. If you do -- work smarter, not harder.
> 
> I wonder if many of the objections raised against C++ have actually been 
> considered in the light of the new C++0x spec.
> 
> At the moment, there are several projects out there which don't even 
> involve C++ in the *kernel*, which are directly impacted by the issues 
> which Andriy is attempting to solve because they use the system headers; 
> I therefore fully support what he is doing, as he is saving people a lot 
> of hassle.
> 
> It's time to get real, and admit that C++ is a very powerful tool that, 
> whilst it can be misused in untrained hands, can be very powerful in 
> skillful hands. Just because something isn't to one's personal tastes, 
> doesn't mean it should be regarded as anathema or mandatory, IMHO.

I've come to the conclusion that unembelished C is actually the wrong
language for kernel development. I think that something a bit higher
should be used as a framenwork for C-like processing segments.

I should be able to specify that a entity is:
* Mostly read from, rarely written to.
* Has an LRU requirement
* has to be looked up on some field
* has to be connected to some other entities in some way
* can be invalidated while other components hold references to it.
etc.

and The framework should handle all that, including adding the
appropriate fields to the structs etc. I should only need to do
code for teh specific things for that structure that the framenwork
doesn't handle.

There are some factors of C++ that allows SOME of this but
I would like to go even further and make the framework actually
generate the classes from which we derive the actual entity we use.

In particular I think that locking should be automatic, and that
while it can be "influenced" (i.e. telling the framework about
access patterns) it should then be handled automatically.

Modularization and dependencies should all be handled automaically.
we have the basis of this technology but we still have to do much
too much "by hand".

I know its all very optimistic, but 35 years of programming
tells me that eventually someone will get there and then
all other OS kernels will become out of date over-night.

> thanks,
> BMS
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"