Home » Blog » Categories »

CppCast Episode 47: Software Defined Visualization with Jeff Amstutz

By robwirving | Mar 4, 2016 10:24 AM | Tags: None

Episode 47 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Jeff Amstutz to discuss Software Defined Visualization and Intel's SPMD Compiler.

CppCast Episode 47: Software Defined Visualization with Jeff Amstutz

by Rob Irving and Jason Turner

About the interviewee:

Jeff is a Visualization Software Engineer at Intel, where he works on the open source OSPRay project. He enjoys all things ray tracing, high performance computing, clearly implemented code, and the perfect combination of Git/CMake/modern C++. Prior to joining Intel, Jeff was an HPC software engineer at SURVICE Engineering where he worked on interactive ballistic simulation applications for the U.S. Army Research Laboratory, implemented using C++, CUDA, and Qt. When he is able, Jeff enjoys academic research in ray tracing and high performance computing, with a specific interest in multi-hit ray tracing algorithms and applications for both graphics 3D rendering and ray-based simulations.

In his spare time, Jeff enjoys powerlifting, golf, being an electric guitar nerd, and studying a wide spectrum of music ranging from progressive metal to ambient electronic music.

C++17 and its Technical Specifications

By Meeting C++ | Mar 3, 2016 08:50 AM | Tags: standardization intermediate experimental c++17 advanced

The 2nd part of my series on proposals for C++17 deals with Technical Specifications:

C++17 and its Technical Specifications

by Jens Weller

From the article:

Part 2 of my series about the current proposals for C++17. This part is covering the Technical Specifications (TS), which are currently released. Some of them will make it into C++17. Those not making it into C++17...

C++ User Group Meetings in March

By Meeting C++ | Mar 2, 2016 05:17 AM | Tags: community

The monthly overview on upcoming C++ User Group meetings at Meeting C++:

C++ User Group meetings in March 2016

by Jens Weller

From the article:

A new month, and more C++ User Groups are meeting! There are more details about running your own user group at the C++ User Group page of Meeting C++. My list of User Groups contains now 65 groups, which of the most have been active in the last year, some do not meet every month but most do. This month it is again 25 User Groups which have announced their meetings sofar!

During February I found 3 new C++ User Groups: Sofia, Hannover, Nantes.

The meetings...

Core C++ - lvalues and rvalues--Anthony Williams

By Adrien Hamelin | Mar 1, 2016 11:54 PM | Tags: intermediate c++11

One of C++ fundamentals explained:

Core C++ - lvalues and rvalues

by Anthony Williams

From the article:

One of the most misunderstood aspect of C++ is the use of the terms lvalue and rvalue, and what they mean for how code is interpreted. Though lvalue and rvalue are inherited from C, with C++11, this taxonomy was extended and clarified, and 3 more terms were added: glvalue, xvalue and prvalue. In this article I'm going to examine these terms, and explain what they mean in practice.

GoingNative 47: MSVC++ is* C++17 standard library feature complete!

By Marco Arena | Mar 1, 2016 06:09 AM | Tags: visual studio

[Updated to reflect the original post's title change. -- Ed]

 

*as of this video's release date, for the standard library

 

An in-depth look at what new C++17 standard library features are available in yet another round of STL updates:

GoingNative 47: MSVC++ is* C++17 standard library feature complete!

by Gabriel Ha

From the video:

as_const(), std::<chrono> helper functions, expression SFINAE in std::result_of and std::function, Improving overload detection for std::pair and std::tuple...

How to try these updates:

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.