> > As for remembering new names, that's a load of complete crap and I
> > find it hard to believe that you're raising the argument for honest
> > reasons.
> The scale of the kernel, the number and churn of developers, and the
> importance of not breaking things in a stable kernel tend to argue
> against you. Humans develop the kernel. Humans remember names well.
> You may think that's arbitrary, but when you change naming across the
> entire kernel, you confuse a very large and diverse group of people who
> do this because they enjoy it. It's hard enough when this has to happen
> for useful or necessary reasons; you're asking the kernel developers to
> accept it for a completely arbitrary whim that they have rejected
> successfully several times in the past.
C++ has how many additional reserved words? I believe the list is delete,
friend, private, protected, public, template, throw, try, and catch.
Renaming every symbol that currently has a name from this list to the
corresponding name with a trailing underscore is an easily understood
consistent change.
That you would argue against is with things like "not breaking things" is a
load of complete crap.
> You want C++? Fork the freely
> available source code at a convenient point and convert it yourself. As
> long as it stays GPL, you're perfectly within your rights so to do.
> Hobson's choice is yours. Belaboring this point is silly.
Making ridiculous arguments like that a consistent change of a small set of
names is "breaking things in a stable kernel" is silly.
And, FWIW, it isn't even necessary to change those names. That is only
needed to compile the kernel in C++, which is not what anyone was talking
about. Supporting C++ modules, for example, would work fine even if the
kernel had variables called 'class' or 'private'. (Though things could be
done a lot more cleanly if it didn't as it would require some remapping
before and after compilation.)
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
