CGAL is a Computational Geometry Algorithms Library written in C++, which is being developed by research groups in Europe and Israel. The goal is to make the large body of geometric algorithms developed in the field of computational geometry available for industrial application. We discuss the major design goals for CGAL, which are correctness, flexibility, ease-of-use, efficiency, and robustness, and present our approach to reach these goals. Generic programming using templates in C++ plays a central role in the architecture of CGAL. We give a short introduction to generic programming in C++, compare it to the object-oriented programming paradigm, and present examples where both paradigms are used effectively in CGAL. Moreover, we give an overview of the current structure of the CGAL-library and consider software engineering aspects in the CGAL-project. Copyright c ○ 1999 John Wiley & Sons, Ltd. KEY WORDS: computational geometry; software library; C++; generic programming;

For the last 15 years, implementors of multiple view programming environments have sought a single code model that would form a suitable basis for all of the program analyses and tools that might be applied to the code. They have been unsuccessful. The consequences are a tendency to build monolithic, single-purpose tools, each of which implements its own specialized analyses and optimized representation. This restricts the availability of the analyses, and also limits the reusability of the representation by other tools. Unintegrated tools also produce inconsistent views, which reduce the value of multiple views. This paper describes an architecture that allows a single, minimal representation of program code to be extended as required to support new tools and program analyses, while still maintaining a simple and uniform interface to program properties. We present architectural patterns that address efficiency, correctness and the integration of multiple analyses and tools in a modular fashion.

This paper describes the design and implementation of version 1.1 of the FIRE engine. The FIRE engine is a C++ class library implementing finite automata and regular expression algorithms. The algorithms implemented in the toolkit are almost all of those presented in the taxonomies of finite automata algorithms [Wat93a, Wat93b]. The reader is assumed to be familiar with the two taxonomies and with advanced C++ programming techniques. The toolkit is implemented largely in an object-oriented style, with finite automata and regular expressions being defined as classes. All of the classes and functions in the toolkit are presented in the same format. For each class (or function) the format includes a short description of its behaviour, details of its implementation, and techniques for improving its performance. CONTENTS Contents 1 Introduction 3 1.1 Coding conventions and performance issues : : : : : : : : : : : : : : : : : : : : : : 3 1.1.1 Performance tuning : : : : : : : : : : : : ...

This paper is an introduction to the programmer's interface of version 1.1 of the FIRE engine. The FIRE engine is a C++ class library implementing finite automata and regular expression algorithms. The algorithms implemented in the toolkit are almost all of those presented in the taxonomies of finite automata algorithms [Wat93a, Wat93b]. None of the implementation details of the library are discussed --- such design and implementation details are given in [Wat94]. The toolkit is unique in providing implementations of all of the known algorithms for constructing finite automata. The implementations, which were developed with efficiency in mind, are intended for use in production quality applications. No shell or graphical user-interface is provided, as the toolkit is intended for integration into applications. The implementations of the algorithms follow directly from the abstract algorithms appearing in [Wat93a, Wat93b]. As such, the toolkit also serves as an educational example of the...

This document describes the TRansportation ANalysis SIMulation System (TRANSIMS) software architecture and high-level design for the first Interim Operational Capability (IOC-1). Our primary goal in establishing the TRANSIMS software architecture is to lay down a framework for IOC-1. Wewant to make sure that the various components of TRANSIMS are effectively integrated, both for IOC-1 and beyond, so that TRANSIMS remains flexible, expandable, portable, and maintainable throughout its lifetime. In addition to outlining the high-level design of the TRANSIMS software, we also set forth the software development environment and software engineering practices used for TRANSIMS. I. Introduction .................................................................................................................3 A. Overview ................................................................................................................. 3 B. The Importance of Architecture .................

An architecture for a new generation of multimedia systems is presented based on the concept of metawidgets, which are collections of alternative representations for information, both within and across sensory modalities, along with user--transparent mechanisms for choosing among them. The proposed architecture allows us to overcome certain drawbacks of today's systems, where the designer typically must assign each component of the display to a specific modality in a fixed and inflexible manner. The design of the POLYMESTRA environment based on our architecture is next described in detail, with particular emphasis on the layered development approach, core software tools and inter--application communication. Finally, we discuss the current status of the implementation, and outline plans for distribution of the prototype later this year to get user feedback. KEYWORDS: multimedia systems, multimodal widgets, object oriented frameworks, C++ and STL. 1. INTRODUCTION Multimedia systems which...

to see if there's a member function template it can instantiate that would let it perform the conversion it's looking for. It finds such a template (the one taking the formal type parameter newType), so it instantiates the template with newType bound to the base class of T that's the target of the conversion. At that point, the only question is whether the code for the instantiated member function will compile. In order for it to compile, it must be legal to pass the (dumb) pointer pointee to the constructor for the smart pointer-to-base-of-T. pointee is of type T, so it is certainly legal to convert it into a pointer to its (public or protected) base classes. Hence, the code for the type conversion operator will compile, and the implicit conversion from smart pointer-to-T to smart pointer-to-base-of- Twill succeed. This is a pre-publication d

This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Portions of this product may be derived from the UNIX ® system, licensed from Novell, Inc., and from the Berkeley 4.3 BSD system, licensed from the University of California. UNIX is a registered trademark in the United States and other countries and is exclusively licensed by X/Open Company Ltd. Third-party software, including font technology in this product, is protected by copyright and licensed from Sun’s suppliers. RESTRICTED RIGHTS: Use, duplication, or disclosure by the U.S. Government is subject to restrictions of FAR 52.227-

Far too many programmers and software designers consider efficient C++ to be an oxymoron. They regard C++ as inherently slow and inappropriate for performancecritical