DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Getting Started

How we decided what components to provide

In deciding what general-purpose components to provide, some vendors have provided a set of C++ classes similar to the Smalltalk class hierarchy. The vendors can boast of ``completeness'' to customers who want to program in C++ exactly as they would program in Smalltalk. However, we believe that if C (or C++) programmers wanted to program in Smalltalk, they would already be doing so. Monolithic class hierarchies are more than simply inimical to the ``C style'': we believe that they impose too high an overhead for those applications where C has traditionally been the language of choice.


NOTE:

If you are interested in component design issues like this one, read the following chapter, The Design of C++ Standard Components.


In contrast, our approach to deciding what kind of components to provide has been relatively pragmatic. We started by analyzing the kinds of programming tasks that real C programmers routinely perform, and the kinds of errors that real C programmers make when performing these tasks. Then we designed components to simplify the tasks and eliminate the errors. We designed our components to rival the efficiency of existing C libraries, which offer similar functionality, but in much less convenient form. We did this because we knew that unless they were efficient, many programmers would not use them.

Of course, there are alternate philosophies on how to choose, design and implement C++ foundation class libraries, each with its own strengths and weaknesses. Our purpose here is to explain our goals, how we have tried to meet them, and how Standard Components can help you.


Next topic: Who uses C++ Standard Components?
Previous topic: You provide application-specific components

© 2004 The SCO Group, Inc. All rights reserved.
UnixWare 7 Release 7.1.4 - 27 April 2004