Bjarne Stroustrup receives Draper Prize, engineering's top U.S. honor

By Blog Staff | Feb 22, 2018 09:48 AM | Tags: None

A few months ago, Bjarne Stroustrup received one of the most distinguished engineering prizes in the world: the Faraday medal.

Last night, the U.S. National Academy of Engineering (NAE) presented Stroustrup with the United States' top engineering honor, the Charles Stark Draper Prize, for his work designing and implementing the C++ programming language. (Note: This is the second Draper prize awarded for a programming language; the first was to John Backus for Fortran, awarded in 1993.)

Please join us in congratulatating Dr. Stroustrup! He is the reason we are all here, and able to do what we do every day as C++ developers.

From the announcement:

Stroustrup’s development of C++ has helped bridge the gap between a problem and its computing elements through the use of visualization for engineers and members of varying disciplines, such as biologists, medical doctors, mathematicians, economists and politicians.

Stroustrup, a visiting professor in computer science at Columbia University, was elected to the National Academy of Engineering in 2004. He is a fellow of IEEE, the Association of Computing Machinery, the Computer History Museum and Churchill College, Cambridge, and is managing director in the technology division of Morgan Stanley in New York City.

The Charles Stark Draper Prize is a $500,000 biannual award that honors engineers whose accomplishments have significantly benefited society. It is considered the Nobel Prize of engineering.

C++ revolutionized the software industry by enabling a variety of software development techniques, including object-oriented programming, generic programming and general resource management, to be deployed at industrial scale. According to industry analysts, C++ is one of the most widely used programming languages in the world, with applications in communications, computer graphics, games, user interfaces, embedded systems, financial systems, medical systems, avionics, scientific computation and many other areas.

Batteries not included: what should go in the C++ standard library?

By Guy | Feb 21, 2018 09:44 AM | Tags: None

With the next standardisation meeting coming up, now is a good time to consider what the limits of the standard library should be. 

Batteries not included: what should go in the C++ standard library?

By Guy Davidson

From the article:

About forty Christmases ago I was absolutely delighted to open a slot car racing set from my parents. I feverishly set everything up, created a track reminiscent of Brands Hatch, and went to plug everything in, only to discover that I needed batteries to operate the controllers. This was Great Britain in the 1970s...

Quick Q: How can a class template store either reference or value?

By Adrien Hamelin | Feb 20, 2018 08:48 AM | Tags: advanced

Quick A: This happen by default.

Recently on SO:

How can a class template store either reference or value?

You already wrote it (minus the required template <typename T>). The deduction rules for a forwarding reference preserve value category as follows:

1. If t is bound to an lvalue of type T2, then T = T2&.
2. If t is bound to an rvalue of type T2, then T = T2.

It's those deduction rules that std::forward relies on to do its job. And why we need to pass the type to it as well.

The above means that you instantiate holder directly with T2 in the rvalue case. Giving you exactly what you want. A copy is made.

As a matter of fact, two copies are made. Once to create the constructor argument t, and the other copy is to initialize obj_m from it. But we can get rid of it with some clever use of type_traits:

template <class T>
class holder {
    T  obj_m;  // should be a reference if possible...
public:
    holder(std::add_rvalue_reference_t<T> t) :obj_m { std::forward<T>(t) } {}
};

template<typename T>
auto hold_this(T && t) { return holder<T>(std::forward<T>(t)); }

See it live. We use add_rvalue_reference_t to make t be of the correct reference type in each case. And "simulate" the argument deduction which would make obj_m { std::forward<T>(t) } resolve to initializing obj_m from the correct reference type.

I say "simulate" because it's important to understand the constructor argument for holder cannot be a forwarding reference because the constructor itself is not templated.

By the way, since you tagged c++17, we can also add a deduction guide to your example. If we define it as follows (with the feedback from T.C. incorporated):

template <class T>
class holder {
    T  obj_m;  // should be a reference if possible...
public:
    holder(T&& t) :obj_m { std::forward<T>(t) } {}
};

template<typename T>
holder(T&&) -> holder<T>;

Then this live example shows you can define variables as hold h1{t}; and hold h2{test()};, with the same deduced types as the function return values from before.

Quick Q: In C++ are static member functions inherited? If yes why ambiguity error does not arise?

By Adrien Hamelin | Feb 20, 2018 08:44 AM | Tags: intermediate

Quick A: Yes, and there are no ambiguity with static members.

Recently on SO:

In C++ are static member functions inherited? If yes why ambiguity error does not arise?

It's fine according to the lookup rules. You see, when you write member access (obj.display();), the member display is looked up not just in the scope of the class and its base classes. Base class sub-objects are taken into consideration as well.

