On Thu, Apr 30, 2009 at 10:00 PM, Albert Cahalan <acaha...@gmail.com> wrote: > 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.
The example was what should have been a member function. There is zero performance loss by what is essentially renaming "rq" to "this". I can't follow your clarity argument here, rewriting a member function to be a static function doesn't add clarity IMO. >> 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. It works nicely in OpenOCD too, if you are careful and don't mind bloated code or have tons of proprietary macros that simulate the well-documented behavior of C++. In fact it would also work nicely if one wrote OpenOCD in assembler. >> C++ brings simple safety measures like strong typing, > > C has this unless you ignore warnings. The C++ imitation involves endless amounts of (explicit) unsafe casts. Like in the example above. There is no way around that although macros can help avoiding simple typing errors. >> function name mangling > > So you can make a mystery out of which function > is actually getting called. :-) Benefiting from name mangling does not imply that people (have to) use polymorphism. I am surprised you didn't refer to the option to enforce function prototypes as a substitute... >> 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. I wasn't talking about hidden magic at all. arch_info is a pointer to subclass specific data which is unnecessary in C++ were such data is stored locally in the derived class. I was talking about changing the code that currently simulates C++ into real C++. Using operator overloading is way beyond that and if it is such an obstacle it can be discouraged in the coding standards. On Thu, Apr 30, 2009 at 10:06 PM, Albert Cahalan <acaha...@gmail.com> wrote: > On Thu, Apr 30, 2009 at 10:03 AM, Øyvind Harboe <oyvind.har...@zylin.com> > wrote: > >> C++ *can* be a pretty hellish language if one goes overboard >> with weird features and libraries... > > Right. Nobody intends to do this, yet it happens. > > Every developer has his pet C++ feature. Ultimately the > project ends up with the union of all pet feature sets. > Unfortunately that is normally far greater than the > intersection of all developer comfort zones. I'll take all the pet C++ features over all the pet macro-based-simulations of pet C++ features any day. Reading these comments one begins to think that the cyberspace must be littered with the rotting corpses of open source projects who dared to go near C++. Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
