Home » Blog » Tags » intermediate

intermediate

CppCon 2014 Modernizing Legacy C++ Code--James McNellis & Kate Gregory

By Adrien Hamelin | Feb 9, 2015 08:00 AM | Tags: intermediate c++11

While we wait for CppCon 2015 in September, we’re featuring videos of some of the 100+ talks from CppCon 2014. Here is today’s feature:

Modernizing Legacy C++ Code

by James McNellis and Kate Gregory

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

C++ is a programming language with a long, storied history spanning over three decades--four if one includes its C ancestry. The C++ language has undergone many changes during that time, compiler technology has advanced substantially, and computers today are very different from the computers of decades past. But despite all of these advances, there's an awful lot of C++ code in use today that looks like it was written in the 1980s. In some cases, the code was written in the 1980s and it's still in use; in other cases, it's recently-written code that just doesn't use modern style.

In this talk, we'll discuss some of the problems with legacy code, and review some practical techniques for applying principles of modern C++ to gradually improve the quality of legacy code and improve maintainability and debuggability. We'll show how some very small changes to code can yield huge benefits.

CppCon 2014 Writing Data Parallel Algorithms on GPUs--Ade Miller

By Adrien Hamelin | Feb 6, 2015 08:00 AM | Tags: performance intermediate

While we wait for CppCon 2015 in September, we’re featuring videos of some of the 100+ talks from CppCon 2014. Here is today’s feature:

Writing Data Parallel Algorithms on GPUs

by Ade Miller

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Today most PCs, tablets and phones support multi-core processors and most programmers have some familiarity with writing (task) parallel code. Many of those same devices also have GPUs but writing code to run on a GPU is harder. Or is it?

Getting to grips with GPU programming is really about understanding things in a data parallel way. This talk will look at some of the common patterns for implementing algorithms on today's GPUs using examples from the C++ AMP Algorithms Library. Along the way it will cover some of the unique aspects of writing code for GPUs and contrast them with a more conventional code running on a CPU.

Sqlpp11, An EDSL For Type-Safe SQL In C++11

By Meeting C++ | Feb 5, 2015 03:41 AM | Tags: sql meeting c++ intermediate database c++11

A new video from Meeting C++ 2014:

Sqlpp11, An EDSL For Type-Safe SQL In C++

by Roland Bock

From the talk description:

Most C/C++ interfaces to SQL databases are string based. Theses strings effectively hide expression structures, names and types from the compiler. And they are vendor-specific. And they defer expression parsing and validation until the test phase or (even worse) production...

Quick Q: What is move_iterator for?

By Adrien Hamelin | Feb 4, 2015 02:12 PM | Tags: intermediate c++11

Quick A: To enabling moving out of *iterator.

Recently on SO:

What is move_iterator for?

If I understand it correct, a=std::move(b) binds reference a to the address of b. And after this operation the content that b points to is not guaranteed.

The implementation of move_iterator here has this line

auto operator[](difference_type n) const -> decltype(std::move(current[n]))
  { return std::move(current[n]); }

However, I don't think it makes sense to std::move an element in an array. What happens if a=std::move(b[n])?

The following example confuses me also:

std::string concat = std::accumulate(
                             std::move_iterator<iter_t>(source.begin()),
                             std::move_iterator<iter_t>(source.end()),
                             std::string("1234"));

Since the concat will itself allocate a continuous chunk of memory to store the result, which will not have any overlap with source. The data in source will be copied to concat but not moved.

What Every Programmer Should Know About Compiler Optimizations--Hadi Brais

By Adrien Hamelin | Feb 4, 2015 02:08 PM | Tags: performance intermediate

Everything is in the title:

What Every Programmer Should Know About Compiler Optimizations

by Hadi Brais

From the article:

High-level programming languages offer many abstract programming constructs such as functions, conditional statements and loops that make us amazingly productive. However, one disadvantage of writing code in a high-level programming language is the potentially significant decrease in performance. Ideally, you should write understandable, maintainable code—without compromising performance. For this reason, compilers attempt to automatically optimize the code to improve its performance, and they’ve become quite sophisticated in doing so nowadays. They can transform loops, conditional statements, and recursive functions; eliminate whole blocks of code; and take advantage of the target instruction set architecture (ISA) to make the code fast and compact. It’s much better to focus on writing understandable code, than making manual optimizations that result in cryptic, hard-to-maintain code. In fact, manually optimizing the code might prevent the compiler from performing additional or more efficient optimizations...

CppCon 2014 Back to the Basics! Essentials of Modern C++ Style--Herb Sutter

By Adrien Hamelin | Feb 4, 2015 08:00 AM | Tags: intermediate c++14 c++11

While we wait for CppCon 2015 in September, we’re featuring videos of some of the 100+ talks from CppCon 2014. Here is today’s feature:

Back to the Basics! Essentials of Modern C++ Style

by Herb Sutter

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

This talk revisits basic questions, such as how to declare and initialize a variable, how to pass a value to a function, how to write a simple loop, and how to use smart pointers, in the light of experience with C++11 and the latest C++14 refinements. This involves examining auto, rvalue references, range-for loops, uniform initialization, lambda expressions, unique_ptr and shared_ptr, and more.