Home » Blog » 2016 » February

February 2016

Another polymorphism -- Andrzej KrzemieĊ„ski

By Felix Petriconi | Feb 29, 2016 02:52 AM | Tags: intermediate

Andrzej goes into detail how variants can be seen as a type of polymorphism in his recent blog post.

Another polymorphism

by Andrzej Krzemieński

From the article:

In this post we will try to see by a practical example what Boost.Variant is for. You can sometimes see examples that use type variant<int, double, string>, but to me they are artificial: I never needed to use something that is either a double or int; but I still consider this library useful. Even if you are already familiar with Boost.Variant an its concepts of “never-empty guarantee” and “static visitor”, I made sure there is still something you can get from reading this post.

Selecting by interface, an idea almost to good to be true

By Meeting C++ | Feb 27, 2016 10:23 AM | Tags: intermediate experimental c++11 boost advanced

I had an idea last night...

Selecting by interface, an idea almost to good to be true

by Jens Weller

From the article:

Last night, I've been coding until 3 am. Working on an API which will connect my CMS to JSON libraries in a generic way. For this I did study different JSON Libraries in the past weeks. I almost wrote another one wink Yet, I had the idea to write a generic interface to interface with some of these libraries, so that my own code is not hard wired to a certain API...

CppCast Episode 46: Hybrid C++/Javascript apps with Sohail Somani

By robwirving | Feb 27, 2016 06:54 AM | Tags: None

Episode 46 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Sohail Somani to discuss building hybrid apps with Javascript and C++.

CppCast Episode 46: Hybrid C++/Javascript apps with Sohail Somani

by Rob Irving and Jason Turner

About the interviewee:

Sohail Somani is a contract cross-platform application developer who has been working in C++ and Python for over 10 years. He has worked in a variety of fields such as computer graphics, C++ compilers, finance and plain old desktop apps. Sohail's obsession with (or hate of) time tracking led him to create Worklog Assistant, a cross-platform time tracker for JIRA, which is in use by more than a thousand companies worldwide. He hopes to one day achieve time tracking nirvana for his users so that he can finally move on to something else. He might be too optimistic...

Otherwise, Sohail is a full-time, work-at-home dad of 2 since 2007. He enjoys playing hockey and listening to rap music. You can contact him at hello@sohailsomani.com - but he doesn't recommend that you visit the domain.

a bit of background for concepts and C++17 -- Bjarne Stroustrup

By Bjarne Stroustrup | Feb 26, 2016 02:15 PM | Tags: None

In about 1987, I tried to design templates with proper interfaces. I failed. I wanted three properties for templates: full generality/expressiveness, zero overhead compared to hand coding, and good interfaces. I got Turing completeness, better than hand-coding performance, and lousy interfaces. The lack of well-specified interfaces led to the spectacularly bad error messages we saw over the years. The other two properties made templates a run-away success.

The solution to the interface specification problem was named “concepts” by Alex Stepanov. A concept is a set of requirements on a set of template arguments. “Concepts” is currently an ISO TS and it is proposed to be put into the standard proper for C++17. A concept is a compile-time predicate. For example, if a template takes a type argument, we can specify that an argument, T, can be an iterator, Iterator<T>, a random access iterator, Random_access_iterator<T>, or maybe a number, Number<T>. Similarly, we can specify that a set of template arguments must meet a predicate, for example Mergeable<In1, In2, Out>. This is very expressive and nicely cheap to compile (cheaper than using template metaprogramming workarounds). Students can use it after a lecture or two. You can, of course, define your own concepts and we can have libraries of concepts. Concepts enable overloading and eliminate the need for a lot of ad-hoc metaprogramming.

It was not easy to get to this point. In the early 2000s there were several ideas, including the one that became the current approach. However, we struggled with an approach based on specifying requirements as sets of functions. Dealing with implicit conversions was hard, interactions between existing unconstrained templates and templates with concepts were hard to manage, and writing a compiler that generated acceptable code took heroic efforts by Doug Gregor. Compilation speed was nowhere near acceptable, though. In the end, the committee pulled the plug on the C++0x concepts.

But we still wanted and needed concepts! Together with Gabriel Dos Reis and Andrew Sutton, I started to re-design concepts from scratch. In 2011, Alex Stepanov called a meeting in Palo Alto, where a largish group, including Sean Parent and Andrew Lumsdaine, attacked the problem from the user’s perspective: What would a properly constrained STL look like? Then, we went home to invent language mechanisms to approximate that ideal. That re-booted of the standards effort and led to the current TS and compiler. Andrew Sutton’s implementation has been used for over three years now and is part of GCC 6.0.

The current concept design focuses on the specification of interfaces. This has led some people to (wrongly) conjecture that we did not care about checking of template definitions and that concepts (as opposed to C++0x concepts) could not be used for that. In reality, the 2006 POPL paper shows how to do definition checking, Gabriel Dos Reis’ experimental language Liz implements those ideas, and recently Andrew Sutton quickly demonstrated that our predicate model easily handles definition checking even when implicit conversions and move operations are used. What we do worry about is how to gradually convert large C+98-style code bases to use definition checking and how to allow data collection, tracing, telemetry, etc. without interface changes.

