Home » Blog » 2014 » November

November 2014

C++14 for Qt programmers -- Olivier Goffart

By Blog Staff | Nov 21, 2014 09:12 AM | Tags: None

For those who know how to pronounce Qt, note that this title is not intended as a beauty judgment:

C++14 for Qt programmers

by Olivier Goffart

From the article:

C++14 is the name of the version of the standard to be released this year. While C++11 has brought many more feature that took time to be implemented by the compilers, C++14 is a much lighter change that is already implemented by compilers such as clang or gcc.

Qt 5 already was adapted in many ways so you can make use of the new features of C++11. You can read about that in my previous article. C++11 in Qt5. This article mention some of the changes in C++14 and the impact on Qt users...

N4320: Make exception specifications be part of the type system -- Jens Maurer

By Blog Staff | Nov 21, 2014 09:04 AM | Tags: None

New WG21 papers are available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4320

Date: 2014-11-20

Make exception specifications be part of the type system

by Jens Maurer

Excerpt:

The exception specification of a function was never considered a part of its type. Instead, 15.4 [except.spec] paragraphs 5 and 6 only restrict assignments and initializations of pointers and references to (member) functions. This leads to odd holes in the type system that have resulted in a number of core issues. ... The recent work on a specification for transactional memory support (see N4265 "Transactional Memory Support for C++: Wording (revision 3)") required integrating the transaction_safe specifier into the types of functions, among other things considering it for implicit conversions and overload resolution. This paper clones that approach to integrate the presence or absence of a non-throwing exception-specification (called noexcept) into the types of functions, too.

Quick Q: Is it idiomatic to make X objects immutable by making all X member data const? -- SO

By Blog Staff | Nov 21, 2014 04:31 AM | Tags: None

Quick A: Yes.

Recently on SO:

Idiomatic way to declare C++ immutable classes

So I have some pretty extensive functional code where the main data type is immutable structs/classes. The way I have been declaring immutability is "practically immutable" by making member variables and any methods const.

struct RockSolid {
   const float x;
   const float y;
   float MakeHarderConcrete() const { return x + y; }
}

Is this actually the way "we should do it" in C++? Or is there a better way?

N4318: Proposal to add an absolute difference function to the C++ Standard Library -- J. Turnbull

By Blog Staff | Nov 20, 2014 02:16 PM | Tags: None

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4318

Date: 2014-09-21

Proposal to add an absolute difference function to the C++ Standard Library

by Jeremy Turnbull

Excerpt:

This document proposes the addition of the abs_diff() template function to the C++ Standard Library. This function computes the absolute difference between two parameters of a type that supports the operator<() and operator-() functions, or other functions of equivalent logic, without computing a logically negative value during function execution.

N4274: Relaxing Packaging Rules for Exceptions... Proposed Wording (Revision 1) -- A. Robison et al.

By Blog Staff | Nov 20, 2014 02:13 PM | Tags: None

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4274

Date: 2014-11-14

Relaxing Packaging Rules for Exceptions Thrown by Parallel Algorithms - Proposed Wording (Revision 1)

by Arch D. Robison, Jared Hoberock, Artur Laksberg

Excerpt:

N4157 described the rationale for changing a future revision of N4105 to relax exception packaging rules. Speci cally, the change permits an implementation to throw an exception that is not an exception_list if only one invocation of an element access function throws an exception. Unfortunately, the proposed wording in N4157 did not completely fix the problem. This document proposes new rewording.