On Thu, Apr 30, 2009 at 2:25 PM, Michael Bruck <mbr...@digenius.de> wrote: > On Thu, Apr 30, 2009 at 9:25 AM, Albert Cahalan <acaha...@gmail.com> wrote: >> On Thu, Apr 30, 2009 at 1:59 AM, Michael Bruck <mbr...@digenius.de> wrote:
> This is a random snippet from the Linux kernel. > > The readability of this would benefit from removing those 23 rq's, > something that comes for free with C++. Nope. First of all, you could remove them in plain C. (via memcpy, struct assignment, macros, or inline functions) There are reasons why this wasn't done: clarity and performance. Performance here is about only copying the stuff that truly needs to be copied in **this** location. Clarity isn't just about simple-looking code. It's also about code that is very visible and no-nonsense in operation. Hiding all that behind some operator overload would serve to obfuscate what is going on. Of course there is a need for balance here; the common things are in fact dealt with in Linux code via macros and inline functions. > Also I am not aware of much use of class inheritance in Linux beyond > simple virtual function tables. To simulate this feature in OpenOCD > there are files where nearly every other function starts with > something like this: > > armv4_5_common_t *armv4_5 = target->arch_info; > arm7_9_common_t *arm7_9 = armv4_5->arch_info; > arm7tdmi_common_t *arm7tdmi = arm7_9->arch_info; > arm720t_common_t *arm720t = arm7tdmi->arch_info; > > This complete block would just disappear in C++ and with it all the > potential for typing errors that comes with this. Linux kernel code would fill in defaults. For example, you can ask for a struct inode. Some stuff is already filled in when you get it. This could well be in code that provides a particular type of struct inode to other code, filling in defaults appropriate for a block device inode. So a scsi driver asks for a block device inode, which in turn asks for a generic inode. It works nicely. > C++ brings simple safety measures like strong typing, C has this unless you ignore warnings. > function name mangling So you can make a mystery out of which function is actually getting called. :-) > In addition C++ code when run through a documentation tool like > doxygen will show the actual class structure unlike the code that > simulates that in C and it avoids fluff like the arch_info fields > above that distract from the actual classes. Such a documentation > would be especially beneficial for a project that wants to attract > newcomers as contributors who implement small tasks/drivers and who > need to see quickly what are the essential interfaces that affect > their task. Hidden magic isn't so good for newcomers either. Currently you can like at an assignment and know what it does. There isn't much chance that x=y is opening database connections or worse. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
