Variadic Templates in C++ -- Eli Bendersky

By Blog Staff | Oct 28, 2014 01:43 AM | Tags: None

A nice tutorial on a feature that leads to convenient and safe calling code:

Variadic Templates in C++

by Eli Bendersky

From the article:

Prior to C++11, the only way to write functions that take an arbitrary number of arguments was to use variadic functions like printf, with the ellipsis syntax (...) and the accompanying va_ family of macros. If you've ever written code using this approach you know how cumbersome it is. In addition to being type unsafe (all type resolution has to be done explicitly with casts in va_arg, at runtime), it's also tricky to get right. The va_ macros perform low-level memory manipulation, and I've seen a lot of code that segfaults because it isn't using them carefully enough.

But what always bothered me most with this approach is leaving something that is clearly known at compile-time, to run-time. Yes, when we write a variadic function we don't know all the ways it's going to be used. But when the compiler puts the whole program together, it does know. It sees perfectly well all the invocations of the function throughout the program, and all the possible argument types it gets passed (types are, after all, resolved at compile-time in C++).

Variadic templates

One of the new features of C++11 is variadic templates. Finally, there's a way to write functions that take an arbitrary number of arguments in a type-safe way and have all the argument handling logic resolved at compile-time, rather than run-time. Variadic templates can be used for much more than just functions that take an arbitrary number of arguments; in this article I want to demonstrate some of these capabilities...

C++11: Let's Write a "Hello, Lambda!" -- Ovidiu Cucu

By Blog Staff | Oct 27, 2014 10:35 AM | Tags: None

Fresh on codexpert:

C++11: Let's Write a "Hello, Lambda!"

by Ovidiu Cucu

From the article:

... Getting rid of optional parts, we can make our program simpler, as follows:

// Example #2

#include <iostream>

int main()
{
    [] { std::cout << "Hello Lambda!"; } ();
}

Further, let’s take a little deeper look in the lambda introducer part...

A different listing for the C++ Proposals

By Meeting C++ | Oct 27, 2014 07:01 AM | Tags: standardization experimental

Two news in one: I used an old project on the weekend to have an alternative listing for the C++ Proposals:

An alternative listing for the C++ Proposals

This years C++ Proposals listed by mailing and subgroup

by Jens Weller

Urbana Proposals - C++17 insight?

By Meeting C++ | Oct 25, 2014 01:59 AM | Tags: intermediate experimental c++17 c++ committee basics advanced

I've started with my series on the proposals for the next C++ Committee Meeting:

Urbana Proposals - C++17 insight?

by Jens Weller

From the article:

A short series to give you an overview over the Papers submitted in the latest mailing for the C++ Committee Meeting in Urbana-Champaign in Illinois. At the beginning of November the C++ Committee will have its 3rd Meeting this year. As C++14 is now finished, the focus is clearly on the upcoming C++17 standard.

From the archives: "C++: as close as possible to C -- but no closer" -- A. Koenig and B. Stroustrup

By Blog Staff | Oct 24, 2014 01:00 AM | Tags: None

For your Friday reading pleasure, we recently came across one of the very earliest C++ standardization papers written, with number N0007 (or call it "007"):

C++: as close as possible to C -- but no closer

by Andrew Koenig and Bjarne Stroustrup

It's interesting too see how much C++ has stayed true to its root design. And the thesis and contents of this paper are both remarkably current, and to be considered by those who would attempt to C-ify C++, or C++-ify C.

From the paper:

ANSI C and the C subset of C++ serve subtly different purposes. ...

The purpose of this note is to summarize the remaining differences between the draft ANSI C standard and C++, explain their motivation, and point out cases where these differences are less important than they might appear at first.

Writing min function, part 4: Const-Correctness -- Fernando Pelliccioni

By Fernando Pelliccioni | Oct 22, 2014 10:30 AM | Tags: None

Writing min function, part 4: Const-Correctness

by Fernando Pelliccioni

From the Article:

This is the fourth article of the series called “Writing min function”.

I still have to solve two mistakes made in the code of the previous posts. One of them is C++ specific, and the other it is a mistake that could be made in any programming language.

Extension methods in C++ -- Marius Bancila

By Blog Staff | Oct 22, 2014 04:52 AM | Tags: None

Recently on Codexpert, an enthusiastic and very readable reaction to two fresh standards proposals that will be considered two weeks from now at the ISO C++ meeting in Urbana-Champaign, Illinois, USA:

Extension methods in C++

by Marius Bancila

From the article:

... if x.f(y) and f(x,y) were equivalent it would be very easy to write the above code like this:

auto v = std::vector<int> {1,2,3,4,5,6,7,8,9};

auto s = v.where([](int e){return e % 2 == 0; })
          .select([](int e){return e*e; })
          .sum();

Isn’t that beautiful? I think it is.

...

The N4174 paper is rather an exploration of possibilities for uniform calling syntax than a very formal proposal. There are various aspects that have to be carefully considered especially when considering how to treat f(x, y). The N4165 paper makes a good case of the uniform calling syntax, explains the benefits better and argues against treating f(x) equivalent to x.f(). You should go ahead and read the two papers for detailed information. However, I sincerely hope that one day this will be accepted and become a core feature of the C++ language.

Quick Q: Does unordered_map<string,MyClass>::erase() destroy my MyClass objects? -- SO

By Blog Staff | Oct 21, 2014 10:47 AM | Tags: basics

Quick A: No, but unordered_map<string, unique_ptr<MyClass>>::erase and unordered_map<string, shared_ptr<MyClass>>::erase do.

Today on SO:

std::unordered_map<std::String, myClass*> -- does std::unordered_map::erase() call myClass' DTor?

Assume I have some unordered_map of pointers to class instances, would erasing an object from that map also delete the instance?

(rewording the question:) If I wanted to delete that instance, which version would be right?

if(it != map.end())
{
    delete it->second;
    map.erase(it);
}

or simply

if(it != map.end())
    map.erase(it);

?

A pair of articles on advanced template mechanics -- Eli Bendersky and Eric Niebler

By Blog Staff | Oct 21, 2014 10:34 AM | Tags: experimental advanced

If you're a very advanced C++ developer with an appetite for template mechanics, these two articles that were posted in the past 24 hours may interest you.

Note: The vast majority of C++ developers don't need to know this, but very advanced developers will find the material and the techniques interesting.

SFINAE and enable_if

by Eli Bendersky

Customization Point Design in C++11 and Beyond

by Eric Niebler

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

By Blog Staff | Oct 20, 2014 10:09 AM | Tags: None

Modern 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.