what is an escaping variable

[malc]

Why would you have to drop templates, RAII, references, function and
operator overloading in driver code? Exceptions typically require some
form of run time support, but none of the other language features you
mention do.

Some of that is addressed here:
http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx

 

[brad]

So here is an expert of who believes that you don't need C++ to
program low level. C++ brings extra complexity that is not needed. C
is #1 language to program in lower level. We can also add that you
don't need C++ to program in higher level either, as you can use
easier and better languages such as C#, Java, Ruby on Ralis, Perl,
Python.

I chose to learn C++ because of the options it provides... the
complexity that you refer to. I can do old-fashioned C, OOP, sequential,
functional, etc. I can do char arrays or use strings. I'm proficient in
Python and Ruby and I like them very much, but there are times when I
need native, compiled code for performance and efficiency reasons...
when that happens I normally use C++ in a C like manner. C++ does not
force me into a certain programming paradigm. That's what I like most
about it. I don't think it is a better C, IMO it's C with more
options... use them if you like, but you don't have to... and if you do
not need the additional options, then just stick with C. They are so
similar that it's not really worth arguing about.

Just my 2 cents,

Brad

 

[Erik Wikström]

Use only explicit C++ POD, __NO__ STL, exceptions, constructor, destructors,
virtual functions, inheritance, whatever... Every object is POD; ctor/dtor
is explicit. POD templates would be allowed. You can still benefit from the
syntax of the language - kernel unfriendly features.

Why limit yourself to PODs? Constructors and destructors can be useful
even in a kernel environment (probably the constructors more than the
destructors though). Virtual functions are also useful, in fact they are
used all over modern kernels (but implemented using function-pointers).
Inheritance can also be useful, I've seen some code like this:

struct Base {
uint16_t type;
};

struct Some_thing {
uint16_t type;
// more data
};

And then you cast Some_thing* to Base* and pass them around and use the
type-field to cast them back, you might just as well use inheritance and
make the connection between the classes explicit in the code.

Of course you can not use every feature (I would not use exceptions or
STL and some other stuff) and you have to be smart about those you use,
but I think that most of the new stuff can find a place in a kernel.


PS: Groups other than c.l.c++ removed.

 

[Ian Collins]

Some of that is addressed here:
http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx

For one compiler. I haven't experienced the problems they cite with
embedded compilers, or with my main hosted compiler.

 

[malc]

For one compiler. I haven't experienced the problems they cite with
embedded compilers, or with my main hosted compiler.

Ergo the problems do not exist? That's wishful thinking.

 

[Ian Collins]

Ergo the problems do not exist? That's wishful thinking.

Not if you use the right tool for the job.

 

[peter koch]

Ergo the problems do not exist? That's wishful thinking.

The Microsoft compiler is notoriously bad wrt its exception handling,
which from logical point of view shouldnt need any OS support. The
problem is that MS thought it wise to include operating system
exceptions (such as divide by zero or dereferencing of an invalid
pointer) as a part of the exception handling machinery.
There's no way back from that decision: we will have to 64-bit windows
to repair this. This also means that C++ will be a very poor choice
for 32-bit kernel/OS development unless you cut at least exceptions
out of the game.

/Peter

 

[Mike Schilling]

I chose to learn C++ because of the options it provides... the
complexity that you refer to. I can do old-fashioned C, OOP,
sequential, functional, etc. I can do char arrays or use strings.
I'm
proficient in Python and Ruby and I like them very much, but there
are times when I need native, compiled code for performance and
efficiency reasons... when that happens I normally use C++ in a C
like manner. C++ does not force me into a certain programming
paradigm. That's what I like most about it. I don't think it is a
better C, IMO it's C with more options... use them if you like, but
you don't have to... and if you do not need the additional options,
then just stick with C. They are so similar that it's not really
worth arguing about.

Note that function prototypes, which were a significant hole in C's
strong typing [1], originated with C++.

Hypothetically, if I were going to program in C++-like C, I'd still
use classes to provide data-hiding and encapsulation, but I'd do
without (at least)

* operator overloading
* virtual functions
* virtual base classes
* templates

Am I leaving anything out?

1. This isn't just a theoretical opinion. I used to work on a very
large suite of C applications, and invalid parameter types were a
common source of errors, particularly where they were "close enough"
on the platform we were developing on, but not on some of the ones we
ported to.

 

[dizzy]

Why would you have to drop templates, RAII, references, function and
operator overloading in driver code?

I wouldn't, especially RAII (I still have fantasies of using RAII for scoped
locking, resource management together with some auto_ptr-like move
semantics in the linux kernel code).

Exceptions typically require some
form of run time support, but none of the other language features you
mention do.

I see. I supose it also has to do with code being more explicit with other
exception handling than C++ exceptions (but also bloated, adding noise to
the source, polluting the source with error handling paths).

 

[James Kanze]

As I said, I will find the link again. His knowledge of C++
is just fine.
http://www.builderau.com.au/video/soa/Rusty-s-message-to-C-programmer...
http://www.builderau.com.au/video/soa/Why-C-remains-relevant/0,200006...
So here is an expert of who believes that you don't need C++ to
program low level. C++ brings extra complexity that is not needed.

[...]

You are not forced to use "all" the features of C++. One could
most certainly use C++ in a kernel. However, I personally
would avoid exceptions and global ctor/dtors like the plague.
I also would not use the STL, oh well...

I'm not sure what you mean by "global ctor/dtors". You probably
cannot count on dynamic initialization of variables with static
lifetime, for obvious reasons, but there's certainly no reason
not to use (and a lot of reasons for using) user defined
constructors and destructors on local objects.

FWIW: Chorus was written entirely in C++ (except for the
unavoidable little bits of assembler), and that was almost 20
years ago. (Chorus was later bought by Sun, and most of its
features worked their way into Solaris, so I suspect that large
parts of Solaris are written in C++ today.)

 

[James Kanze]

innews:[email protected]:

I would be interested in the answer to this myself. I know that in real
time systems they don't want the somewhat uncontrolled flurry of activity
that usually accompanies a method exit,

And it's more controlled if you explicitly call named functions,
rather than doing it in a destructor?

however most OS's aren't real time and I wouldn't think that
it would matter in the main.

The two OS's I know that are (or were) written primarily in C++
(Chorus and Symbian) both have significant support for real
time.

 

[Joe Greer]

And it's more controlled if you explicitly call named functions,
rather than doing it in a destructor?

Possibly. You are at least forced to think about it, since you have to
code each cleanup operation where it is going to occur. Hopefully, the
tone of my message conveyed that I thought this was a somewhat weak
argument myself, but it's the only one I had heard against destructors.

joe

 

[James Kanze]

"James Kanze" <[email protected]> wrote in message

news:930a9325-6d39-4c58-be22-d21cd8545e9c@s50g2000hsb.googlegroups.com...

[...]

Yeah, your right. However, I did not use them out of habit
back when I was working on a toy x86 kernel implementation.
Some objects may need to interface with assembly language. I
personally find that using POD makes can make that process a
bit easier...

Interfacing with assembler is another theme. Throw in some
privates and publics, virtual functions and a bit of
inheritance, and figuring out the layout in assembler isn't
going to be trivial. I've never found a compiler where just
adding a constructor or destructor to what would otherwise be a
POD changed the layout in anyway, however. (On the other hand,
whatever reasons made you want a destructor could very well
impact on how you use the class in assembler. Interfacing with
assembler is one place where char[] beats std::string hands
down.)