Re: C++ in kernel (was Re: exception in a device driver)

Chip Salzenberg (chip@perlsupport.com)
Sat, 16 Jan 1999 13:43:42 -0500


According to Khimenko Victor:
> In <19990115230842.C767@perlsupport.com> Chip Salzenberg (chip@perlsupport.com) wrote:
> CS> According to Khimenko Victor:
> >> Even two constructs like
> >> A. someclass var(1);
> >> B. someclass var=1;
> >> are NOT equal!
>
> CS> Yes, and ... ? Initialization and assignment are entirely different
> CS> animals in C++. Anyone who doesn't know that isn't ready to _read_
> CS> C++ code, much less write it.
>
> Uh, oh, bummmm. This mean that YOU are one who "isn't ready to _read_ C++ code,
> much less write it". (Hint: there are NO assignment in BOTH constructs!).

You are mistaken, again. Statement (B) is default construction of
var, followed by construction of a temporary "someclass(1)", followed
by assignment of that temporary to var, followed by destruction of the
temporary. The compiler may elide the contruction and destruction of
the temporary under many circumstances; but the semantics are clear
nonetheless.

> >> If you'll use objects you are tied to VERY LIMITED C++ object model.
>
> CS> That's a feature, not a bug. C++'s object model is limited to
> CS> features that have efficient implementation and which penalize only
> CS> those who use them.
>
> Yes, but why use it at all ?

Static type checking with knowledge of inheritance; forced
construction and destruction; convenience. (C already has adequate
static type checking if you use composition instead of inheritance.)

> CS> Base *target = new Derived1;
> CS> // begin transmogrification
> CS> void *p = dynamic_cast<void *>(target);
> CS> target->~Base();
> CS> target = new (p) Derived2;
> CS> // end transmogrification
>
> CS> Tadaa, all done. Only requirement is that the new class be no larger
> CS> than the old one -- same as C. :-)
>
> Unfortunatelly this is
> 1. Not feature of C++ but feature of GNU C++ (i.e.: non-portable; still most
> implementation will work Ok here).

You are mistaken, again. This is 100% ANSI C++. I wrote it with the
ANSI standard open in another window.

> 2. Since target could change value after such "change nature of your class"
> so it's not exactly change nature of your class -- more like optimization
> of new/delete call.

It is _exactly_ changing the nature of an object (not a class, but I
think that's just a typo on your part). Consider that we may choose
to define a constructor for Derived2 that omits the initialization of
member variables, thus inheriting previous values from Derived1.

-- 
Chip Salzenberg      - a.k.a. -      <chip@perlsupport.com>
      "When do you work?"   "Whenever I'm not busy."

- 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/