Articles & Books

An interview with Sean Parent

I had the opportunity to interview Sean Parent!

An Interview with Sean Parent

by Jens Weller

From the Interview:

Lets start with the Introduction, who is Sean Parent?

Introducing yourself is always the toughest question. I’ve been a software developer for nearly 30 years and I’ve been fortunate enough to work on some great products and with some great people. I started my career at a small company, Orange Micro, where I wrote a print spooler for Mac (before MultiFinder) and “hijacked” Apple’s ImageWriter printer drivers to work with a wide variety of printers. I worked at Apple in the QuickDraw GX printing group (GX didn’t survive but lives on in spirit in Skia) and I worked on the PowerMac team that did the transition from 68K processors to PowerPC. I joined the Photoshop team at Adobe during the development of Photoshop 3.0, and managed Adobe’s Software Technology Lab for many years. I worked briefly at Google on the ChromeOS project, and then returned to Adobe where I’ve been working on mobile and web digital imaging products since.

What is your role as a principal scientist at adobe?

The role of a principal scientist in general is to act as a multiplier. I act as a consultant for individuals and groups, I work on various products and projects where I perceive a need. I helped to bring the rendering technology from Lightroom and the Photoshop Camera Raw plugin to mobile, first for the Revel product (a now defunct Lightroom like product for non-professionals) and then for Lightroom Mobile. I also brought the engine up inside the browser which is now part of Lightroom Web.

New Book “C++ Standard Library Quick Reference” Now Available

Marc Gregoire’s and Peter Van Weert’s brand new book “C++ Standard Library Quick Reference”, published by Apress is now available:

C++ Standard Library Quick Reference (Apress) 
C++ Standard Library Quick Reference (Amazon)

By Marc Gregoire and Peter Can Weert

From the abstract:

This quick reference is a condensed reference guide to the essential data structures, algorithms, and functions provided by the C++ Standard Library. Used by millions of C++ programmers on a daily basis, the C++ Standard Library features core classes for strings, I/O streams, and various generic containers, as well as a comprehensive set of algorithms to manipulate them. In recent years, the C++11 and C++14 standards have added even more efficient container classes, a new powerful regular expression library, and a portable multithreading library featuring threads, mutexes, condition variables, and atomic variables.

Needless to say, it is hard to know and remember all the possibilities, details, and intricacies of this vast and growing library. This handy reference guide is therefore indispensable to any C++ programmer. It offers a condensed, well-structured summary of all essential aspects of the C++ Standard Library. No page-long, repetitive examples or obscure, rarely used features. Instead, everything you need to know and watch out for in practice is outlined in a compact, to-the-point style, interspersed with practical tips and well-chosen, clarifying examples. The book does not explain the C++ language or syntax, but is accessible to anyone with basic C++ knowledge or programming experience. Even the most experienced C++ programmer though will learn a thing or two from it and find it a useful memory-aid. Among the topics covered are:

  • The essentials that the C++ Standard Library has to offer
  • How to use containers to efficiently store and retrieve your data
  • How to use algorithms to inspect and manipulate your data
  • How lambda expressions allow for elegant use of algorithms
  • What the standard string class provides and how to use it
  • How to write localized applications
  • What functionality the library provides for file and stream-based I/O
  • What smart pointers are and how to use them to prevent memory leaks
  • How to write safe and efficient multi-threaded code using the C++11 threading libraries

 

Trip report: Summer ISO C++ standards meeting (Oulu) -- Herb Sutter

A comprehensive trip report from the just-concluded ISO C++ meeting:

Trip report: Summer ISO C++ standards meeting (Oulu)

by Herb Sutter

From the article:

The big news is that C++ is feature-complete, and on time! We added several more features to the C++17 working paper (see next section), then approved the result to be sent out this summer for its major ISO international comment ballot, which is the Committee Draft or “CD” ballot.

... At this meeting, we added several more features into C++17: ...

Competing constructors--Andrzej Krzemieński

We all got some surprises like this:

Competing constructors

By Andrzej Krzemieński

From the article:

We start with a known C++ gotcha:

std::vector<int> v (size_t(4), 2); // parentheses
std::vector<int> u {size_t(4), 2}; // braces
 
assert (v.size() == 4);
assert (u.size() == 2);
 
assert (v[0] == 2); // elements: {2, 2, 2, 2}
assert (u[0] == 4); // elements: {4, 2}

In this post I want to analyze the source of the problem a bit further, and offer some suggestions on class design.

Quick Q: Are `==` and `!=` mutually dependent?

Quick A: They are not, because it is not always true.

Recently on SO:

Are `==` and `!=` mutually dependent?

You would not want the language to automatically rewrite a != b as !(a == b) when a == b returns something other than a bool. And there are a few reasons why you might make it do that.

You may have expression builder objects, where a == b doesn't and isn't intended to perform any comparison, but simply builds some expression node representing a == b.

You may have lazy evaluation, where a == b doesn't and isn't intended to perform any comparison directly, but instead returns some kind of lazy<bool> that can be converted to bool implicitly or explicitly at some later time to actually perform the comparison. Possibly combined with the expression builder objects to allow complete expression optimisation before evaluation.

You may have some custom optional<T> template class, where given optional variables t and u, you want to allow t == u, but make it return optional<bool>.

There's probably more that I didn't think of. And even though in these examples the operation a == b and a != b do both make sense, still a != b isn't the same thing as !(a == b), so separate definitions are needed.

Typedef Literacy--Michael Park

typedef explained!

Typedef Literacy

by Michael Park

From the article:

The typedef declaration provides a way to create an alias for an existing type. For example, we can provide an alias for int called integer like so:

typedef int integer;

I imagine most people have seen such declarations, and they are fairly simple to read. In fact it’s so simple that we may incorrectly conclude that the syntax for typedef is:

typedef <existing_type> <new_type_name>;

Quick Q: Why doesn't std::queue::pop return value?

Quick A: To guarantee exception safety and for performance.

Some time ago on SO:

Why doesn't std::queue::pop return value?

So, whats the difference, pop function could have done the same thing.

It could indeed have done the same thing. The reason it didn't, is because a pop that returned the popped element is unsafe in the presence of exceptions (having to return by value and thus creating a copy).

Consider this scenario (with a naive/made up pop implementation, to ilustrate my point):

template<class T>
class queue {
    T* elements;
    std::size_t top_position;
    // stuff here
    T pop()
    {
        auto x = elements[top_position];
        // TODO: call destructor for elements[top_position] here
        --top_position;  // alter queue state here
        return x;        // calls T(const T&) which may throw
    }

If the copy constructor of T throws on return, you have already altered the state of the queue (top_position in my naive implementation) and the element is removed from the queue (and not returned). For all intents and purposes (no matter how you catch the exception in client code) the element at the top of the queue is lost.

This implementation is also inefficient in the case when you do not need the popped value (i.e. it creates a copy of the element that nobody will use).

This can be implemented safely and efficiently, with two separate operations (void pop and const T& front()).