If the member being looked up is not static, since base class sub-objects are part of the consideration, and you have two sub-objects of the same type, there's an ambiguity in the lookup.

But when they are static, there is no ambiguity. And to make it perfectly clear, the C++ standard even has a (non-normative) example when it describes class member lookup (in the section [class.member.lookup])

Quick Q: Most concise way to disable copy and move semantics

By Adrien Hamelin | Feb 20, 2018 08:40 AM | Tags: c++11 advanced

Quick A: Delete the move assignment.

Recently on SO:

Most concise way to disable copy and move semantics

According to this chart (by Howard Hinnant):

The most concise way is to =delete move assignment operator (or move constructor, but it can cause problems mentioned in comments).

Though, in my opinion the most readable way is to =delete both copy constructor and copy assignment operator.

Quick Q: Vector going out of bounds without giving error

By Adrien Hamelin | Feb 14, 2018 10:16 PM | Tags: basics

Quick A: Welcome to undefined behaviour.

Recently on SO:

Vector going out of bounds without giving error

STL vectors perform bounds checking when the .at() member function is called, but do not perform any checks on the [] operator.

When out of bounds, the [] operator produces undefined results.

Factory With Self-Registering Types -- Bartlomiej Filipek

By bfilipek | Feb 14, 2018 07:20 AM | Tags: None

Let’s see how classes can register themselves in a factory and what are the examples where it’s used.

Factory With Self-Registering Types

by Bartlomiej Filipek

From the article:

In this post, I’ve covered a type of factory where types register themselves. It’s an opposite way of simple factories where all the types are declared upfront. Such approach gives more flexibility and removes dependency on the exact list of supported classes from the factory.

Read-Compile-Run-Loop - a tiny embeddable REPL analog for C++ -- Viktor Kirilov

By onqtam | Feb 13, 2018 09:42 AM | Tags: None

Most scripting languages have REPLs (read-eval-print-loop) - an interactive console.

Read-Compile-Run-Loop - a tiny embeddable REPL analog for C++

by Viktor Kirilov

From the article:

Ever wanted to modify some value or execute some (complex) statement while your C++ program is running just to test something out? Something that cannot be done through the debugger or wouldn’t be trivial? Scripting languages have REPLs and it's time for C++ to get one too.

To RAII or Not to RAII?--Jonathan Boccara

By Adrien Hamelin | Feb 12, 2018 10:55 PM | Tags: intermediate

Good question.

To RAII or Not to RAII?

by Jonathan Boccara

From the article:

RAII is a central concept in C++, that consists in relying on the compiler to call destructors automatically in certain cases. Putting appropriate code in such destructors then relieves us from calling that code – the compiler does it for us.

RAII is an idiomatic technique of C++, but can we use RAII for everything? Is it a good idea to shift every possible piece of code to the destructor of some class, to leave the work to the compiler and make calling code as light as can be?

Since this question comes down to asking if the proverbial hammer is a tool fit for every single task, the answer to that question is probably the proverbial No.

But then, in which cases would RAII improve the design of a piece of code?

In this article we’ll see a case where RAII is adapted, then a case where RAII is NOT adapted. And after that we’ll see a case open to discussion. We’ll then conclude with how to use levels of abstractions to make the decision to RAII or not to RAII...

Overload 143 is now available

By Adrien Hamelin | Feb 12, 2018 10:49 PM | Tags: community

ACCU’s Overload journal of February 2018 is out. It contains the following C++ related articles.

Overload 143 is now available

From the journal:

Hapaxes, Singletons and Anomalies
Programmers can be odd. Frances Buontempo celebrates many manifold peculiarities. by Frances Buontempo

A Wider Vision of Software Development
Is code a hopeful arrangement of bytes? Charles Tolman brings his Organising Principles series to a close. by Charles Tolman

An MWSR Queue with Minimalist Locking
Multithreaded queues come in many flavours. Sergey Ignatchenko describes his implementation of a multiple writer single reader queue. by Sergey Ignatchenko

Testing: Choose the Right Level
Testing can be easy. Andy Balaam considers levels to keep your focus just right. by Andy Balaam

CTAD – What Is This New Acronym All About?
What is class template argument deduction? Roger Orr elucidates this new C++17 feature. by Roger Orr

C++ with Meta-classes?
Meta-classes will allow us to detail class requirements. Francis Glassborow compares them to developments of C++ in the 1990s. by Francis Glassborow

Practical Scale Testing
Everyone wants scalable systems. Arun Saha explores methods for testing scalability. by Arun Saha

Functional Error-Handling with Optional and Expected
Exceptions should be exceptional. Simon Brand shows modern alternatives from the standard library and ways to improve them. by Simon Brand