Re: C++ pushback

J.A. Magallon
2006-04-25T20:10:04Z

[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]

On Tue, 25 Apr 2006 13:09:47 +0400, Nikita Danilov <nikita@clusterfs.com> wrote:

> J.A. Magallon writes:
>
> [...]
>
> >
> > Tell me what is the difference between:
> >
> >
> > sbi = kmalloc(sizeof(*sbi), GFP_KERNEL);
> > if (!sbi)
> > return -ENOMEM;
> > sb->s_fs_info = sbi;
> > memset(sbi, 0, sizeof(*sbi));
> > sbi->s_mount_opt = 0;
> > sbi->s_resuid = EXT3_DEF_RESUID;
> > sbi->s_resgid = EXT3_DEF_RESGID;
> >
> > and
> >
> > SuperBlock() : s_mount_opt(0), s_resuid(EXT3_DEF_RESUID), s_resgid(EXT3_DEF_RESGID)
> > {}
> >
> > ...
> > sbi = new SuperBlock;
> > if (!sbi)
> > return -ENOMEM;
> >
> > apart that you don't get members initalized twice and get a shorter code :).
>
> The difference is that second fragment doesn't mention GFP_KERNEL, so
> it's most likely wrong. Moreover it's shorter only because it places
> multiple initializations on the same like, hence, contradicting
> CodingStyle.
>

Well, you could always have

sbi = new(GPF_KERNEL) SuperBlock;

And CodingStyle was written for C.

Just to make a thing clear: I'm not advocating to include C++ support in
current kernel. I just say that the only valid argument is that
'KERNEL IS C', and interfacing C with C++ just would add bloat and errors.
There is no technical argument to reject to write an OS kernel in C++.
It would not be slower not more complicated, and it will be probably safer
because it leaves less things (from thost you always _must_ do) to
programmers memories.

--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.16-jam9 (gcc 4.1.1 20060330 (prerelease)) #1 SMP PREEMPT Tue

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]