Slashdot Mirror
Interview With Bjarne Stroustrup
koval writes "artima.com has published an initial portion of interview with Bjarne Stroustrup.
The scope of first part is mostly about improving the style of C++ programming and getting maximum from a language."
Bill Venners: In an interview, you said, "The C++ community has yet to
internalize the facilities offered by standard C++. By reconsidering the style of C++ use,
major improvements in ease of writing, correctness, maintainability, and efficiency can
be obtained." How should C++ programmers reconsider their style of C++ use?
Bjarne Stroustrup: It's always easier to say what not to do, rather than what to
do, so I'll start that way. A lot of people see C++ as C with a few bits and pieces added.
They write code with a lot of arrays and pointers. They tend to use new
the way they used malloc. Basically, the abstraction level is low. Writing
C-style code is one way to get into C++, but it's not using C++ really well.
I think a better way of approaching C++ is to use some of the standard library facilities.
For example, use a vector rather than an array. A vector knows its size. An array does
not. You can extend a vector's size implicitly or explicitly.
To get an array of a different size, you must explicity deal with
memory using realloc, malloc, memcpy, etc.
Also, use inline
functions rather than macros, so you don't get into the macro problems. Use a C++ string
class rather than manipulating C strings directly. And if you've got a lot of casts in the
code, there's something wrong. You have dropped from the level of types, a high level of
abstraction, down to a level of bits and bytes. You shouldn't do that very often.
To get out of writing low level code, you needn't start writing a lot of classes. Instead,
start using facilities provided in libraries. The standard library os the first and most
obvious source, but there are also good libraries for things like math or systems
programming. You don't have to do threading at the C level. You can use a C++
threading library. There are quite a few of them. If you want callbacks, don't use just
plain C functions. Get libc++, and you'll have a proper library that deals with
callbackscallback classes, slots and signals, that kind of stuff. It's available.
It's conceptually closer to what you're thinking about anyway. And you don't have to mess
with error prone details.
Most of these techniques are criticized unfairly for being inefficient. The assumption is
that if it is elegant, if it is higher level, it must be slow. It could be slow in a few cases, so
deal with those few cases at the lower level, but start at a higher level. In some cases, you
simply don't have the overhead. For example, vectors really are as fast as arrays.
The other way people get into trouble is exactly the opposite. They believe that C++
should be an extremely high level language, and everything should be object-oriented.
They believe that you should do everything by creating a class as part of a class hierarchy
with lots of virtual functions. This is the kind of thinking that's reflected in a language
like Java for instance, but a lot of things don't fit into class hierarchies. An integer
shouldn't be part of a class hierarchy. It doesn't need to. It costs you to put it there. And
it's very hard to do elegantly.
You can program with a lot of free-standing classes. If I want a complex number, I write
a complex number. It doesn't have any virtual functions. It's not meant for derivation.
You should use inheritance only when a class hierarchy makes sense from the point of
view of your application, from your requirements. For a lot of graphics classes it makes
perfect sense. The oldest example in the book is the shape example, which I borrowed
from Simula. It makes sense to have a hierarchy of shapes or a hierarchy of windows,
things like that. But for many other things you shouldn't plan for a hierarchy, because
you're not going to need one.
So you can start with much simpler abstractions. Again the standard library can provide
some examples: vector, string, complex number. Don't go to hierarchies until you need
them. Again, one indication that you've gone too far with class hierarchies is you have to
write casts all the time, casting from base classes to derived classes. In really old C++,
you would do it with a C style cast, which is unsafe. In more modern C++, you use a
dynamic cast, which at least is safe. But still better design usually leads you to use casting
only when you get objects in from outside your program. If you get an object through
input, you may not know what it is until a bit later, and then you have to cast it to the
right type.
Bill Venners: What is the cost of going down either of those two paths, being to
low-level or too enamored with object-orientation? What's the problem?
Bjarne Stroustrup: The problem with the C way is that if you write code C-style,
you get C-style problems. You will get buffer overflows. You will get pointer problems.
And you will get hard to maintain code, because you're working at a very low level. So
the cost is in development time and maintenance time.
Going to the big class hierarchy is again, you write more code than you need to, and you
get too much connection between different parts. I particularly dislike classes with a lot
of get and set functions. That is often an indication that it shouldn't have been a class
in the first place. It's just a data structure. And if it really is a data structure,
make it a data structure.