Home » Blog » Categories » News

News

CppCast Episode 45: C++ in the Visual Effects Industry with Paul Miller

By robwirving | Feb 19, 2016 08:57 AM | Tags: None

Episode 45 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Paul Miller to discuss C++ in the Visual Effects Industry.

CppCast Episode 45: C++ in the Visual Effects Industry with Paul Miller

by Rob Irving and Jason Turner

About the interviewee:

Paul Miller is a partner and lead engineer at Digital Film Tools/Silhouette FX. He has been writing visual effects and image processing software for over 20 years, and has been using C++ for most of that time. He started his love of graphics and digital music on the Amiga in 1986, teaching himself C with K&R and the Amiga ROM Kernel manuals. In 1992 he ended up Wisconsin, writing software for the relatively new digital post production industry on Silicon Graphics workstations, and has been writing widely-used tools for that industry since. He uses Qt for cross-platform UI, Python, OpenGL, and OpenCL extensively.

He holds a private pilot's license and enjoys going to movies and beer festivals.

Notes on C++ SFINAE -- Bartlomiej Filipek

By Felix Petriconi | Feb 18, 2016 09:13 AM | Tags: c++14 c++11 advanced

Bartlomiej explains in his recent blog post in nice details the SFINAE construct.

Notes on C++ SFINAE

by Bartlomiej Filipek

From the article:

This time I’d like to tackle a bit more complex problem: SFINAE. I’m not using this paradigm on a daily basis, but I’ve stumbled across it several times and I thought it might be worth trying to understand this topic.

What is SFINAE? Where can you use it? Do you need this on a daily basis? Let’s try to answer those questions.

In the article he goes into details of Overload Resolution, Where can I use it?, enable_if, Expression SFINAE, Any disadvantages?, and Alternatives to SFINAE.

Revisiting QWidgets & data, refactoring and performance

By Meeting C++ | Feb 18, 2016 07:51 AM | Tags: qtdev intermediate basics advanced

A follow up on an older Blog post of mine:

Revisiting QWidgets & data, refactoring and performance

by Jens Weller

From the article:

My CMS project has grown quite a bit, and there are a few places where I think I should refactor the code. One of the larger ones is that TreeItem::get<T> returns a pointer instead of a reference. Another one is related to how the Qt UI application is acting when opening a new panel in the TabControl. There used to be a noticeable delay...

The promises and challenges of std::async task-based parallelism in C++11 -- Eli Bendersky

By Mantosh Kumar | Feb 16, 2016 10:47 PM | Tags: c++11

How to use std::async for task-based parallelism in C++11.

The promises and challenges of std::async task-based parallelism in C++11

by Eli Bendersky

From the article:

"Task-based parallelism" refers to a higher level of abstraction, where the programmer manages "tasks" - chunks of work that has to be done, while the library (or language) presents an API to launch these tasks. It is then the library's job to launch threads, make sure there are not too few or too many of them, make sure the work is reasonably load-balanced, and so on. For better or worse, this gives the programmer less low-level control over the system, but also higher-level, more convenient and safer APIs to work with. Some will claim that this also leads to better performance, though this really depends on the application.

Try out the latest C++ compiler toolset--Andrew Pardoe

By Marco Arena | Feb 16, 2016 09:29 AM | Tags: visual studio

Today the Visual C++ team is announcing a new experiment: releasing the VC++ toolset as a NuGet package that can be added to any C++ project or solution targeting desktop:

Try out the latest C++ compiler toolset without waiting for the next update of Visual Studio

by Andrew Pardoe

From the article:

Why might you want to try out new tools? There’s a lot of change happening in Visual C++ today: support for new features going into the C++17 language such as Coroutines...

One of C++ most underrated features: Namespace aliases--Jonathan Müller

By Adrien Hamelin | Feb 15, 2016 09:17 AM | Tags: intermediate c++11

A nice story with a goal:

One of C++ most underrated features: Namespace aliases

by Jonathan Müller

From the article:

About two months ago I wrote the following r/cpp comment:

