At this time, innovations are much smaller than in the first part. Still, C ++ 14 is considered a minor release, aimed more at eliminating the shortcomings of C ++ 11, rather than introducing new features.
Short list:
- Freeing memory of a certain size
- Single quote as digital delimiter
- Attribute
[[deprecated]]
- Custom literals for
std::complex
- Filesystem API
- Convert network byte order
Overview of the new features of C ++ 14: Part 1Current draft standardChanges in the language itself
Freeing memory of a certain size
In C ++ 11, programmers can define a static method of class
operator delete
, which would accept as a parameter the size of the object being deleted. Now, the corresponding global operator
delete
been added to the standard. This change is designed to improve the performance of modern memory allocators.
')
The added operators have the following signatures:
void operator delete(void* ptr, std::size_t size) noexcept; void operator delete(void* ptr, std::size_t size, const std::nothrow_t&) noexcept; void operator delete[](void* ptr, std::size_t size) noexcept; void operator delete[](void* ptr, std::size_t size, const std::nothrow_t&) noexcept;
The main compatibility problem that has arisen here is the case when the new system and old user memory allocation libraries are used. In new programs, calls to an operator who does not accept the size will be directed to the user library, and calls with size to the system library. At the moment, the standard behavior of operators with size is a call to the corresponding operators without size, so there will be no problems yet, and users who want to get a boost in productivity will need to add the appropriate versions of the operators themselves. However, in future versions of the standard, it is planned to change this behavior. Thus, the committee gives programmers time to adapt their memory allocators to avoid unexpected problems.
Single quote as digital delimiter
Now you can use single quotes to isolate the orders of numbers. For example, the numbers
1048576
,
1'048'576
,
1'0'4'8'5'7'6
,
0X100000
,
0x10'0000
, and
0'004'000'000
have the same meaning.
However, this change leads to the following problems:
First, the behavior of the macro extension changes. For example:
#define M(x, ...) __VA_ARGS__ int x[2] = { M(1'2,3'4) };
And secondly, many editors and other utilities designed to highlight the syntax will now incorrectly parse the code. Even Habrahabr could not resist, compare:
int testing_habrahabr_syntax_highlighter = 1000;
int testing_habrahabr_syntax_highlighter = 1'000;
int testing_habrahabr_syntax_highlighter = 1'000'000;
int testing_habrahabr_syntax_highlighter = 1'0'0'0'0'0'0;
Attribute [[deprecated]]
In C ++ 11, the syntax for declaring attributes, previously known as __attribute__ for gcc / clang and __declspec for VC ++, was standardized. In C ++ 14, an attribute was added that allows you to mark any of the following tokens: class, variable, non-static class member, function, enumeration, template specialization or typedef - as obsolete, if for some reason their further use is undesirable. As a result, when the programmer uses tokens marked with this attribute, the compiler will issue a warning. The optional attribute parameter allows you to specify your additional message (for example, a suggestion about a suitable replacement), which will be displayed along with a compiler warning.
void foo(); [[deprecated("use 'foo' instead")]] void bar();
It is allowed to re-declare tokens with this attribute, if you, for example, want to prohibit your development team from using some functions from third-party libraries, however, you cannot remove the effect of this attribute by re-declaration.
#include <GL/gl.h> [[deprecated("use 'glDrawArrays' instead")]] void glBegin(GLenum);
At the discretion of the STL developers, all relevant tokens listed in Appendix D to the C ++ standard (Compatibility features) can be labeled with this attribute.
Changes in the standard library
Custom literals for std::complex
The following literals have been added to quickly create complex numbers consisting only of the imaginary part:
namespace std { inline namespace literals { inline namespace complex_literals { constexpr complex<long double> operator""il(long double); constexpr complex<long double> operator""il(unsigned long long); constexpr complex<double> operator""i(long double); constexpr complex<double> operator""i(unsigned long long); constexpr complex<float> operator""if(long double); constexpr complex<float> operator""if(unsigned long long); }}}
As a result, you can easily create complex numbers with familiar arithmetic operations:
using namespace std; complex<double> a = 1.5 + 0.3i; auto b = 2.3 - 0.2i;
Technical specifications

As shown in the image, until 2011, the committee used a “monolithic” model, where all new features fell into the only draft of the standard.
Starting from 2012, the committee moved to a more “distributed” model, where the main areas of development of the standard are carried out independently of the standard with its speed and can be released as soon as they are ready, without waiting for the main standard, in the form of technical specifications (TS), followed by merge with him after a while. This model allows the committee to present the work to the public in small pieces in a faster and more predictable way. This should also speed up the release of new versions of the standard itself.
A
draft technical specification of the API for working with the file system, based on Boost.Filesystem v3, including iteration over files and directories, has already been approved.
The following specifications are under active development:
- Networking TS. Currently contains:
- Functions for converting byte order between network (big-endian) and used on the local machine, based on the functions of the
htonl(), htons(), ntohl(), ntohs()
standard POSIX. Already approved by the committee. - API for working with URIs. Still awaiting committee approval.
- Library Fundamentals TS: Is a set of extensions to the main part of the standard library. Here
optional<>
and other fundamental utilities for revision were brought. - Array Extensions TS: Array language and library extensions.
dynarray<>
runtime-sized arrays
and dynarray<>
were brought here for refinement. - Concurrency TS: Initially includes support for executors and schedulers and non-blocking operations for
std::future
, such as .then()
and .when_*()
. Later, language extensions such as await
and library extensions such as parallel hash containers can be added here. - Extensions for parallelism: Initially includes a parallel STL library with support for parallel algorithms that use multiple processor cores, and vectorized (vectorizable) algorithms that use the full power of processor instruction sets.
All technical specifications use the
std::experimental
namespace.
Also, a group engaged in graphics has recently begun its work in order to standardize the “2D Lite” API for drawing. A brief discussion of graphics and C ++ can be found in the presentation of the Coat of Arms of Sutter with GoingNative2013, starting at 42:30
here .
Conclusion
The next meeting of the committee is scheduled for February 2014. After which we will get some semblance of the release of the candidate of the following - C ++ 14 standard, also known as C ++ 1y.
According to the latest data, Clang along with libc ++ in SVN already fully implement the current draft of the standard, GCC lags behind somewhat. You can verify this here:
Clang ,
libc ++ ,
GCC .
Overview of the new features of C ++ 14: Part 1Current draft standardPS swap
operator
Among all the other proposals for standardization, last spring there was a proposal to introduce a special exchange operator in C ++: =: to replace the function of the standard library
std::swap
. Then some took it as an April Fool's joke, but at the end of August the proposal was updated to version 2. I still don’t know the committee’s opinion about this operator, but it hasn’t yet been approved for standardization. Read more about it
here .