From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2000-05-30 15:58:48
Hi,
This is a very tentative proposal, I want to gauge your interest
about that.
I am writing a book on design with C++ and patterns. The book
basically builds Loki, a library of design elements. The goals in
building Loki are: high-level, broad usability, high portability.
These goals are pursued by using generic programming, design
patterns, and standard C++.
The components that Loki currently has are:
* Typelists - a complete typelist facility that allows you to
manipulate lists of types at compile time the same way you can
manipulate value lists at runtime. Two interesting library template
classes allow you to generate whole hierarchies from typelists.
* Abstract Factory - an Abstract Factory generic interface and two
stock implementations (one using new, the other using the Prototype
design pattern).
* Generalized Functors - forwarding functors with value semantics
that can be bound to functions, other functors, and objects+pointer-
to-member-functions. There is support for up to 15 parameters. The
most interesting features are support for automatic conversions, a
nice binding mechanism, chaining, and extensibility.
* Object Factory - a generic object factory implemented with a map of
tokens and creators. By default creators are pointers to functions.
You can have a generalized functor be a creator, and this gives an
idea on how nicely Loki's elements dovetail together. The tokens can
be integers, strings, you get the idea.
* Visitor - generic implementations of the GoF and Acyclic Visitor
patterns.
* SmartPtr - a smart pointer based on a carefully-chosen set of
policy classes, that is extremely flexible and very behavior-rich.
There are about 160 possible behaviors implemented with a small
codebase, and in particular you can imitate auto_ptr, shared_ptr and
linked_ptr. SmartPtr even supports non-pointer (handle-based)
representations. Because SmartPtr is actually nothing but a syntactic
shell that integrates six policies, I hope that you never have to
develop a smart pointer from scratch; instead, you would write new
policies for SmartPtr.
* Singleton - a generic Singleton implementation.
* Three Double Dispatch engines - brute force, logarithmic, constant
time. They support conversions and to some extent, inheritance.
* TypeTraits - a subset of Boost's type_traits, a very compact
implementation.
* A small object allocator.
* A drop-in replacement for std::map that uses a sorted vector. See
Matt's recent article in the Report. Loki uses it in the object
factory and the double dispatch engine.
* Threading amenities - this is a tough subject, but I couldn't
ignore providing some support.
I underline all implementations are fully generic, that is, unlike
many libraries, Loki doesn't make any assumptions about the design
tradeoffs or the user's environment. Instead, it's the user who
chooses the tradeoffs, and uses Loki with her own types. There are
some pre-canned policies, but the user can easily define new ones.
Loki's style is to make important design components such as object
factories or Visitors as easy to put together as writing a two-lines
typedef. (Also imagine what a boon for maintenance.) My hope is that
Loki democratizes good design.
I wonder if you guys would find Loki suitable for integrating with
Boost. Loki's idioms and programming style ease high-level libraries
construction, and makes you think of putting in libraries elements
that are most often confined to the whiteboard. On the list are
generic implementations of Observer and Composite. I know it sounds
cray to *implement* such open-ended stuff, yet I have some ideas
about these that I think are neat, however deadline issues force me
to forego them for the book.
So, I am curious on what you guys think. A small issue could be
naming conventions (I use Herb Sutter's) and a bigger problem is
documentation - which can raise copyright issues with the publisher.
Another thing is that Loki uses template template parameters in some
essential parts, which makes the effort somehow future-oriented :o).
Thanks.
Andrei