Reference counting techniques? Nothing new, you might think. Every good + +C++ text that takes you to an intermediate or advanced level will introduce + +the concept. It has been explored with such thoroughness in the past that + +you might be forgiven for thinking that everything that can be said has + +been said. Well, let's start from first principles and see if we can unearth + +something new....
+ +The principle behind reference counting is to keep a running usage count + +of an object so that when it falls to zero we know the object is unused. + +This is normally used to simplify the memory management for dynamically + +allocated objects: keep a count of the number of references held to that + +object and, on zero, delete the object.
+ + + +How to keep a track of the number of users of an object? Well, normal + +pointers are quite dumb, and so an extra level of indirection is required + +to manage the count. This is essentially the PROXY + +pattern described in Design Patterns [Gamma, Helm, Johnson & + +Vlissides, Addison-Wesley, ISBN 0-201-63361-2]. The + +intent is given as
+ + + +Provide a surrogate or placeholder for another object to control + +access to it.
+ +Coplien [Advanced C++ Programming Styles and Idioms, Addison-Wesley, + +ISBN 0-201-56365-7] defines a set of idioms related + +to this essential separation of a handle and a body part. The Taligent + +Guide to Designing Programs [Addison-Wesley, ISBN 0-201-40888-0] + +identifies a number of specific categories for proxies (aka surrogates). + +Broadly speaking they fall into two general categories:
+ + + +For reference counted smart pointers there are two places the count + +can exist, resulting in two different patterns, both outlined in Software + +Patterns [Coplien, SIGS, ISBN 0-884842-50-X]:
+ + + +Even with this simple analysis, it seems that the DETACHED + +COUNTED HANDLE/BODY + +approach is ahead. Indeed, with the increasing use of templates this is + +often the favourite, and is the principle behind the common - but not standard + +- counted_ptr. +[The Boost name is shared_ptr + +rather than counted_ptr.]
+ + + +A common implementation of COUNTED BODY + +is to provide the counting mechanism in a base class that the counted type + +is derived from. Either that, or the reference counting mechanism is provided + +anew for each class that needs it. Both of these approaches are unsatisfactory + +because they are quite closed, coupling a class into a particular framework. + +Added to this the non-cohesiveness of having the count lying dormant in + +a non-counted object, and you get the feeling that excepting its use in + +widespread object models such as COM and CORBA the COUNTED + +BODY approach is perhaps only of use in specialised + +situations.
+ +It is the question of openness that convinced me to revisit the problems + +with the COUNTED BODY idiom. + +Yes, there is a certain degree of intrusion expected when using this idiom, + +but is there anyway to minimise this and decouple the choice of counting + +mechanism from the smart pointer type used?
+ + + +In recent years the most instructive body of code and specification + +for constructing open general purpose components has been the Stepanov + +and Lee's STL (Standard Template Library), now part of the C++ standard + +library. The STL approach makes extensive use of compile time polymorphism + +based on well defined operational requirements for types. For instance, + +each container, contained and iterator type is defined by the operations + +that should be performable on an object of that type, often with annotations + +describing additional constraints. Compile time polymorphism, as its name + +suggests, resolves functions at compile time based on function name and + +argument usage, i.e. overloading. This is less intrusive, although less + +easily diagnosed if incorrect, than runtime poymorphism that is based on + +types, names and function signatures.
+ + + +This requirements based approach can be applied to reference counting. + +The operations we need for a type to be Countable are loosely:
+ + + +Note that the count is deduced as a part of the abstract state of this + +type, and is not mentioned or defined in any other way. The openness of + +this approach derives in part from the use of global functions, meaning + +that no particular member functions are implied; a perfect way to wrap + +up an existing counted body class without modifying the class itself. The + +other aspect to the openness comes from a more precise specification of + +the operations.
+ + + +For a type to be Countable it must satisfy the following requirements, + +where ptr is a non-null pointer to a single + +object (i.e. not an array) of the type, and #function + +indicates number of calls to function(ptr):
+ + + +| Expression | + + + +Return type | + + + +Semantics and notes | + +
| acquire(ptr) | + + + +no requirement | + + + +post: acquired(ptr) | + +
| release(ptr) | + + + +no requirement | + + + +pre: acquired(ptr) + +post: acquired(ptr) == #acquire - + +#release |
+
+
| acquired(ptr) | + + + +convertible to bool | + + + +return: #acquire > #release | + +
| dispose(ptr, ptr) | + + + +no requirement | + + + +pre: !acquired(ptr) + +post: *ptr no longer usable |
+
+
Note that the two arguments to dispose + +are to support selection of the appropriate type safe version of the function + +to be called. In the general case the intent is that the first argument + +determines the type to be deleted, and would typically be templated, while + +the second selects which template to use, e.g. by conforming to a specific + +base class.
+ + + +In addition the following requirements must also be satisfied, where + +null is a null pointer to the Countable + +type:
+ + + +| Expression | + + + +Return type | + + + +Semantics and notes | + +
| acquire(null) | + + + +no requirement | + + + +action: none | + +
| release(null) | + + + +no requirement | + + + +action: none | + +
| acquired(null) | + + + +convertible to bool | + + + +return: false | + +
| dispose(null, null) | + + + +no requirement | + + + +action: none | + +
Note that there are no requirements on these functions in terms of exceptions + +thrown or not thrown, except that if exceptions are thrown the functions + +themselves should be exception safe.
+ +Given the Countable requirements for a type, it is possible to + +define a generic smart pointer type that uses them for reference counting:
+ + + +template<typename countable_type>
+class countable_ptr
+{
+public: // construction and destruction
+
+ explicit countable_ptr(countable_type *);
+ countable_ptr(const countable_ptr &);
+ ~countable_ptr();
+
+public: // access
+
+ countable_type *operator->() const;
+ countable_type &operator*() const;
+ countable_type *get() const;
+
+public: // modification
+
+ countable_ptr &clear();
+ countable_ptr &assign(countable_type *);
+ countable_ptr &assign(const countable_ptr &);
+ countable_ptr &operator=(const countable_ptr &);
+
+private: // representation
+
+ countable_type *body;
+
+};
+
+
+
+
+
+
+The interface to this class has been kept intentionally simple, e.g. + +member templates and throw specs have been + +omitted, for exposition. The majority of the functions are quite simple + +in implementation, relying very much on the assign + +member as a keystone function:
+ + + +template<typename countable_type>
+countable_ptr<countable_type>::countable_ptr(countable_type *initial)
+ : body(initial)
+{
+ acquire(body);
+}
+
+template<typename countable_type>
+countable_ptr<countable_type>::countable_ptr(const countable_ptr &other)
+ : body(other.body)
+{
+ acquire(body);
+}
+
+template<typename countable_type>
+countable_ptr<countable_type>::~countable_ptr()
+{
+ clear();
+}
+
+template<typename countable_type>
+countable_type *countable_ptr<countable_type>::operator->() const
+{
+ return body;
+}
+
+template<typename countable_type>
+countable_type &countable_ptr<countable_type>::operator*() const
+{
+ return *body;
+}
+
+template<typename countable_type>
+countable_type *countable_ptr<countable_type>::get() const
+{
+ return body;
+}
+
+template<typename countable_type>
+countable_ptr<countable_type> &countable_ptr<countable_type>::clear()
+{
+ return assign(0);
+}
+
+template<typename countable_type>
+countable_ptr<countable_type> &countable_ptr<countable_type>::assign(countable_type *rhs)
+{
+ // set to rhs (uses Copy Before Release idiom which is self assignment safe)
+ acquire(rhs);
+ countable_type *old_body = body;
+ body = rhs;
+
+ // tidy up
+ release(old_body);
+ if(!acquired(old_body))
+ {
+ dispose(old_body, old_body);
+ }
+
+ return *this;
+}
+
+template<typename countable_type>
+countable_ptr<countable_type> &countable_ptr<countable_type>::assign(const countable_ptr &rhs)
+{
+ return assign(rhs.body);
+}
+
+template<typename countable_type>
+countable_ptr<countable_type> &countable_ptr<countable_type>::operator=(const countable_ptr &rhs)
+{
+ return assign(rhs);
+}
+
+
+
+
+
+
+
+
+Conformance to the requirements means that a type can be used with countable_ptr. + +Here is an implementation mix-in class (mix-imp) that confers countability + +on its derived classes through member functions. This class can be used + +as a class adaptor:
+ + + +class countability
+{
+public: // manipulation
+
+ void acquire() const;
+ void release() const;
+ size_t acquired() const;
+
+protected: // construction and destruction
+
+ countability();
+ ~countability();
+
+private: // representation
+
+ mutable size_t count;
+
+private: // prevention
+
+ countability(const countability &);
+ countability &operator=(const countability &);
+
+};
+
+
+
+
+
+
+Notice that the manipulation functions are const + +and that the count member itself is mutable. + +This is because countability is not a part of an object's abstract state: + +memory management does not depend on the const-ness + +or otherwise of an object. I won't include the definitions of the member + +functions here as you can probably guess them: increment, decrement and + +return the current count, respectively for the manipulation functions. + +In a multithreaded environment you should ensure that such read and write + +operations are atomic.
+ + + +So how do we make this class Countable? A simple set of forwarding + +functions does the job:
+ + + +void acquire(const countability *ptr)
+{
+ if(ptr)
+ {
+ ptr->acquire();
+ }
+}
+
+void release(const countability *ptr)
+{
+ if(ptr)
+ {
+ ptr->release();
+ }
+}
+
+size_t acquired(const countability *ptr)
+{
+ return ptr ? ptr->acquired() : 0;
+}
+
+template<class countability_derived>
+void dispose(const countability_derived *ptr, const countability *)
+{
+ delete ptr;
+}
+
+
+
+
+
+
+Any type that now derives from countability + +may now be used with countable_ptr:
+ + + +class example : public countability
+{
+ ...
+};
+
+void simple()
+{
+ countable_ptr<example> ptr(new example);
+ countable_ptr<example> qtr(ptr);
+ ptr.clear(); // set ptr to point to null
+} // allocated object deleted when qtr destructs
+
+
+
+
+
+
+
+The challenge is to apply COUNTED BODY + +in a non-intrusive fashion, such that there is no overhead when an object + +is not counted. What we would like to do is confer this capability on a + +per object rather than on a per class basis. Effectively we are after Countability + +on any object, i.e. anything pointed to by a void + +*! It goes without saying that void + +is perhaps the least committed of any type.
+ + + +The forces to resolve on this are quite interesting, to say the least. + +Interesting, but not insurmountable. Given that the class of a runtime + +object cannot change dynamically in any well defined manner, and the layout + +of the object must be fixed, we have to find a new place and time to add + +the counting state. The fact that this must be added only on heap creation + +suggests the following solution:
+ + + +struct countable_new; +extern const countable_new countable; + +void *operator new(size_t, const countable_new &); +void operator delete(void *, const countable_new &);+ + + + +
We have overloaded operator new with a + +dummy argument to distinguish it from the regular global operator + +new. This is comparable to the use of the std::nothrow_t + +type and std::nothrow object in the standard + +library. The placement operator delete is + +there to perform any tidy up in the event of failed construction. Note + +that this is not yet supported on all that many compilers.
+ + + +The result of a new expression using countable + +is an object allocated on the heap that has a header block that holds the + +count, i.e. we have extended the object by prefixing it. We can provide + +a couple of features in an anonymous namespace (not shown) in the implementation + +file for for supporting the count and its access from a raw pointer:
+ + + +struct count
+{
+ size_t value;
+};
+
+count *header(const void *ptr)
+{
+ return const_cast<count *>(static_cast<const count *>(ptr) - 1);
+}
+
+
+
+
+
+
+An important constraint to observe here is the alignment of count + +should be such that it is suitably aligned for any type. For the definition + +shown this will be the case on almost all platforms. However, you may need + +to add a padding member for those that don't, e.g. using an anonymous union + +to coalign count and the most aligned type. + +Unfortunately, there is no portable way of specifying this such that the + +minimum alignment is also observed - this is a common problem when specifying + +your own allocators that do not directly use the results of either new + +or malloc.
+ + + +Again, note that the count is not considered to be a part of the logical + +state of the object, and hence the conversion from const + +to non-const - count + +is in effect a mutable type.
+ + + +The allocator functions themselves are fairly straightforward:
+ + + +void *operator new(size_t size, const countable_new &)
+{
+ count *allocated = static_cast<count *>(::operator new(sizeof(count) + size));
+ *allocated = count(); // initialise the header
+ return allocated + 1; // adjust result to point to the body
+}
+
+void operator delete(void *ptr, const countable_new &)
+{
+ ::operator delete(header(ptr));
+}
+
+
+
+
+
+
+Given a correctly allocated header, we now need the Countable functions + +to operate on const void * to complete the + +picture:
+ + + +void acquire(const void *ptr)
+{
+ if(ptr)
+ {
+ ++header(ptr)->value;
+ }
+}
+
+void release(const void *ptr)
+{
+ if(ptr)
+ {
+ --header(ptr)->value;
+ }
+}
+
+size_t acquired(const void *ptr)
+{
+ return ptr ? header(ptr)->value : 0;
+}
+
+template<typename countable_type>
+void dispose(const countable_type *ptr, const void *)
+{
+ ptr->~countable_type();
+ operator delete(const_cast<countable_type *>(ptr), countable);
+}
+
+
+
+
+
+
+The most complex of these is the dispose + +function that must ensure that the correct type is destructed and also + +that the memory is collected from the correct offset. It uses the value + +and type of first argument to perform this correctly, and the second argument + +merely acts as a strategy selector, i.e. the use of const + +void * distinguishes it from the earlier dispose shown for + +const countability *.
+ + + + + + +Now that we have a way of adding countability at creation for objects + +of any type, what extra is needed to make this work with the countable_ptr + +we defined earlier? Good news: nothing!
+ + + +class example
+{
+ ...
+};
+
+void simple()
+{
+ countable_ptr<example> ptr(new(countable) example);
+ countable_ptr<example> qtr(ptr);
+ ptr.clear(); // set ptr to point to null
+} // allocated object deleted when qtr destructs
+
+
+
+
+
+
+The new(countable) expression defines + +a different policy for allocation and deallocation and, in common with + +other allocators, any attempt to mix your allocation policies, e.g. call + +delete on an object allocated with new(countable), + +results in undefined behaviour. This is similar to what happens when you + +mix new[] with delete + +or malloc with delete. + +The whole point of Countable conformance is that Countable objects + +are used with countable_ptr, and this ensures + +the correct use.
+ + + +However, accidents will happen, and inevitably you may forget to allocate + +using new(countable) and instead use new. + +This error and others can be detected in most cases by extending the code + +shown here to add a check member to the count, + +validating the check on every access. A benefit of ensuring clear separation + +between header and implementation source files means that you can introduce + +a checking version of this allocator without having to recompile your code.
+ + + + + + +There are two key concepts that this article has introduced:
+ + + +The application of the two together gives rise to a new variant of the + +essential COUNTED BODY pattern, + +UNINTRUSIVE COUNTED BODY. + +You can take this theme even further and contrive a simple garbage collection + +system for C++.
+ + + +The complete code for countable_ptr, countability, + +and the countable new is also available.
+ ++ +
|
+ Home | +Libraries | +People | +FAQ | +More | +
How is a library accepted for posting on the site? An initial review by the +library master filters out libraries which do not meet the absolute requirements (must be +C++, ownership clear, reasonable format, etc.) The author is free to rework and +resubmit libraries which do not pass initial muster. This is encouraged, particularly when +reviewers like the idea behind a library but feel that details are lacking.
+ +Is there any assurance libraries actually work as claimed? No. The review +process will hopefully eliminate the most seriously flawed libraries, but a well +constructed library with hidden defects is likely to slip through. Encouraging ordinary +users to report their experience with a library is intended to address such concerns.
+ +How does someone submit a comment? Send email to boost@egroups.com.
+ +How does someone submit a library? See Library +Guidelines
+ +Are commercial libraries requiring a fee acceptable? No. However, a library that +a commercial enterprise makes available without fee is acceptable. If the description of +the library makes a low-key plug for the supplier, that is acceptable as long as the +library delivers real value and isn’t just a Trojan horse for the plug.
+ +Are shareware libraries acceptable? No. At least initially, only free libraries +will be accepted.
+ +Are open source license libraries acceptable? No, not currently.
+Open source licenses often require redistribution or availability of source code,
+inclusion of license document with machine-executable redistribution, give the initial
+developer rights to licensee modifications, and need a lawyer to understand. These
+would be immediate disqualifications for many business, commercial, and consumer
+applications. Boost aims to avoid subjecting users to hard-to-comply-with license terms.
+
+This is subject to review for a particularly important piece of software, or as the
+industry changes.
Must full source code be provided? Yes, these are source code libraries.
+ +What about documentation? A very simple library might be accepted with only a +well commented header file. For more substantial libraries, some form of documentation is +certainly going to be expected. HTML is the preferred form.
+ +Are platform specific libraries acceptable? There is a preference for portable +libraries. Libraries will be accepted that have portable interfaces but require platform +specific implementations, as long as the author supplies implementations for a couple of +disparate major operating systems.
+ +Must a library do useful work? No. A library meant as a teaching example or +demonstration might not actually do any work.
+ +Who owns the libraries? Presumably many authors will copyright their libraries. +Others authors may wish to place their libraries in the public domain. The Boost.org +policy is to only accept libraries with a clear copyright notice. It is up to +potential users to decide if they find the copyright terms acceptable, and to not use +libraries with unacceptable copyrights.
+ +What support is available for the libraries? Try the boost@egroups.com mailing list.
+ +Is there a relationship between Boost.org and the C++ Standards Committee? + No. The people who started Boost.org were all on the committee, but that was just +happenstance.
+ +Will the Boost.org libraries become part of the next C++ Standard? Some +might, someday off in the future, but that is up to the standards committee. To the +extent a library becomes "existing practice", the likelihood increases that +someone will propose it for future standardization. Submitting a library to Boost.org is +one way to establish existing practice - as long as enough people are interested to +download and use it!
+ +Is the site a commercial business? No. It is just some people getting together +as a kind of cyberspace civic association. If it ever needs to incorporate, it would be as +non-profit organization.
+ +Is there any charge for submitting libraries or reviews to Boost.org? No. Unlike +the standards committees, you don’t have to pay to volunteer!
+ +Will the site include material beyond libraries? The main focus is on libraries, +but if people contribute occasional articles or other material to make the site more +interesting, that could be a nice fit.
+ +How do I unzip the distribution files on my [whatever] computer? + The .zip format is used for distribution because there are free decoders and +encoders available for many, many different platforms. See the Info-ZIP web site, which includes a FAQ and +much other useful information about the .zip format. Many commercial compressor-archiver +utilities also support this format.
+ +-- End of FAQ --
+ +Revised May 17, 1999
+ + diff --git a/more/feature_model_diagrams.htm b/more/feature_model_diagrams.htm new file mode 100644 index 0000000000..40e807be3b --- /dev/null +++ b/more/feature_model_diagrams.htm @@ -0,0 +1,103 @@ + + + + + + +By Beman Dawes
+In their seminal book, Generative Programming, Czarnecki and Eisenecker (C&E) +describe how to build feature models [C&E 4.4] consisting of a feature +diagram plus semantic, rationale, and other attributes. Feature models are +then used to drive design cycles which eventually lead to manual or automatic +assembly of configurations.
+Feature models provide a language to describe the library variability that is +often such an issue in boost.org discussions. The Whorf hypothesis that +"Language shapes the way we think, and determines what we can think +about" seems to apply. In discussion of library variability issues, +we have been crippled by lack of a good language. With feature models we now +have a language to carry on the dialog.
+The graphical feature diagrams presented by C&E are not in a suitable +form for the email discussions boost.org depends upon. The hierarchical nature +of feature diagrams can be represented by a simple text-based feature diagram +language. A feature model can also take advantage of the hyperlinks +inherent in HTML.
+The grammar for the feature diagram language is expressed in Extended +Bakus-Naur Form; ::= represents productions, [...] represents options, {...} +represents zero or more instances, and represents | alternatives.
+++feature-model ::= concept-name details { feature }+feature ::= feature-name [details]+details ::= "(" feature-list ")" // required features + | "[" feature-list "]" // optional features+feature-list ::= element { "|" element } // one only + | element { "+" element } // one or more + | element { "," element } // all + // [a+b] equivalent to [a,b]+element ::= feature + | details+concept-name ::= name+feature-name ::= name+
The usual lexical conventions apply. Names are case-insensitive and consist +of a leading letter, followed by letters, digits, underscores or hyphens, with +no spaces allowed.
+At least one instance of each name should be hyperlinked to the corresponding +Feature Description.
+While the grammar is intended for written communication between people, it +may also be trivially machine parsed for use by automatic tools.
+Descriptive information is associated with each concept or feature. According +to [C&E 4.4.2] this includes:
+A feature [C&E 4.9.1] is "anything users or client programs might +want to control about a concept. Thus, during feature modeling, we +document no only functional features ... but also implementation features, ..., +various optimizations, alternative implementation techniques, and so on."
+++special-container ( organization, + performance, + interface ) // all required+organization [ ordered + indexed ] // zero or more (4 configurations)+indexed [ hash-function ] // zero or one (2 configurations)+performance ( fast | small | balanced ) // exactly one (3 configurations)+interface ( STL-style + cursor-style ) // one or more (3 configurations)+
There should be feature descriptions for some-container, organization,
+ordered, indexed, hash-function, performance, fast, small, balanced, interface,
+STL-style, and cursor-style.
The number of possible configurations is (2 + 2*2) * 3 * 3 = 54, +assuming no constraints.
+There are equivalent representations. For example:
+++special-container ( organization[ ordered+indexed[ hash-function ]], + performance( fast|small|balanced ), + interface( STL-style+cursor-style ) )+
Krzysztof Czarnecki and Ulrich W. Eisenecker, Generative +Programming, Addison-Wesley, 2000, ISBN 0-210-30977-7
+Revised 23 July 2000
+© Copyright Beman Dawes, 2000
+ + + + diff --git a/more/formal_review_process.htm b/more/formal_review_process.htm new file mode 100644 index 0000000000..a552056649 --- /dev/null +++ b/more/formal_review_process.htm @@ -0,0 +1,94 @@ + + + + + + + |
+ Home | +Libraries | +People | +FAQ | +More | +
The Formal Review process determines if a proposed library should be accepted +as a Boost library.
+The final "accept" or "reject" decision is made by the +Review Manager, based on review comments received from boost mailing list +members.
+Members only can see Formal +Review Schedule for the current review schedule.
+All Boost mailing list members are encouraged to submit Formal Review +comments:
++++
+- Publicly on the mailing list.
+- Privately to the Review Manager. (See Formal Review Status page )
+- Privately to the library submitter.
+
Private comments to a library submitter may be helpful to her or him, but +won't help the Review Manager reach a decision, so the other forms are +preferred.
+Comments may be brief or lengthy, but basically the Review Manager needs your +answers to several questions. If you identify problems along the way, +please note if they are minor, serious, or showstoppers.
+At the conclusion of the comment period, the Review Manager will post a +message to the mailing list saying if the library has been accepted or +rejected. A rationale should be provided, but its extent is up to the +Review Manager.
+Consider writing a Review page for posting on the web site.
+In Review pages or mailing list postings, do quote review comments if you +wish, but don't identify authors of private comments.
+A proposed library should remain stable during the review period; it is just +going to confuse and irritate reviewers if there are numerous changes. It +is, however, useful to upload fixes for serious bugs right away, particularly +those which prevent reviewers from fully evaluating the library. Post a +notice of such fixes on the mailing list.
+Library improvements suggested by reviewers should be held until after the +completion of review period. Such changes can then be incorporated in the final +submission file sent to the webmaster for posting. If the suggested +changes might affect reviewer's judgments, post a notice of the pending +change on the mailing list.
+Revised 13 June, 2000
++ + + + diff --git a/more/header.htm b/more/header.htm new file mode 100644 index 0000000000..5d65137bd0 --- /dev/null +++ b/more/header.htm @@ -0,0 +1,102 @@ + + + + +
|
+ Home | +Libraries | +People | +FAQ | +More | +
Header files are the place where a library comes into contact with user code +and other libraries. To co-exist peacefully and productively, headers must +be "good neighbors".
+Here are the standards for namespace boost headers. Many of +these are also reasonable guidelines for general use. +
// Boost general library furball.hpp header file ---------------------------//
+
+// (C) Copyright Your Name 1998. Permission to copy, use, modify, sell and
+// distribute this software is granted provided this copyright notice appears
+// in all copies. This software is provided "as is" without express or implied
+// warranty, and with no claim as to its suitability for any purpose.
+
+// $Id$ or other version information
+
+#ifndef BOOST_FURBALL_HPP
+#define BOOST_FURBALL_HPP
+
+namespace boost {
+
+// Furball class declaration -----------------------------------------------//
+
+ class furball
+ {
+ public:
+ void throw_up();
+ private:
+ int whatever;
+ }; // furball
+
+} // namespace
+
+#endif // BOOST_FURBALL_HPP
+The alert reader will have noticed that the sample +header employs a certain coding style for indentation, positioning braces, +commenting ending braces, and similar formatting issues. These stylistic +issues are viewed as personal preferences and are not part of the Boost Header +Policy.
+Revised 23 June, 2000
+ + + + diff --git a/more/imp_vars.htm b/more/imp_vars.htm new file mode 100644 index 0000000000..9d1a191135 --- /dev/null +++ b/more/imp_vars.htm @@ -0,0 +1,201 @@ + + + + + + + |
+ Home | +Libraries | +People | +FAQ | +More | +
The interface specifications for boost.org library components (as well as for +quality software in general) are conceptually separate from implementations of +those interfaces. This may not be obvious, particularly when a component is +implemented entirely within a header, but this separation of interface and +implementation is always assumed. From the perspective of those concerned with +software design, portability, and standardization, the interface is what is +important, while the implementation is just a detail.
+Dietmar Kühl, one of the original boost.org contributors, comments "The +main contribution is the interface, which is augmented with an implementation, +proving that it is possible to implement the corresponding class and providing a +free implementation."
+ +There may be a need for multiple implementations of an interface, to +accommodate either platform dependencies or performance tradeoffs. Examples of +platform dependencies include compiler shortcomings, file systems, thread +mechanisms, and graphical user interfaces. The classic example of a performance +tradeoff is a fast implementation which uses a lot of memory versus a slower +implementation which uses less memory.
+Boost libraries generally use a configuration +header, boost/config.hpp, to capture compiler and platform +dependencies. Although the use of boost/config.hpp is not required, it is +the preferred approach for simple configuration problems.
+The Boost policy is to avoid platform dependent variations in interface +specifications, but supply implementations which are usable over a wide range of +platforms and applications. That means boost libraries will use the +techniques below described as appropriate for dealing with platform +dependencies.
+The Boost policy toward implementation variations designed to enhance +performance is to avoid them unless the benefits greatly exceed the full +costs. The term "full costs" is intended to include both +tangible costs like extra maintenance, and intangible cost like increased +difficulty in user understanding.
+ +Several techniques may be used to provide implementation variations. Each is +appropriate in some situations, and not appropriate in other situations.
+The first technique is to simply not provide implementation variation at +all. Instead, provide a single general purpose implementation, and forgo +the increased complexity implied by all other techniques.
+Appropriate: When it is possible to write a single portable +implementation which has reasonable performance across a wide range of +platforms. Particularly appropriate when alternative implementations differ only +in esoteric ways.
+Not appropriate: When implementation requires platform specific +features, or when there are multiple implementation possible with widely +differing performance characteristics.
+Beman Dawes comments "In design discussions some implementation is often +alleged to be much faster than another, yet a timing test discovers no +significant difference. The lesson is that while algorithmic differences may +affect speed dramatically, coding differences such as changing a class from +virtual to non-virtual members or removing a level of indirection are unlikely +to make any measurable difference unless deep in an inner loop. And even in an +inner loop, modern CPU’s often execute such competing code sequences in the +same number of clock cycles! A single general purpose implementation is +often just fine."
+Or as Donald Knuth said, "Premature optimization is the root of all +evil." (Computing Surveys, vol 6, #4, p 268).
+While the evils of macros are well known, there remain a few cases where +macros are the preferred solution:
++++
+- Preventing multiple inclusion of headers via #include guards.
+- Passing minor configuration information from a configuration + header to other files.
+
Appropriate: For small compile-time variations which would +otherwise be costly or confusing to install, use, or maintain. More appropriate +to communicate within and between library components than to communicate with +library users.
+Not appropriate: If other techniques will do.
+To minimize the negative aspects of macros:
++++
+- Only use macros when they are clearly superior to other + techniques. They should be viewed as a last resort.
+- Names should be all uppercase, and begin with the namespace name. This + will minimize the chance of name collisions. For example, the #include + guard for a boost header called foobar.h might be named BOOST_FOOBAR_H.
+
A library component can have multiple variations, each contained in its own +separate file or files. The files for the most appropriate variation are +copied to the appropriate include or implementation directories at installation +time.
+The way to provide this approach in boost libraries is to include specialized +implementations as separate files in separate sub-directories in the .ZIP +distribution file. For example, the structure within the .ZIP distribution file +for a library named foobar which has both default and specialized variations +might look something like:
+++foobar.h // The default header file +foobar.cpp // The default implementation file +readme.txt // Readme explains when to use which files +self_contained/foobar.h // A variation with everything in the header +linux/foobar.cpp // Implementation file to replace the default +win32/foobar.h // Header file to replace the default +win32/foobar.cpp // Implementation file to replace the default+
Appropriate: When different platforms require different +implementations, or when there are major performance differences between +possible implementations.
+Not appropriate: When it makes sense to use more that one of the +variations in the same installation.
+Rather than have several implementation variations of a single component,
+supply several separate components. For example, the Boost library currently
+supplies scoped_ptr and shared_ptr classes rather than
+a single smart_ptr class parameterized to distinguish between the
+two cases. There are several ways to make the component choice:
+++
+- Hardwired by the programmer during coding.
+- Chosen by programmer written runtime logic (trading off some extra + space, time, and program complexity for the ability to select the + implementation at run-time.)
+
Appropriate: When the interfaces for the variations diverge, and when +it is reasonably to use more than one of the variations. When run-time selection +of implementation is called for.
+Not appropriate: When the variations are data type, traits, or +specialization variations which can be better handled by making the component a +template. Also not appropriate when choice of variation is best done by some +setup or installation mechanism outside of the program itself. Thus +usually not appropriate to cope with platform differences.
+Note: There is a related technique where the interface is specified as +an abstract (pure virtual) base class (or an interface definition language), and +the implementation choice is passed off to some third-party, such as a +dynamic-link library or object-request broker. While that is a powerful +technique, it is way beyond the scope of this discussion.
+Turning a class or function into a template is often an elegant way to cope +with variations. Template-based approaches provide optimal space and time +efficiency in return for constraining the implementation selection to compile +time.
+Important template techniques include:
++++
+- Data type parameterization. This allows a single component to + operate on a variety of data types, and is why templates were originally + invented.
+- Traits parameterization. If parameterization is complex, bundling + up aspects into a single traits helper class can allow great variation + while hiding messy details. The C++ Standard Library provides + several examples of this idiom, such as
+iterator_traits<>+ (24.3.1 lib.iterator.traits) and char_traits<> (21.2 + lib.char.traits).- Specialization. A template parameter can be used purely for the + purpose of selecting a specialization. For example:
+++++SomeClass<fast> my_fast_object; // fast and small are empty classes +SomeClass<small> my_small_object; // used just to select specialization+
Appropriate: When the need for variation is due to data type or +traits, or is performance related like selecting among several algorithms, and +when a program might reasonably use more than one of the variations.
+Not appropriate: When the interfaces for variations are +different, or when choice of variation is best done by some mechanism outside of +the program itself. Thus usually not appropriate to cope with platform +differences.
+Revised 23 June, 2000
+ + + + diff --git a/more/index.htm b/more/index.htm new file mode 100644 index 0000000000..1c97f2d736 --- /dev/null +++ b/more/index.htm @@ -0,0 +1,62 @@ + + + + + + + |
+ Home | +Libraries | +People | +FAQ | +More | +
These policies explain what is expected of boost libraries and the process +for library submissions.
+++Library Requirements and Guidelines. + Basic standards for those preparing a submission.
+Library Submission Process. + How to submit a library to Boost.
+Library Formal Review Process. + Including how to submit a review comment.
+Header Policy. Headers are where a + library contacts its users, so programming practices are particularly + important.
+Implementation Variations. + Sometimes one size fits all, sometimes it doesn't. This page deals with + the trade-offs.
+
++The C++ Standard (ISO/IEC 14882) is available online as a PDF file from the + ANSI (American National Standards Institute) + Electronic Standards Store. The price is $US 18.00. The document is + certainly not a tutorial, but is interesting to those who care about the + precise specification of the language and the standard library.
+
++Counted Body Techniques by Kevlin + Henney is must reading for those interested in reference counting, a + widely used object management idiom. Originally published in Overload + magazine.
+Feature Model Diagrams in text and + HTML describes how to represent feature model diagrams in text form.
+
Revised 16 July, 2000
+ + + + diff --git a/more/lib_guide.htm b/more/lib_guide.htm new file mode 100644 index 0000000000..260ea55f25 --- /dev/null +++ b/more/lib_guide.htm @@ -0,0 +1,268 @@ + + + + + |
+ Home | +Libraries | +People | +FAQ | +More | +
This page describes requirements and guidelines for the content +of a library submitted to Boost.
+See the Boost Library +Submission Process page for a description of the process involved.
+To avoid the frustration and wasted time of a proposed library being +rejected, it must meets these requirements:
+There's no requirement that an author read the mailing list for a time before +making a submission. It has been noted, however, that submissions which begin +"I just started to read this mailing list ..." seem to fail, often +embarrassingly.
+A library's interface must portable and not restricted to a
+ particular compiler or operating system.
+
A library's implementation must if possible be portable and
+ not restricted to a particular compiler or operating system. If a
+ portable implementation is not possible, non-portable constructions are
+ acceptable if reasonably easy to port to other environments.
+
There is no requirement that a library run on all C++
+ compilers.
+
There is no requirement that a library run on any particular + C++ compiler. Boost contributors often try to ensure their libraries + work with popular compilers. The boost/config.hpp configuration + header is the preferred mechanism for working around compiler + deficiencies.
Since there is no absolute way to prove portability, many boost +submissions demonstrate practical portability by compiling and executing +correctly with two different C++ compilers, often under different operating +systems. Otherwise reviewers may disbelieve that porting is in fact +practical.
+Are you sure you own the library you are thinking of +submitting? "How to Copyright Software" by MJ Salone, Nolo +Press, 1990 says:
+++Doing work on your own time that is very similar to + programming you do for your employer on company time can raise nasty legal + problems. In this situation, it's best to get a written release from + your employer in advance.
+
Place a copyright notice in all the important files you submit. +Boost.org won't accept libraries without clear copyright information.
+Please use these guidelines as a checklist for preparing the +content a library submission. Not every guideline applies to every +library, but a reasonable effort to comply is expected.
+Even the simplest library needs some documentation; the amount should be +proportional to the need. The documentation should assume the readers have +a basic knowledge of C++, but are not necessarily experts.
+The format for documentation should be HTML, and should not require an +advanced browser or server-side extensions.
+There is no single right way to do documentation. HTML documentation is often +organized quite differently from traditional printed documents. Task-oriented +styles differ from reference oriented styles. In the end, it comes down to the +question: Is the documentation sufficient for the mythical "average" +C++ programmer to use the library successfully?
+Appropriate topics for documentation often include: +
Rationale for some of the requirements and guidelines follows.
+Exception specifications [ISO 15.4] are sometimes coded to indicate what +exceptions may be thrown, or because the programmer hopes they will improved +performance. But consider the follow member from a smart pointer:
+ T& operator*() const throw() { return *ptr; }
+This function calls no other functions; it only manipulates fundamental data +types like pointers Therefore, no runtime behavior of the +exception-specification can ever be invoked. The function is completely +exposed to the compiler; indeed it is declared inline Therefore, a smart +compiler can easily deduce that the functions are incapable of throwing +exceptions, and make the same optimizations it would have made based on the +empty exception-specification. A "dumb" compiler, however, may make +all kinds of pessimizations.
+For example, some compilers turn off inlining if there is an +exception-specification. Some compilers add try/catch blocks. Such +pessimizations can be a performance disaster which makes the code unusable in +practical applications.
+Although initially appealing, an exception-specification tends to have +consequences that require very careful thought to understand. The biggest +problem with exception-specifications is that programmers use them as though +they have the effect the programmer would like, instead of the effect they +actually have.
+A non-inline function is the one place a "throws nothing" +exception-specification may have some benefit with some compilers.
+The C++ standard committee's Library Working Group discussed this issue in +detail, and over a long period of time. The discussion was repeated again in +early boost postings. A short summary:
+Dave Abrahams comments: An important purpose (I daresay the primary purpose) +of source code is communication: the documentation of intent. This is a doubly +important goal for boost, I think. Using a fixed-width font allows us to +communicate with more people, in more ways (diagrams are possible) right there +in the source. Code written for fixed-width fonts using spaces will read +reasonably well when viewed with a variable-width font, and as far as I can tell +every editor supporting variable-width fonts also supports fixed width. I don't +think the converse is true.
+Rationale is defined as "The fundamental reasons for something; +basis." by the American Heritage Dictionary.
+Beman Dawes comments: Failure to supply contemporaneous rationale for +design decisions is a major defect in many software projects. Lack of accurate +rationale causes issues to revisited endlessly, causes maintenance bugs when a +maintainer changes something without realizing it was done a certain way for +some purpose, and shortens the useful lifetime of software.
+Rationale is fairly easy to provide at the time decisions are made, but very +hard to accurately recover even a short time later.
+As a library matures, it almost always accumulates improvements suggested to +the authors by other boost members. It is a part of the culture of +boost.org to acknowledge such contributions, identifying the person making the +suggestion. Major contributions are usually acknowledged in the +documentation, while minor fixes are often mentioned in comments within the code +itself.
+Revised 24 July, 2000
+ + + + diff --git a/more/submission_process.htm b/more/submission_process.htm new file mode 100644 index 0000000000..63d722b23d --- /dev/null +++ b/more/submission_process.htm @@ -0,0 +1,169 @@ + + + + + + + |
+ Home | +Libraries | +People | +FAQ | +More | +
This page describes the process of getting a library accepted by Boost. +The process is still evolving, so if you have suggestions for improvement by all +means post them on the mailing list.
+See the Boost Library Requirements and Guidelines +page for issues of content.
+Subscribe to the mailing list for a +while, or look through the archives. +Click around the web site. Understand the Requirements. +Read the rest of this page to learn about the process. Otherwise, you will +just end up wasting everyone's time.
+There is a culture associated with Boost, aimed at encouraging high quality +libraries by a process of discussion and refinement.
+If what you really want is a site that will just post your library without +even looking at it, you should go elsewhere.
+Potential library submitters should use the mailing +list as a forum to gauge interest a possible submission.
+A message might be as simple as "Is there any interest in a library +which solves Traveling Salesperson problems in linear time?"
+A bit of further description or snippet of code may be helpful. Messages +should be plain text; not rich text, HTML, etc.
+Please don't post lengthy descriptions, documentation, or code to the mailing +list, and no attachments, even small ones. Please post lengthy material in +the eGroups boost Files section +(formerly called the " vault").
+If response to an initial query indicates interest, then post preliminary +files in the Files section of +the boost eGroups web site if you haven't already done so.
+Discuss, refine, resubmit. Repeat until satisfied.
+The exact details of this process varies a lot. Sometimes it is public, +on the mailing list, sometimes a lot of discussion happens in private +emails. For some libraries the process is over quickly, for others it goes +on for months. It's often challenging, and sometimes leads off in +completely unexpected directions.
+The archive of past +messages is one way to see how this process worked for other boost +libraries.
+[The Formal Review procedure is new as of 9 May, 2000, and will be refined +as experience dictates.]
+Once a library author feels a submission (which presumably is now in the +files/vault) has matured enough for formal review, the author sends a message +requesting a formal review to the mailing list. Please use a subject in +the form "Review Request: library" where library is replaced by +the library name.
+Reviews are scheduled so that:
+Before a library can be scheduled for review, an active boost member not +connected with the library submission must volunteer to be the "Review +Manager" for that library. The review manager decides on the schedule, +posts a notice when the review period starts, how long it lasts, and how boost +members can contribute their comments. The review manager collects comments, +chairs any discussions, and then when the review period is over, decides if +there is enough consensus to accept the library.
+See Formal Review Process for +details.
+Members only can see Formal +Review Schedule for the current library review schedule.
+[The plan is that the first several reviews will be managed by long-time +boost contributors who will be encouraged to experiment with the review +process. Presumably, successful processes will evolve over time and +can then be documented.]
+All of the files which make up the library should be combined and compressed +into a single final submission file using the .zip format. Free encoders +and decoders for this format running on many different platforms are available +at the Info-ZIP web site, which +includes a FAQ and much other useful information about the .zip format. Many +commercial compressor-archiver utilities also support this format.
+The final submission file contains the material that will live on the +boost.org web site. The closer the submission file mirrors the directory +structure and format of the web site, the easier it is for the webmaster to +integrate it into the web site. +
The submission file for a library named foo should include these +subdirectories, with the contents indicated: +
++libs/foo +
+
+- An introductory page named index.html or index.htm which looks like the + initial page of other libraries. Rational + is a model for single part libraries, Integer + or Utility are models for + multi-part libraries.
+- The documentation page or pages, also in HTML format.
+- Source files implementing the library if it isn't entirely header + based. The boost file type convention for source files is .cpp.
+- Test programs and data files if supplied.
+- If the library has a large number of subsidiary files which aren't + linked to from the documentation pages, these subsidiary files can be + combined into a single .zip file.
+boost
++
+- Public header files as described in the documentation for the + library. The boost file type convention for header files is .hpp.
+boost/detail
++
+- Implementation header files not normally accessed by library users.
+
Submit via email to webmaster@boost.org. +Attach the .zip submission file. In the email message, please include your +email address, postal mail address, and telephone number, if boost.org doesn't +already have them. Your addresses and phone number will not appear on the web +site (unless you include them in your biography). Anonymous postings are +not accepted.
+If the boost.org web site doesn't already have your capsule biography +and picture (optional, with not-too-serious pictures preferred), please +send them mailto:webmaster@boost.org. It is +up to you as to whether or not the biography includes your email address or +other contact information. The preferred picture format is .jpg, but other +common formats are acceptable. The preferred image size is 500x375 but the +webmaster has photo editing software and can do the image preparation if +necessary.
+Libraries are software; they loose their value over time if not +maintained. Details still hazy.
+Revised 19 June, 2000
+ + + + diff --git a/more/use_other_libs.htm b/more/use_other_libs.htm new file mode 100644 index 0000000000..2aecadebb5 --- /dev/null +++ b/more/use_other_libs.htm @@ -0,0 +1,52 @@ + + + + + + + +(Details)
+The benefits of using components from other libraries include clearer, more +understandable, code, reduced development and maintenance costs, and the +assurance which comes from using well-known and trusted building blocks.
+The costs incurred may include added compilation and runtime costs, and +undesirable coupling between components. If the interface to the +additional component is complex, using it may make code less readable, and thus +actually increase development and maintenance costs.
+Example where another boost component should be used: +boost::noncopyable (in boost/utility.hpp) has considerable benefits; it +simplifies code, improves readability, and signals intent. Costs are low +as coupling is limited; it uses no other classes and includes only the +generally lightweight headers <boost/config.hpp> and <cstddef>. +There are no runtime costs at all. With costs so low and benefits so high, other +boost libraries should use boost::noncopyable except in exceptional +circumstances.
+Example where a standard library component might be used: Providing +diagnostic output as a debugging aid can be a nice feature for a library. Yet +using Standard Library iostreams for the purpose involves a lot of additional +coupling, if iostreams is otherwise unused, and may be a complete waste if the +library is used in a GUI or embedded application. It might be better to +redesign the boost library so that the user supplies the output mechanism, +avoiding marginal use of iostreams.
+Example where another boost component should not be used: The +boost dir_it library has considerable coupling and runtime costs, not to mention +portability issues with unsupported operating systems. While completely +appropriate when directory iteration is required, it would not be reasonable for +another boost library to use dir_it just to check that a file is available +before opening, since Standard Library file open functionality does this at +lower cost. Don't use dir_it just for the sake of using a boost library.
++
+ + + + diff --git a/people/aleksey_gurtovoy.htm b/people/aleksey_gurtovoy.htm new file mode 100644 index 0000000000..fa31707cbb --- /dev/null +++ b/people/aleksey_gurtovoy.htm @@ -0,0 +1,50 @@ + + + + + + +
|
+ Home | +Libraries | +People | +FAQ | +More | +
Aleksey Gurtovoy is just a one Russian guy from Siberia, who now lives and +works in the United States. He is a technical lead in a small software company MetaCommunications, +a job and people which have taught him so much.
+He was born in early 1977, has been in love with computers since 1989, and +still has a lot of (exciting) ideas for his "spare time" in the next +few years. The first computer he worked with was DEC PDP-11, and he still has a +kind of nostalgia about this amazing machine. He graduated with honors from +Krasnoyarsk Technical State University in 1998 with a Master Degree in Computer +Science.
+While being acknowledged as a talented programmer, Aleksey tries to be a +better engineer than he is now and hopes that reading good books will help him +with that task. He reads a lot... One of his favorite books about his profession +is 'The Mythical Man-Month' by Frederic P. Brooks, Jr.
+He has been working with C++ since 1993, he loves the language and wants to +be involved in its progress. Sometimes you can come across his articles in the comp.lang.c++.moderated +and comp.std.c++ newsgroups. The other +numerous things Aleksey is interested in include patterns, object-oriented +methodology and programming languages, organization of software development +process and tools & technologies which make programmer's life easier (e.g. +compilers).
+He is not married, but he has in mind one great girl he hopes to be with +someday.
+You can contact him by sending mail to alexy@meta-comm.com.
+ + + + + diff --git a/people/beman_dawes.html b/people/beman_dawes.html new file mode 100644 index 0000000000..2a4113990e --- /dev/null +++ b/people/beman_dawes.html @@ -0,0 +1,36 @@ + + + + + + |
+ Home | +Libraries | +People | +FAQ | +More | +
+Beman Dawes is a software developer from Virginia in the United States.
He is the author of the StreetQuick® geographic atlas library used by +digital map publishers to help people get really, really, lost.
+He wrote his first computer program 40 years ago, and does not mourn the +passing of bi-quinary +arithmetic.
+Beman has been a voting member of the ANSI/ISO C++ Standards Committee since +1992, and chaired the Library Working Group for five years.
+He enjoys travel, sailing, hiking, and biking. He is married, and he and his +wife have three cats.
+Email: beman@esva.net
+ + + + diff --git a/people/darin_adler.htm b/people/darin_adler.htm new file mode 100644 index 0000000000..176b05fe51 --- /dev/null +++ b/people/darin_adler.htm @@ -0,0 +1,48 @@ + + + + + + + |
+ Home | +Libraries | +People | +FAQ | +More | +
Darin Adler has been programming computers since 1976. He loves to do it.
His first major professional experience was at Apple +Computer. In 1988 he led the team that rewrote the Macintosh Finder in C++. +Before that project was completed, he was shanghaied to be the technical lead +for the System 7 project (these days they would call it "Mac OS 7"). +The group he formed to help him do that, the Blue Meanies, is still a legend +in the Apple community.
+Since Apple, Darin has worked at General +Magic as an architect of the Magic +Cap OS, used the moniker Bent Spoon Software +to do consulting, and helped start Eazel, a +company that is working to make Linux easier to use. Since 1997, he has worked +from his home in Los Angeles, CA, collaborating with clients and coworkers in +other locations.
+He prefers to use and program Macintosh computers with C++. But Eazel's +mission to make Linux easier to use is best accomplished with a non-Macintosh +PC. (That is why Darin is sitting in front of two computers.) +The other people working on the GNOME project +don't like C++, so he's writing a lot of C code these days.
+The larger version of his picture shows him hard at +work with his C++ guru, his daughter Sophia.
+He has hobbies and stuff but you don't want to read about that here.
+You can contact him by sending mail to darin@bentspoon.com.
+ + + + diff --git a/people/dave_abrahams.htm b/people/dave_abrahams.htm new file mode 100644 index 0000000000..48881bbe3d --- /dev/null +++ b/people/dave_abrahams.htm @@ -0,0 +1,29 @@ + + + + + + + |
+ Home | +Libraries | +People | +FAQ | +More | +
+Dave Abrahams often shows up at C++ standards committee meetings on a bicycle.
Beyond that, we will just have to wait until he sends in a biography.
+ + + + diff --git a/people/dietmar_kuehl.htm b/people/dietmar_kuehl.htm new file mode 100644 index 0000000000..281155eb20 --- /dev/null +++ b/people/dietmar_kuehl.htm @@ -0,0 +1,42 @@ + + + + + |
+ Home | +Libraries | +People | +FAQ | +More | +
Dietmar Kuehl (the
+"ue" is actually a "u-umlaut", ie. one of those funny German
+characters which has two dots above it) was fork(2)ed in early 1968.
He visited school more or less successfully from 1973 to 1987. In 1987 he started to +study at the Technical University of Berlin. He finished his studies in 1997 with a Diplom +(roughly the German equivalent of a masters) in Mathematics. His thesis was "Design +Pattern for the Implementation of Graph Algorithms"; strike the "Design +Pattern" and put in "Generic" somehow to get an idea of the main topic. The +thesis is available from ftp://ftp.informatik.uni-konstanz.de/pub/algo/personal/kuehl/da.ps.gz.
+ +Since 1997 he has worked as consultant for a small company called Claas Solutions (the +"aa" is no typo), mainly working for major German banks. Since late 1995 Dietmar +Kuehl has been one of the moderators of the newsgroup comp.lang.c++.moderated. He is active on the C++ +Standards committee.
+ +Email: dietmar.kuehl@claas-solutions.de
+ +Home page: http://www.claas-solutions.de/kuehl/
+ + diff --git a/people/ed_brey.htm b/people/ed_brey.htm new file mode 100644 index 0000000000..9ac29f3dd5 --- /dev/null +++ b/people/ed_brey.htm @@ -0,0 +1,60 @@ + + + + + + + |
+ Home | +Libraries | +People | +FAQ | +More | +
+Ed Brey lives in Menomonee Falls, Wisconsin, a village outside of
+Milwaukee. In the summertime, he likes to play tennis with his fiancée, and
+in the winter, if there is enough snow, he likes to go tobogganing or
+ice-skating. If it is not nice enough outside for either of those, he plays
+on the piano. Although Ed enjoys doing those activities, most of his time is
+currently spent at work and at home studying. He works at Eaton Corporation in Milwaukee and is working
+on his masters degree in computer engineering through NTU.
+
+
Ed started working for Eaton as part of Marquette University's engineering co-op program. +Upon graduation in 1995 from Marquette with a BS in electrical and computer +engineering, he was hired on full-time at Eaton. At Eaton, Ed has been +primarily focused on embedded system design and programming in the industrial +controls industry. Recently, however, he has delved into writing a +near-real-time database engine running under Windows. + +
Ed has held programming as a pastime since his grade school days, when he +wrote a babysitting invoicing program. Soon after, he wrote a game inspired +by the TV game show "Press Your Luck". Ever since, programming languages and +concepts, along with finding ways to improve the art and science of coding +software, have always peeked his interest. + +
Lastly, Ed has managed to retain his perspective. As fun as computers and +programming are, Ed's true love in his life is his fiancée Beth.
+ +Email: brey@ductape.net + +
Home page: http://ww.cc.edu/~eschmied/ + + + + diff --git a/people/gavin_collings.htm b/people/gavin_collings.htm new file mode 100644 index 0000000000..bb6dbc4fde --- /dev/null +++ b/people/gavin_collings.htm @@ -0,0 +1,31 @@ + + +
+ + + + |
+ Home | +Libraries | +People | +FAQ | +More | +
Gavin Collings was born and bred in Wiltshire in the UK. After spending the
+1960s in childish pursuits, he spent the 1970s at school becoming ever more fascinated with the mysteries of physics. This he went on to study at St
+John's College, Cambridge until 1985, at which time he entered the world of employment.
After early work with other languages, he became involved with C++ in the early 1990s and now works as consultant, not far from his original home, in +Gloucestershire.
+He enjoys playing the piano, walking in the local countryside, playing 5-a-side (indoor soccer), and sailing.
+ + + + diff --git a/people/greg_colvin.htm b/people/greg_colvin.htm new file mode 100644 index 0000000000..9d4701e74c --- /dev/null +++ b/people/greg_colvin.htm @@ -0,0 +1,28 @@ + + + + + |
+ Home | +Libraries | +People | +FAQ | +More | +
Dr.
+Greg Colvin has been hacking happily since 1972. He is a member of the ANSI/ISO C++
+standards committee and a Principal Member of Technical Staff with the Java Products Group
+at Oracle Corporation. In his spare time he plays apocalyptic electric blues guitar in his
+Colorado, USA home studio.
|
+ Home | +Libraries | +People | +FAQ | +More | +
When
+Howard Hinnant is not monkeying around, he is the principal author of the
+Metrowerks CodeWarrior C++ library. He is also a member of the C++ Standards
+committee.
Howard is married with four children, two dogs, one cat, a rabbit, an +undetermined number of rodents (which the cat ignores), and ... well, we're +really not sure what else. When not sitting in front of his computer, Howard +enjoys snow skiing and ... more, snow skiing.
+ + + + diff --git a/people/jens_maurer.htm b/people/jens_maurer.htm new file mode 100644 index 0000000000..ba3805da08 --- /dev/null +++ b/people/jens_maurer.htm @@ -0,0 +1,39 @@ + + + + + + + |
+ Home | +Libraries | +People | +FAQ | +More | +
+Jens Maurer is a software developer from Germany who lives close to
+Frankfurt/Main. He was born in 1973 and hasn't died yet.
He has worked for a multimedia company programming home-banking applications, +CGI scripts and Java applications. He also helped program some simulation +systems for long-term decision support to aid businessmen in arguing about +company investments.
+He is neither married nor does he have a girl friend, but asked his +colleagues to find one for him.
+In his spare time, he likes visiting foreign countries but dislikes getting +there in uncomfortable airplane seats. On random week-ends, he enjoys +participating in historic dance courses (without a costume, of course). +Sometimes, he needs fresh air and goes for a walk.
+Email: Jens.Maurer@gmx.net
+ + + + diff --git a/people/jeremy_siek.htm b/people/jeremy_siek.htm new file mode 100644 index 0000000000..4f1d81eeab --- /dev/null +++ b/people/jeremy_siek.htm @@ -0,0 +1,36 @@ + + + + + + + |
+ Home | +Libraries | +People | +FAQ | +More | +
Jeremy Siek is a student at Univ. of Notre Dame, though currently
+he's on "sabatical", working with the SGI C++ compiler and library team.
+
+He is the author of the Matrix Template Library (MTL), and helped design the new Generic Graph Component Library (GGCL).
+
+Once in a while Jeremy "comes up for air" and enjoys fencing, hiking, skiing, and reading. He's also been spotted at a few fightin' irish
+tailgaters (BYOB).
+
+Jeremy has an intense fear for the ancient dark forests where dusty decks thrive and devour programmers, places where the light of abstraction
+has not yet reached.
|
+ Home | +Libraries | +People | +FAQ | +More | +
John Maddock
+is a software developer from England and holds a PhD in Chemistry,
+but found that computers smell less and explode less often!
John is the author of the regex++ +regular expression package, has an almost pathological +interest in anything that "can't be done", and can be +contacted at John_Maddock@compuserve.com.
+ + diff --git a/people/kevlin_henney.htm b/people/kevlin_henney.htm new file mode 100644 index 0000000000..51ac135692 --- /dev/null +++ b/people/kevlin_henney.htm @@ -0,0 +1,49 @@ + + + + + + + |
+ Home | +Libraries | +People | +FAQ | +More | +
+Kevlin Henney (mailto:kevlin@curbralan.com, http://www.curbralan.com)
+is an independent consultant and trainer based in the UK. He has developed and
+delivered training course material and consultancy on many aspects of OO
+development, which he has practiced across a number of domains for over a
+decade. His professional interests include patterns, OO and component based
+design, architecture, distributed object systems, C++, and Java. He is also a
+member of the BSI C++ standards committee.
+
Now that writing code is no longer the core responsibility of his job, his +non-professional interests seem to include the hacking associated with the +aforementioned professional interests. However, never being one to keep +something to himself (like C++'s relationship with C, this is regarded as both a +strength and a weakness), he shares/inflicts (delete as necessary) his +professional and non-professional development experiences with/on (ditto) others +through writing articles and presenting tutorials, workshops and papers at +conferences.
+He is married, and not just to his work. He and Carolyn have neither children +nor pets, but he feels that the missing aggravation is made up for by a house +that needs a great deal of work, requiring constant attention and feeding of +money. The little spare time that remains to him is taken up with music, +reading, pub appreciation, etc. Finally, although he enjoys writing, Kevlin is +not really one for writing in the third person.
+ + + diff --git a/people/mark_rodgers.htm b/people/mark_rodgers.htm new file mode 100644 index 0000000000..079a1dc761 --- /dev/null +++ b/people/mark_rodgers.htm @@ -0,0 +1,36 @@ + + + + + + + |
+ Home | +Libraries | +People | +FAQ | +More | +
Mark
+Rodgers lives in Wellington,
+the capital of New Zealand,
+with his wife, Clare, and their son, Ronnie.
He studied Computer Science at Victoria
+University of Wellington from 1983 to 1986, completing a
Mark has been programming in C++ since about 1990, and loves every minute of +it, but is continually amazed at how much more he still has to learn.
+You can contact Mark at mark.rodgers@cadenza.co.nz. + + + + diff --git a/people/paul_moore.htm b/people/paul_moore.htm new file mode 100644 index 0000000000..ef7dd4859a --- /dev/null +++ b/people/paul_moore.htm @@ -0,0 +1,38 @@ + + +
+ + + + |
+ Home | +Libraries | +People | +FAQ | +More | +
Paul
+Moore lives in Cheshire, England. He is married, with one son. His "day
+job" is as an Oracle DBA, but he writes C and C++ programs in his spare
+time.
Paul started programming on Acorn's BBC Micro and RISC PC series of +computers, but finally went mainstream and bought a PC, on which he now runs +Windows and Linux. Paul's main interest is in porting and developing open-source +software, and so his main programming language is C (at least until the open +source community switches to C++).
+Paul's main claim to C++ fame is that he owns all 3 editions of Bjarne +Stroustrup's "The C++ Programming language", plus the ARM and the C++ +standard, but he didn't own a C++ compiler until after the 3rd edition of +Stroustrup's book came out. Make of that what you will...
+ + + + diff --git a/people/valentin_bonnard.htm b/people/valentin_bonnard.htm new file mode 100644 index 0000000000..5c47561e2f --- /dev/null +++ b/people/valentin_bonnard.htm @@ -0,0 +1,27 @@ + + + + + |
+ Home | +Libraries | +People | +More | +FAQ | +
Valentin Bonnard is currently studying the semantics of
+programming languages and logical proofs. In his spare time, he writes C++ programs, and
+participates in newsgroup discussions about C++. He is also a member of AFNOR, the French
+C++ standardisation committee.