Articles & Books

How Microsoft is taking on the cross-platform challenge with Office—Mary Jo Foley

zaika-office.PNGModern C++, modern apps:

How Microsoft is taking on the cross-platform challenge with Office

by Mary Jo Foley

Summary: Microsoft's Office team has a new approach designed to allow it to share more of Office's code across not just Windows, but also Android, iOS and the Web.

Note: This is a 50-minute version of the same talk given at CppCon in two one-hour sessions. After presenting this at CppCon, Igor was invited to present the information also at Facebook's @Scale.

See also Dropbox's CppCon talk about how Dropbox uses a similar architecture, and moved to C++ to enable a single cross-platform source base after initially having written separate apps in Java for Android and Objective-C for iOS.

From the article:

Zaika talked about Microsoft's Office cross-platform architecture strategy at the recent Facebook @Scale conference. ... In his 50-minute session, Zaika detailed how Microsoft is building Office across Windows, Apple, Android and the Web by using C++. ...

The goal is to maintain a shared core of intellectual property — the guts of Office — all written in C++ and keep that shared core as large as possible. By doing this, risks of document corruption are reduced. On top of that core, there is a set of native UX application programming interfaces. ...

The goal of "write once, run anywhere" which technologies like Java, Flash and HTML5 were designed to try to solve by pushing the level of abstraction as low as possible or making application programming interfaces (APIs) very broad sounded good, Zaika said, but ended up creating impedance mismatch. Compatibility and interoperability problems, among others, arose. "Either you blew up, or the OS (operating system) blew up," Zaika said. ...

With a common C++ core, a thin native UX layer and evolving PALs, Microsoft is building its Office apps so they work on different OSes with fairly little tweaking required. Zaika cited PowerPoint as an example, noting that only four percent of its tens of millions of lines are unique to the WinRT/Universal version of Office (the touch-first Office release some of us have been calling "Gemini"). If the XAML code is excluded, the amount of shared code is 98.6 percent he said. The PowerPoint for Android code base includes 95 percent shared code, Zaika said.

User-defined literals—Marius Bancila

Today on the Codexpert blog:

User-defined literals

by Marius Bancila

From the article:

The C++11 standard introduced the possibility to create user-defined literals, that are basically built-in type literals (integer, float, char or string) followed by a used-defined suffix. User-defined literals enable the creation of new objects based on the built-in literal value and the applied user-defined suffix.

auto temp = 77_fah;       // 77 Fahrenheit degrees = 25 Celsius degrees

auto size = 1_KB;         // 1 kilobyte = 1024 bytes

auto emp  = "marius"_dev; // a user defined type Developer 

Ranges for the Standard Library—Eric Niebler

Fresh over the weekend, and in this morning's Standardization feed:

N4128: Ranges for the Standard Library

by Eric Niebler

From the article:

Eleven months ago, I began work on an updated range library for modern C++. Yesterday, I submitted a proposal to the C++ standardization committee to add ranges to the Standard Library. The proposal presents a vision for a future Standard Library that is familiar and yet more powerful, more usable, and more efficient than today’s.

My goal is nothing less than to change how C++ programmers write code. Seriously.

Overload 123 is now available

overload-123.PNGOverload 123 is now available. It contains the following C++-related articles, and more:


Overload 123

Alternative Overloads

[No pun intended. --Ed.] How do you return a default value given a condition? Malcolm Noyes presents solutions using older and newer C++ techniques.

Debug Complexity: How Assertions Affect Debugging Time

Debugging any program can be time consuming. Sergey Ignatchenko and Dmytro Ivanchykhin extend their mathematical model to consider the effect of assertions.

Defining Visitors Inline in Modern C++

The Visitor pattern can involve non-local boilerplate code. Robert Mill and Jonathan Coe present an inline VISITOR in C++.

Quick Q: Why is “want speed? pass by value” not recommended?—StackOverflow

Quick A: Because it performs worse than C++98 for common types like string and vector. The preferred way to optimize for rvalues is to add a && overload.

Fresh on SO:

