On Thu, 13 Jul 2000, Andrew Morton wrote:
> inline void *operator new(size_t size)
> {
> return kmalloc(size);
> }
Yes? Care to compile that? FYI, kmalloc() has _two_ arguments. And no, I'm
not being pedantic - choice of the second argument matters. Big way. C++
has a notion of "allocation", but kernel has not. What it has is "atomic
allocation", "dma-suitable allocation", etc. Choosing the right one is
_not_ a task for compiler - it's AI-complete. Always forcing atomic is not
an option, BTW - performance hit will be too serious.
> char *foo(int n)
> {
> return new char[n];
> }
Yes, sir. And now try to call foo() from the bottom-half. Woops...
> g++ -c -O -fno-exceptions t.cc
> size t.o
> text data bss dec hex filename
> 21 0 0 21 15 t.o
>
>
> This is a red herring. All of it.
Unfortunately, not all.
> I'm sorry, Victor but this one gets under my skin. If people want to
> write kernel code in C++ well good for them. All it requires of the
> kernel developers is to take the darn C++ keywords out of the headers.
> About an hour's work for someone who has a license for /bin/vi.
>
> This is an ideological language war masquerading as a technical and
> supportability issue.
>
> grrr...
<shrug> C++ is a valid choice in many situations. For the kernel it simply
isn't. Just as Miranda or LML - they need things that do not map on the
problem domain. C fits because of its minimalistic semantics - nothing
magical about that. It leaves tricky (_very_ tricky - try to invent rules
for that) choices for programmer. Yes, usually C++ compiler can do choices
of that kind. And that works for normal userland stuff. Here it's not an
option.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:16 EST