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

[Parc <ne...@ri...>]

On Mon, Mar 11, 2002 at 12:09:30PM -0500, David Hovemeyer wrote:
> On Mon, Mar 11, 2002 at 10:35:01AM -0600, Parc wrote:
> > On Mon, Mar 11, 2002 at 11:15:14AM -0500, David Hovemeyer wrote:
> > [snip]
> > > is a clear benefit.  I want to avoid over-use of C++ features,
> > > especially constructors and destructors (which can cause major
> > > performance overheads if used carelessly).
> > 
> > What?  Constructors and destructors don't cause performance overhead.
> > You can't avoid calling ctors/dtors.
> 
> Right, I wasn't very specific.  What I meant was "constructors
> and destructors implicitly called for objects used by value",
> especially for hidden temporaries.  I have seen this become
> a huge source of overhead in C++ programs.
> 

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've conciously avoided using the dynamic "new" and "delete" operators,
> so we can completely avoid automatic calls to constructors and
> destructors made by the compiler.  (These calls can be made explicitly
> as needed.)
> 

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.

> > Perhaps what you intended to say was virtual functions?  Those would
> > cause some significant overhead.
> 
> Yes, there is some overhead associated with virtual function calls.
> However, they are exactly equivalent to calling a function through
> a table of function pointers, and every OS kernel I have seen
> uses this technique.
> 
> -Dave
> 
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.

-parc