(ref.doc)Library design using C++

p 14-22
Library design using C++
Some thoughts from the designer
by Bjarne Stroustrup (Note:
 C++ Programming Language)

These language features exist to support more fundamental trade-offs.
Should the design:
- Emphasize runtime efficiency?
- Minimize re-compilation after a change?
- Maximize portability across platforms?
- Enable users to extend the basic library?
- Allow use without source code available?
- Blend in with existing notations and styles?
- Be usable from code not written in C++?
- Be usable by novices?


My main recommendation to library builders and users is simple: Don't
fight the type system.

The basic structure of C++ encourages a strongly typed style of
programming.

To put it more crudely: Don't break the type system with casts.


Consider a library built on the notion of a "universal" base class and
runtime type inquiries. [...] This [...] is perfectly legal C++, but
organized in such a way as to take no advantage of the type system.


The basic rule is as ever: Use static (compile-time checked)
mechanisms wherever possible.


Managing library diversity:
- name clashes
- "universal" base class
- memory management
- initialization and cleanup
- error handling


A library designer must present the user with a clean comprehensible
model of how memory is allocated and deallocated. One such policy is
"whoever created an object must also destroy it". [...] Another policy
is "if you give an object to the library, the library is responsible
for it, if you get an object from the library, you become responsible
for it".



static Lib_counter:
This solution isn't perfectly elegant and can be unpleasantly
expensive in a virtual memory system if this initialization code is
scattered throughout the address space of a process.

References:
6.  Johnson, R.E. The importance of being abstract. C++ Report, 1(3),
    1989

10. Reiser, J.F. Static initializers: reducing the value-aded tax on
    programms. Proceedings of the Usenix C++ Conference. Portland, OR,
    Aug 1992