Re: [Geekos-devel] first release of experimental version

[David H. <da...@cs...>]

On Mon, Mar 11, 2002 at 11:24:30AM -0600, Parc wrote:
> Hidden temporaries are only a problem when you don't keep them in mind.
> A well constructed default ctor will keep overhead to a minimum.  Once
> you're in C++, you should be passing by reference for the most part anyway.

I agree to some extent.  For the most part, however, I don't think
objects with by-value semantics will be necessary in the kernel.
Currently, I think there is only one place where a struct is allocated
on the stack.  In general, all interesting objects will be
allocated in the kernel heap.

> What are you using to allocate/free memory then?  Ignoring the internal
> free pool, if you don't use new/delete, you're going to screw up inheritance
> down the line.

  - kmalloc() and kfree() for the memory allocation
  - explicit call to constructor via the placement new operator
  - explicit call to destructor

There are two reasons I don't want dynamic new or delete.

First, at some point I may want an additional parameter to kmalloc()
specifying whether the caller wants to wait for memory if there
is a shortage.  This is hard to do with "new".

Second, and more importantly, I want to be able to return a null
pointer to indicate any problem with the creation of the object.
C++ doesn't allow new to return null.  You're supposed to use exceptions
to signal errors in a constructor, and I definitely don't want to
use exceptions (mostly because I don't understand the runtime
requirements for C++ exceptions as implemented in GNU C++).

So, I make the constructor and destructor private, and use static
member functions to do object creation.  The static function does
the resource creation.  If successful, it invokes the constructor,
which cannot fail.

> Multiple inheritence would cause more overhead, just to clarify my point.
> Further, implementation of inheritence is the responsability of the compiler
> and is not specified by the standard.  Most compilers use a vtable, but not
> all(not that it matters since you can only compile with gcc).  It's entirely
> possible(albeit stupid) to not have O(c) lookup time for a function.

Multiple inheritance is evil!  My brain gets tied in knots just
trying to think about how it works.  I do not expect to use multiple
inheritance, ever.

-Dave