On Thu, Apr 30, 2009 at 9:25 AM, Albert Cahalan <[email protected]> wrote:
> On Thu, Apr 30, 2009 at 1:59 AM, Michael Bruck <[email protected]> wrote:
>> On Thu, Apr 30, 2009 at 7:12 AM, Zach Welch <[email protected]> wrote:
>
>>> At the most fundamental level, it comes down to this:
>>>
>>> C == imperative programming
>>> C++ == object-oriented programming
>>>
>>> The different mindsets should yield completely different code. Their
>>> overall architectures could be virtually identical, but the code would
>>> not be structured even remotely the same.
>>
>> The current code looks to me as if in large parts it is a simulation
>> of C++ in C.
>
> Linux itself is highly object-oriented, and it hasn't been C++ since
> 1992 at least. (oo abstraction examples: vfs, block device, network
> protocol, scsi device, cd device, etc.)
>
> It has excellent style. It's highly readable as kernels go.
> If there is any question of changing style, follow Linux.
>
12 void blk_recalc_rq_sectors(struct request *rq, int nsect)
13 {
14 if (blk_fs_request(rq) || blk_discard_rq(rq)) {
15 rq->hard_sector += nsect;
16 rq->hard_nr_sectors -= nsect;
17
18 /*
19 * Move the I/O submission pointers ahead if required.
20 */
21 if ((rq->nr_sectors >= rq->hard_nr_sectors) &&
22 (rq->sector <= rq->hard_sector)) {
23 rq->sector = rq->hard_sector;
24 rq->nr_sectors = rq->hard_nr_sectors;
25 rq->hard_cur_sectors = bio_cur_sectors(rq->bio);
26 rq->current_nr_sectors = rq->hard_cur_sectors;
27 rq->buffer = bio_data(rq->bio);
28 }
29
30 /*
31 * if total number of sectors is less than the
first segment
32 * size, something has gone terribly wrong
33 */
34 if (rq->nr_sectors < rq->current_nr_sectors) {
35 printk(KERN_ERR "blk: request botched\n");
36 rq->nr_sectors = rq->current_nr_sectors;
37 }
38 }
39 }
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++.
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.
C++ brings simple safety measures like strong typing, auto-generated
virtual function tables a.k.a. class support, member access
restrictions, function name mangling etc.
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.
Michael
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development