Why is value taking setter member functions not recommended in Herb Sutter's CppCon 2014 talk (Back to Basics: Modern C++ Style)?

In Herb Sutter's CppCon 2014 talk Back to Basics: Modern C++ Style he refers on slide 28 (a web copy of the slides are here) to this pattern:

class employee {
  std::string name_;
  void set_name(std::string name) noexcept { name_ = std::move(name); }

He says that this is problematic because when calling set_name() with a temporary, noexcept-ness isn't strong (he uses the phrase "noexcept-ish").

Now, I have been using the above pattern pretty heavily in my own recent C++ code mainly because it saves me typing two copies of set_name() every time -- yes, I know that can be a bit inefficient by forcing a copy construction every time, but hey I am a lazy typer. However Herb's phrase "This noexcept is problematic" worries me as I don't get the problem here: std::string's move assignment operator is noexcept, as is its destructor, so set_name() above seems to me to be guaranteed noexcept. I do see a potential exception throw by the compiler before set_name() as it prepares the parameter, but I am struggling to see that as problematic.

Later on on slide 32 Herb clearly states the above is an anti-pattern. Can someone explain to me why lest I have been writing bad code by being lazy?

Quick Q: Why did C++ add delegating constructors?—StackOverflow

Quick A: Because they reduce code duplication, and so make code more readable and maintainable.

Recently on SO:

Why did C++11 introduce delegating constructors?

I cannot understand what the use is of delegating constructors. Simply, what cannot be achieve without having delegating constructors?

It can do something simple like this

class M
 int x, y;
 char *p;
 M(int v) : x(v), y(0), p(new char [MAX]) {}
 M(): M(0) {cout<<"delegating ctor"<<endl;}

But I don't see it, is it worth introducing a new feature for such a simple thing? May be I couldn't recognize the important point. Any idea?

Ranges in C++: Counted Iterables and Efficiency—Eric Niebler

New in Eric's series on ranges for C++:

Ranges in C++: Counted Iterables and Efficiency

by Eric Niebler

From the article:

I’ve been hard at work fleshing out my range library and writing a proposal to get range support into the standard. That proposal describes a foundational range concept: Iterable. An Iterable is anything we can pass to std::begin() and std::end() to get an Iterator/Sentinel pair. Sentinels, as I described here earlier this year, make it possible for the Iterable concept to efficiently describe other kinds of ranges besides iterator pairs.

The three types of ranges that we would like the Iterable concept to be able to efficiently model are:

  • Two iterators
  • An iterator and a predicate
  • An iterator and a count
The Iterator/Sentinel abstraction is what makes it possible for the algorithms to handle these three cases with uniform syntax. However, as Sean Parent pointed out here, the third option presents challenges when trying to make some algorithms optimally efficient. Back in February, when Sean offered his criticism, I promised to follow up with a blog post that justified the design. This is that post.

Quick Q: Should I prefer non-member std::begin and std::end?—StackOverflow

Quick A: Yes.

A classic on SO, just re-asked yesterday:

When to use std::begin and std::end instead of container specific versions

Are there any general preferences or rules that explain when container specific versions of begin and end should be used instead of free functions std::begin and std::end?

It is my understanding that if the function is a template whereby the container type is a template parameter then std::begin and std::end should be used, i.e.:

template<class T> void do_stuff( const T& t )
    std::for_each( std::begin(t), std::end(t), /* some stuff */ );

What about in other scenarios such as a standard / member function where the type of container is known? Is it still better practice to use std::begin(cont) and std::end(cont) or should the container's member functions cont.begin() and cont.end() be preferred?

Am I correct in assuming that there is no benefit in performance by calling cont.end() over std::end(cont)?

Insights into new and C++

I've written down some basic thinking on new and new standards:

Insights into new and C++

by Jens Weller

From the article:

Every now and then, I've been thinking about this. So this blogpost is also a summary of my thoughts on this topic, dynamic memory allocation and C++. Since I wrote the blog entries on smart pointers, and C++14 giving us make_unique, raw new and delete seem to disappear from C++ in our future code...