We should have concepts in C++17, not just in a TS. “Concepts” as specified in the TS is an immensely useful feature for designers of generic code and together with constexpr functions lead to greatly simplified and more maintainable code. Sadly, the concepts-based Ranges library is by some deemed not ready for C++17, so it is likely to stay a TS for a while, – even though concepts were designed to exactly match the requirements of the STL algorithms.

A bit of background for the default comparison proposal -- Bjarne Stroustrup

By Bjarne Stroustrup | Feb 26, 2016 10:50 AM | Tags: None

In 2014, Oleg Smolsky proposed to add default member functions defining comparisons. That re-ignited a decades-old debate. I once asked Dennis Richie why C didn’t provide a built-in == (equality) the way it provides a built-in = (copy). The answer was that until 1978 C didn’t have = for structs either, and copying could be efficiently implemented by something like memcpy(), but comparison couldn’t because the layout of structs included “holes” caused by alignment that had to be ignored. The days where compilers could handle individual members one by one and still generate optimal code for them were still far in the future, so I postponed dealing with comparisons. If you wanted one, you could write it yourself. That’s true, but many people, including Alex Stepanov, have objected to the inconvenience.

The killer argument for default comparisons is not actually convenience, but the fact that people get their equality operators wrong. They forget to compare all elements (especially when updating a struct with a new member). Also, given inheritance, a X::operator==(const X&) is easy to misuse (whether virtual or not). We get slicing (b==d will work even if b and d are of different classes in a hierarchy, and usually give a wrong answer). If people define operator==() as a member; then the left- and right-hand operand obey different conversion rules. Also, defining the semantics for == and != is relatively simple, but there are subtleties about other operators, such as <=; does its meaning involve < and == or < and !? Contrary to “common knowledge” there seems to be little difference in performance.

Lots of people joined the discussions and the discussions went all over the place. How do we handle pointers? (we don’t), how do we handle mutable members?, should we use static reflection?, etc., etc., At times, I thought that we would get nothing. That wouldn’t be a tragedy because default comparisons are not on my (mostly mythical) top-20 list of desirable improvements to C++. However:

  • I started trying to design == in analogy to = as if Dennis and I had been doing it in 1980 or so.
  • Jens Maurer helped us with wording, making sure the rules were consistent.
  • Herb Sutter helped ensure that lookup rules were sane from a programmer’s point of view.

Using namespaces and operator==(), you can (today) construct programs for which a==b is true in one place and false in another. That’s unavoidable if you treat == as an ordinary function. But == is not ordinary! Its semantics is fixed by the rules of logic (we cannot have both a==b and a!=b), and its meaning must match that of copying (e.g., after a=b we must have a==b). Secondly, slicing is evil. Defining = in terms of references was a mistake. As far as I can remember, this is the only place in C++ where I made a change based solely on the advice of a theoretician: “OO is based on references, so for uniformity == should be based on references.” But there is nothing OO about ==! Each class (in a hierarchy or not) has its own ==, just like it has its own =. You can define “odd” assignments and comparisons yourself. That’s your problem, but the default must be sane and safe.

Jens suggested the obvious solution: just ban slicing for both == and =. I had shied away from this incompatible change, but the result is beautiful. If the committee approves, we have a coherent set of rules and we eliminate some subtle nasty bugs! To preserve the techniques of tag dispatching, the rule is that you cannot slice if the derived class has added a non-static data member. That is, the derived to base conversion works unless it produces a sliced object.

CppCon 2016 registration is open

By Jon Kalb | Feb 25, 2016 08:08 AM | Tags: community

The early bird registration for the upcoming CppCon 2016 in September is open.

 
 

Early Bird registration

The big new is that there are six classes that will be held on the Saturday and Sunday before the conference. Attendees can choose between classes on the Core Guidelines, concurrency, embedded developement, C++11/14, Qt/Widgets, and low-latency programming taught by some of the best instructors in the industry.

Registration opportunties also include a field trip to Seattle's Living Computer Museum, attending the Standards Committee's Study Group on game development and low-latency, and getting logo'ed shirts.

Cheerp PreExecuter: compile-time evaluation of constructors--Sander Mathijs van Veen

By Adrien Hamelin | Feb 23, 2016 06:00 AM | Tags: efficiency advanced

An advancement in the world of C++ to javascript:

Cheerp PreExecuter: compile-time evaluation of constructors

by Sander Mathijs van Veen

From the article:

The size of a JavaScript web application, especially when compiled from a complex C++ source, has a key role on the quality of the user experience, being directly connected to the download and startup time. Size also has a big impact on the traffic and bandwidth needs of the hosting server, which translates one to one into costs. Therefore, minimizing the size of JavaScript applications compiled from C++ with Cheerp has always been one of our priorities...

Automatic event cleanup in C++--Nercury

By Adrien Hamelin | Feb 23, 2016 05:51 AM | Tags: intermediate

How to handle events?

Automatic event cleanup in C++

by Nercury

From the article:

Event subscriptions have a downside: someone has to unsubscribe. Usual approach is to make sure it happens when the subscibtion is no longer needed.

But, can we do it automatically, in a way that is easy to use and extend?

Let's see how it can be done in C++...