From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 20:18:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E8F1106566C for ; Sun, 15 Feb 2009 20:18:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outu.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0BA8FC15 for ; Sun, 15 Feb 2009 20:18:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 67BB1245A; Sun, 15 Feb 2009 12:18:18 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 4C9182D6017; Sun, 15 Feb 2009 12:18:17 -0800 (PST) Message-ID: <49987895.2010502@elischer.org> Date: Sun, 15 Feb 2009 12:18:29 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Bruce Simpson References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <49983868.5010107@incunabulum.net> In-Reply-To: <49983868.5010107@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Reilly , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 20:18:18 -0000 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 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"