c++ - What changes introduced in C++14 can potentially break a program written in C++11? -
introduction
with c++14 (aka. c++1y) standard in state close being final, programmers must ask backwards compatibility, , issues related such.
the question
in answers of this question stated standard has appendix dedicated information regarding changes between revisions.
it helpful if these potential issues in mentioned appendix explained, perhaps of formal documents related mentioned there.
- according standard: changes introduced in c++14 can potentially break program written in c++11?
note: in post consider "breaking change" either, or both, of;
1. change make legal c++11 ill-formed when compiled c++14, and;
2. change change runtime behavior when compiled c++14, vs c++11.
c++11 vs c++14, standard say?
the standard draft (n3797) has section dedicated kind of information, describes (potentially breaking) differences between 1 revision of standard, , another.
this post has used section, [diff.cpp11]
, base semi-elaborate discussion regarding changes affect code written c++11, compiled c++14.
c.3.1] digit separators
the digit separator introduced 1 could, in more readable manner, write numeric literals , split them in way more natural way.
int x = 10000000; // (1) int y = 10'000'000; // (2), c++14
it's easy see (2) easier read (1) in above snippet, while both initializers have same value.
the potential issue regarding feature single-quote denoted start/end of character-literal in c++11, in c++14 single-quote can either surrounding character-literal, or used in shown manner (2).
example snippet, legal in both c++11 , c++14, different behavior.
#define m(x, ...) __va_args__ int a[] = { m(1'2, 3'4, 5) }; // int a[] = { 5 }; <-- c++11 // int a[] = { 3'4, 5 }; <-- c++14 // ^-- semantically equivalent `{ 34, 5 }`
( note: more information regarding single-quotes digit separators can found in n3781.pdf )
c.3.2] sized deallocation
c++14 introduces opportunity declare global overload of operator delete
suitable sized deallocation, wasn't possible in c++11.
however, standard mandates developer cannot declare 1 of 2 related functions below, must declare either none, or both; stated in [new.delete.single]p11.
void operator delete (void*) noexcept; void operator delete (void*, std::size_t) noexcept; // sized deallocation
further information regarding potential problem:
existing programs redefine global unsized version not define sized version. when implementation introduces sized version, replacement incomplete , programs call implementation-provided sized deallocator on objects allocated programmer-provided allocator.
note: quote taken n3536 - c++ sized deallocation
( note: more of interest available in paper titled n3536 - c++ sized deallocation, written lawrence crowl )
c.3.3] constexpr
member-functions, no longer implicitly const
there many changes constexpr in c++14, change change semantics between c++11, , c++14 constantness of member-function marked constexpr.
the rationale behind change allow constexpr member-functions mutate object belong, allowed due relaxation of constexpr.
struct { constexpr int func (); }; // struct { constexpr int func () const; }; <-- c++11 // struct { constexpr int func (); }; <-- c++14
recommended material on change, , why important enough introduce potential code-breakage:
- andrzej's c++ blog - “constexpr” function not “const”
- open-std.org - constexpr member functions , implicit const
- (open-std.org - relaxing constraints on constexpr functions)
example snippet, legal in both c++11 , c++14, different behavior
struct obj { constexpr int func (int) { return 1; } constexpr int func (float) const { return 2; } };
obj const = {}; int const x = a.func (123); // int const x = 1; <-- c++11 // int const x = 2; <-- c++14
c.3.4] removal of std::gets
std::gets
has been removed standard library because considered dangerous.
the implications of of course trying compile code written c++11, in c++14, such function used fail compile.
( note: there ways of writing code doesn't fail compile, , have different behavior, depends on removal of std::gets
standard library )
Comments
Post a Comment