[compte supprimé]

  • You could always just alias the namespace like namespace fnc = FunctionalPlus.

foonathan

  • Namespace aliases are one of C++ most underrated features.

In the thread a new library was presented. One user complained about the long namespace name, (s)he got the above replies. Judging by the number of upvotes, people seemed to agree with my comment. In this blog post I am going to elaborate it...

A bit of background for the unified call proposal

By Bjarne Stroustrup | Feb 14, 2016 03:43 PM | Tags: None

C++ provides two calling syntaxes, x.f(y) and f(x,y). This has bothered me for a long time. I discussed the problem in the context of multimethods in D&E in 1994, referring back to a proposal by Doug Lea from 1991, and again in 2007. Each of the syntaxes has its virtues, but they force design decisions on people, especially library designers. When you write a library, which syntax do you use for operations on objects passed to you by your users? The STL insists on the traditional functional syntax, f(x,y), whereas many OO libraries insist on the dot notation, x.f(y). In turn, libraries force these decisions on their users.


Interestingly, I solved the problems for operators: x+y doesn’t care whether you provide operator+(T,T) or T::operator+(T). The problem is getting more noticeable as we get more generic libraries. Note begin(c) and c.begin() for range-for loops and in general code. Why do we/someone have to write both? If c.begin() exists, begin(c) should find it, just as x+y finds the right implementation. Such call-syntax adapters are pure overhead and different people’s adapters can clash.


In early 2014, Herb Sutter and I each independently decided to propose a unified syntax. Herb suggested unification based on allowing x.f(y) to find a non-member function, giving preference to the x.f(y) syntax, whereas my ideal was that x.f(y) and f(x,y) should mean exactly the same. After a quick discussion, we joined forces. Based on real input from code and users, I reluctantly agreed that for compatibility reasons, x.f(y) and f(x,y) could not mean exactly the same. The only feasible way forward was to do a traditional lookup based on the syntax used, and then try the other syntax if the first one failed. Stability – backwards compatibility – is an important feature, overruling my desire for perfection.


To my surprise, many people came out strongly against x.f(y) finding f(x,y) – even if member functions were preferred over free-standing functions by the lookup rules. I received email accusing me of “selling out to the OO crowd” and people whose experience and opinion I respect insisted that x.f(y) finding f(x,y) would seriously compromise their ability to design stable interfaces. I think those fears are greatly exaggerated, but I could be wrong. Also, I prefer the dot syntax in some cases; for example, I find x.f(y).g(z) more readable than g(f(x,y),z). However, there was no chance of acceptance of a proposal that included x.f(y) finding f(x,y). Maybe modules will eventually help here. Furthermore, David Vandevoorde pointed out that because of the two-phase lookup rules having x.f(y) find f(x,y) would complicate the task for compiler writers and possibly be expensive in compile time.


So, we are left with a simple proposal to allow f(x,y) to find x.f(y) where f(x,y) wouldn’t work today. This solves the problem for library writers and their users along the lines of the STL:

  • Library designers don’t have to force users to use one preferred syntax or to duplicate the implementation to handle both.
  • It allows us to write simple concepts for new libraries.
  • We no longer have to write call-syntax adapters.
  • We can in many cases add functionality to an abstraction without modifying a class
  • We no longer have to bother the users with the distinction between member functions and helper functions.

The proposal was approved by the Evolution Working Group. Faisal Vali did an experimental implementation in Clang. Now we just have to hope that we can agree on exact wording in time for C++17. I consider it a small proposal that will significantly simplify the way we design and use libraries.

Compiler improvements in VS 2015 Update 2--Andrew Pardoe

By Marco Arena | Feb 12, 2016 06:58 AM | Tags: visual studio

The C++ compiler team is excited for you to try out the compiler in Visual Studio 2015 Update 2 CTP 1. Let’s dive into some of the feature improvements they have made in the compiler for Update 2:

Compiler improvements in VS 2015 Update 2

by Andrew Pardoe

From the article:

Since Update 1 we’ve made progress on being Standards-conformant for lot of C++11 and C++14 features...