C++ Report. "Pre-publication" means this is what I sent to the Report, but it may not be exactly the same as what appeared in print, because the Report and I often make small changes after I submit the "final" draft for a column. Comments? Feel free to send me mail: smeyers@aristeia.com. if (inputFile) ... // test to see if inputFile // was successfully // opened Like all type conversion functions, this one has the drawback of letting function calls succeed that most programmers would expect to fail [cite 1]. In particular, it allows comparisons of smart pointers of completely different types: SmartPtr<Apple> pa; SmartPtr<Orange> po; ... if (pa == po) ... // this compiles! Even if there is no operator== taking a SmartPtr<Apple> and a SmartPtr<Orange>, this compiles, because both smart pointers can be implicitly converted into void*<

from templates because, like built-in pointers, they must be strongly typed; the template parameter specifies the type of object pointed to. Most smart pointer templates look something like this: template<class T> // template for smart class SmartPtr { // pointer objects public: SmartPtr(T* realPtr = 0); // create a smart ptr to an // obj given a dumb ptr to // it; uninitialized ptrs // default to 0 (null) SmartPtr(const SmartPtr& rhs); // copy a smart ptr ~SmartPtr(); // destroy a smart ptr // make an assignment to a smart ptr SmartPtr& operator=(const SmartPtr& rhs); T* operator->() const; // dereference a smart ptr // to get at a member of // what it points to This is a pre-publication draft of the column I wrote for the April 1996 issue of the C++ Report. "Pre-publication" means this is what I sent to the Report, but it may not be exactly the same as what appeared in print, because the Report and I of

Passing functions and function objects to general purpose routines is a powerful abstraction mechanism that should be taught in freshman computer science. In C-I-I-, a "function" can be defined directly by the user or by a library or can be defined indirectly via operator() as a member function of a class. It is not obvious how to treat these "functions" in a uniform manner. We will show how function templates in C++ provide an elegant and teachable mechanism for passing entities with functional behavior as arguments to other functions.

this document is to provide coding standards for writing C code in MLC++ . The description here can be used as a general guideline for programming in C , independent of MLC++ , but it is a low-level guide that does not discuss important issues of design. The MLC++ coding standards defines defines higher-level concepts used in MLC++ , including error-handling, defensive programming, and testing. The conventions established here are designed to make the code more readable and more reliable. Every rule has exceptions, but deviations from the standards should be documented in the code and explained

a limited time, get the free, fully searchable eBook—a $20 value! See last page for details.

Investigating the effectiveness of object-oriented testing strategies using the mutation method ‡

Abstract The Rcpp package simplifies integrating C++ code with R. It provides a consistent C++ class hierarchy that maps various types of R objects (vectors, functions, environments,...) to dedicated C++ classes. Object interchange between R and C++ is managed by simple, flexible and extensible concepts which include broad support for C++ STL idioms. C++ code can be compiled, linked and loaded on the fly. Flexible error and exception code handling is provided. Rcpp substantially lowers the barrier for programmers wanting to combine C++ code with R.

Tech Talk is a series of white papers created by engineers at Mantaro to share our knowledge in different technical areas. With a diverse and progressive set of clients, Mantaro has a rich history of staying at the leading edge of the technology curve. To keep the entire engineering team updated on the latest tools, trends, and technology, Mantaro holds regular meetings where engineers share their findings. Tech Talk captures this wealth of knowledge in the form of white papers which are made available to the general pubic through our website. If you have any questions or comments, please email us at

Abstract. Separation logic formalizes the idea of local reasoning for heap-manipulating programs via the frame rule and the separating conjunction P ∗ Q, which describes states that can be split into separate parts, with one satisfying P and the other satisfying Q. In standard separation logic, separation means physical separation. In this paper, we introduce fictional separation logic, which includes more general forms of fictional separating conjunctions P ∗ Q, where ∗ does not require physical separation, but may also be used in situations where the memory resources described by P and Q overlap. We demonstrate, via a range of examples, how fictional separation logic can be used to reason locally and modularly about mutable abstract data types, possibly implemented using sophisticated sharing. Fictional separation logic is defined on top of standard separation logic, and both the meta-theory and the application of the logic is much simpler than earlier related approaches.

Developing visualization applications is non-trivial and poses special challenges. This is due to the fact that typical visualization software processes a large amount of data resulting in large and sometimes very complex data structures. Traditional tools for debugging are of limited use because they de-couple the information they report from the spatio-temporal domain in which unexpected problems occur. We present a set of guidelines targeted specifically at debugging visualization software. The guidelines are inspired by experience in developing applications in both industry and research. Specific examples where the guidelines are applied are given throughout. In general, the key is to exploit the strengths of computer graphics and visualization itself in combination with some more well–known good practices.