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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: weeding out c++ keywords from sys/sys
    ... Can you mention exactly which links were invalid for you? ... any movement within the Linux community to bring C++ support into the kernel. ... 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. ...
    (freebsd-current)
  • Re: [PATCH 3/7] inflate pt1: clean up input logic
    ... invalid initrd to kernel" would have been a simpler description. ... Boot firmware passes invalid arguments. ...
    (Linux-Kernel)
  • Re: Webcam
    ... > Invalid argument ... > hardware is recognised (everything works fine in camstream) ... The Philips webcams use the "pwc" kernel driver. ... 288x353, or get "pwcx" working. ...
    (comp.os.linux.hardware)
  • Re: [PATCH 3/7] inflate pt1: clean up input logic
    ... invalid initrd to kernel" would have been a simpler description. ... Boot firmware passes invalid arguments. ... The kernel does not have such functionality, ... if we have to have separate code to validate a compressed image, ...
    (Linux-Kernel)
  • Re: sensors fun..
    ... The goal of this framework is ... IMO to "collect" all this data in the kernel and provide a single ... point of contact for the userland to query this in-kernel data. ... I will answer to your mail where I talked about access to ISA stuff as time permits, and I try to do it in a verbose way so that the picture about Constantine's sensors framework is more clear. ...
    (freebsd-arch)