On Thursday 27 April 2006 07:37, you wrote: > > If C++ doesn't work > > properly for a simple and clean example like struct list_head, why > > should we assume that it's going to work any better for more complicated > > examples in the rest of the kernel? Whether or not some arbitrary > > function is inlined should be totally orthogonal to adding type-checking. > > You misunderstood something. The struct list_head is indeed a perfect > type to be templatized with all members inlined. C++ works properly in > this case. I am not sure, if you can relieably use the container_of() magic in C++. Do you know? I have a C++ linked list example here: http://websvn.kde.org/trunk/extragear/security/pwmanager/pwmanager/libpwmanager/linkedlist.h?rev=421676&view=markup It is very simple and in some points different from the kernel linked lists. It has a separate "head" and "entry" class and it stores a pointer to the entry (the kernel linked lists would use container_of() instead) > Nothing works by default. I did not say that static constructors are > advantageous. I said that it is easy for the kernel to make static > constructors working. Global variables should be deprecated anyway. You are kidding. Must be... > > Plus this would > > break things like static spinlock initialization. How would you make > > this work sanely for this static declaration: > > > > spinlock_t foo_lock = SPIN_LOCK_UNLOCKED; > > > > Under C that turns into (depending on config options): > > > > spinlock_t foo_lock = { .value = 0, .owner = NULL, (...) }; > > I would make it exactly like this: > #define SPIN_LOCK_UNLOCKED (spinlock_t){0,-1,whatever} > spinlock_t foo_lock=SPIN_LOCK_UNLOCKED; > This is easy to change. The empty structures look far more painful. The lack of named initializers is one of the main reasons (for me) why C++ damn sucks. Hopefully they will include them in the next C++ standard. -- Greetings Michael.
Attachment:
pgpurZjv5Ondy.pgp
Description: PGP signature
- Follow-Ups:
- Re: C++ pushback
- From: "linux-os \(Dick Johnson\)" <[email protected]>
- Re: C++ pushback
- References:
- RE: C++ pushback
- From: Matthew Frost <[email protected]>
- Re: C++ pushback
- From: Kyle Moffett <[email protected]>
- Re: C++ pushback
- From: Roman Kononov <[email protected]>
- RE: C++ pushback
- Prev by Date: Re: [PATCH 13/16] ehca: firmware InfiniBand interface
- Next by Date: Re: C++ pushback
- Previous by thread: Re: C++ pushback
- Next by thread: Re: C++ pushback
- Index(es):
 |