(Tôi đang tìm một hoặc hai ví dụ để chứng minh quan điểm, không phải một danh sách.)

Đã bao giờ có trường hợp thay đổi trong tiêu chuẩn C ++ (ví dụ: từ 98 thành 11, 11 thành 14, v.v.) đã thay đổi hành vi của mã người dùng hiện có, được định dạng tốt, có hành vi xác định - một cách âm thầm chưa? tức là không có cảnh báo hoặc lỗi khi biên dịch với phiên bản tiêu chuẩn mới hơn?

Ghi chú:

• Tôi đang hỏi về hành vi bắt buộc theo tiêu chuẩn, không phải về lựa chọn tác giả trình thực hiện / trình biên dịch.
• Mã càng ít nội dung càng tốt (như một câu trả lời cho câu hỏi này).
• Ý tôi không phải là mã có phát hiện phiên bản chẳng hạn như #if __cplusplus >= 201103L.
• Các câu trả lời liên quan đến mô hình bộ nhớ là tốt.

Kiểu trả về string::datathay đổi từ const char*thành char*trong C ++ 17. Điều đó chắc chắn có thể tạo ra sự khác biệt

void func(char* data)
{
    cout << data << " is not const\n";
}

void func(const char* data)
{
    cout << data << " is const\n";
}

int main()
{
    string s = "xyz";
    func(s.data());
}

Có một chút giả thiết nhưng chương trình hợp pháp này sẽ thay đổi đầu ra của nó từ C ++ 14 thành C ++ 17.

Câu trả lời cho câu hỏi này cho thấy cách khởi tạo một vectơ bằng cách sử dụng một size_typegiá trị duy nhất có thể dẫn đến hành vi khác nhau giữa C ++ 03 và C ++ 11.

std::vector<Something> s(10);

C ++ 03 mặc định-xây dựng một đối tượng tạm thời của loại phần tử Somethingvà sao chép-xây dựng từng phần tử trong vectơ từ tạm thời đó.

C ++ 11 mặc định-xây dựng từng phần tử trong vector.

Trong nhiều (hầu hết?) Trường hợp này dẫn đến trạng thái cuối cùng tương đương, nhưng không có lý do gì chúng phải làm như vậy. Nó phụ thuộc vào việc triển khai các hàm tạo Somethingmặc định / sao chép.

Xem ví dụ giả tạo này :

class Something {
private:
    static int counter;

public:
    Something() : v(counter++) {
        std::cout << "default " << v << '\n';
    }

    Something(Something const & other) : v(counter++) {
        std::cout << "copy " << other.v << " to " << v << '\n';
    }

    ~Something() {
        std::cout << "dtor " << v << '\n';
    }

private:
    int v;
};

int Something::counter = 0;

C ++ 03 sẽ mặc định-xây dựng một Somethingvới v == 0sau đó sao chép-xây dựng thêm mười từ cái đó. Ở cuối, vectơ chứa mười đối tượng có vgiá trị từ 1 đến 10, bao gồm cả.

C ++ 11 sẽ xây dựng mặc định từng phần tử. Không có bản sao nào được thực hiện. Ở cuối, vectơ chứa mười đối tượng có vgiá trị từ 0 đến 9, bao gồm cả.

Tiêu chuẩn có một danh sách các thay đổi đột phá trong Phụ lục C [khác] . Nhiều thay đổi này có thể dẫn đến thay đổi hành vi thầm lặng.

Một ví dụ:

int f(const char*); // #1
int f(bool);        // #2

int x = f(u8"foo"); // until C++20: calls #1; since C++20: calls #2

Mỗi khi họ thêm các phương thức mới (và thường là các hàm) vào thư viện chuẩn, điều này sẽ xảy ra.

Giả sử bạn có một loại thư viện chuẩn:

struct example {
  void do_stuff() const;
};

khá đơn giản. Trong một số bản sửa đổi tiêu chuẩn, một phương thức mới hoặc quá tải hoặc bên cạnh bất kỳ thứ gì được thêm vào:

struct example {
  void do_stuff() const;
  void method(); // a new method
};

điều này có thể âm thầm thay đổi hành vi của các chương trình C ++ hiện có.

Điều này là do khả năng phản chiếu hạn chế hiện tại của C ++ đủ để phát hiện ra phương thức như vậy có tồn tại hay không và chạy mã khác dựa trên nó.

template<class T, class=void>
struct detect_new_method : std::false_type {};

template<class T>
struct detect_new_method< T, std::void_t< decltype( &T::method ) > > : std::true_type {};

đây chỉ là một cách tương đối đơn giản để phát hiện cái mới method, có vô số cách.

void task( std::false_type ) {
  std::cout << "old code";
};
void task( std::true_type ) {
  std::cout << "new code";
};

int main() {
  task( detect_new_method<example>{} );
}

Điều tương tự cũng có thể xảy ra khi bạn xóa các phương thức khỏi các lớp.

Trong khi ví dụ này trực tiếp phát hiện ra sự tồn tại của một phương thức, thì kiểu điều này xảy ra gián tiếp có thể ít giả thiết hơn. Ví dụ cụ thể, bạn có thể có một công cụ tuần tự hóa quyết định xem thứ gì đó có thể được tuần tự hóa dưới dạng một vùng chứa hay không dựa trên việc liệu nó có thể lặp lại được hay không, hoặc nếu nó có một dữ liệu trỏ đến raw-byte và một thành viên kích thước, với một ưu tiên hơn cai khac.

Tiêu chuẩn đi và thêm một .data()phương thức vào một vùng chứa, và đột nhiên kiểu thay đổi đường dẫn mà nó sử dụng để tuần tự hóa.

Tất cả những gì tiêu chuẩn C ++ có thể làm, nếu nó không muốn bị đóng băng, là làm cho loại mã bị ngắt âm thầm trở nên hiếm hoặc bằng cách nào đó không hợp lý.

Oh boy ... Các liên kết cpplearner cung cấp là đáng sợ .

Trong số những người khác, C ++ 20 không cho phép khai báo cấu trúc kiểu C của cấu trúc C ++.

typedef struct
{
  void member_foo(); // Ill-formed since C++20
} m_struct;

Nếu bạn được dạy cách viết các cấu trúc như thế (và những người dạy "C với các lớp học" dạy chính xác điều đó) thì bạn đã bị hỏng .

Đây là một ví dụ in 3 trong C ++ 03 nhưng 0 trong C ++ 11:

template<int I> struct X   { static int const c = 2; };
template<> struct X<0>     { typedef int c; };
template<class T> struct Y { static int const c = 3; };
static int const c = 4;
int main() { std::cout << (Y<X< 1>>::c >::c>::c) << '\n'; }

Sự thay đổi hành vi này là do xử lý đặc biệt cho >>. Trước C ++ 11, >>luôn là toán tử dịch đúng. Với C ++ 11, >>cũng có thể là một phần của khai báo mẫu.

Các đoạn đã giảm

Tệp nguồn được mã hóa trong một tập ký tự vật lý được ánh xạ theo cách được triển khai xác định với tập ký tự nguồn , được định nghĩa trong tiêu chuẩn. Để phù hợp với các ánh xạ từ một số bộ ký tự vật lý vốn dĩ không có tất cả các dấu câu cần thiết cho bộ ký tự nguồn, các đoạn văn được xác định theo ngôn ngữ — chuỗi gồm ba ký tự phổ biến có thể được sử dụng thay cho một ký tự dấu câu ít phổ biến hơn. Bộ tiền xử lý và trình biên dịch được yêu cầu để xử lý những điều này.

Trong C ++ 17, các đồ thị đã bị loại bỏ. Vì vậy, một số tệp nguồn sẽ không được chấp nhận bởi các trình biên dịch mới hơn trừ khi chúng được dịch lần đầu tiên từ bộ ký tự vật lý sang một số bộ ký tự vật lý khác ánh xạ 1-1 sang bộ ký tự nguồn. (Trong thực tế, hầu hết các trình biên dịch chỉ thực hiện việc giải thích các đoạn văn là tùy chọn.) Đây không phải là một thay đổi hành vi tinh tế, mà là một thay đổi đột phá ngăn không cho các tệp nguồn được chấp nhận trước đó được biên dịch mà không cần quá trình dịch bên ngoài.

Nhiều ràng buộc hơn về char

Tiêu chuẩn cũng đề cập đến bộ ký tự thực thi , được xác định việc triển khai, nhưng phải chứa ít nhất toàn bộ bộ ký tự nguồn cộng với một số lượng nhỏ mã điều khiển.

Tiêu chuẩn C ++ được định nghĩa charlà một kiểu tích phân có thể không dấu có thể biểu diễn hiệu quả mọi giá trị trong bộ ký tự thực thi. Với sự trình bày từ một luật sư ngôn ngữ, bạn có thể lập luận rằng a charphải có ít nhất 8 bit.

Nếu việc triển khai của bạn sử dụng giá trị không được đánh dấu cho char, thì bạn biết nó có thể nằm trong khoảng từ 0 đến 255 và do đó phù hợp để lưu trữ mọi giá trị byte có thể có.

Nhưng nếu triển khai của bạn sử dụng giá trị đã ký, thì nó có các tùy chọn.

Hầu hết sẽ sử dụng phần bù của hai, cho charmột phạm vi tối thiểu từ -128 đến 127. Đó là 256 giá trị duy nhất.

Nhưng một tùy chọn khác là dấu + độ lớn, trong đó một bit được dành riêng để cho biết liệu số có âm hay không và bảy bit còn lại biểu thị độ lớn. Điều đó sẽ cung cấp charmột phạm vi từ -127 đến 127, chỉ là 255 giá trị duy nhất. (Bởi vì bạn mất một tổ hợp bit hữu ích để biểu diễn -0.)

Tôi không chắc ủy ban đã bao giờ chỉ định rõ ràng đây là một khiếm khuyết, nhưng đó là vì bạn không thể dựa vào tiêu chuẩn để đảm bảo một chuyến khứ hồi từ unsigned charđi charvà về sẽ giữ nguyên giá trị ban đầu. (Trong thực tế, tất cả các triển khai đều như vậy vì chúng đều sử dụng phần bù của hai cho các loại tích phân có dấu.)

Chỉ gần đây (C ++ 17?) Mới được sửa lại từ ngữ để đảm bảo sự thành thạo. Bản sửa lỗi đó, cùng với tất cả các yêu cầu khác trên char, bắt buộc một cách hiệu quả phần bù của hai cho charcó dấu mà không cần nói rõ ràng như vậy (ngay cả khi tiêu chuẩn tiếp tục cho phép biểu diễn dấu + độ lớn cho các loại tích phân có dấu khác). Có một đề xuất yêu cầu tất cả các kiểu tích phân có dấu sử dụng phần bù của hai, nhưng tôi không nhớ liệu nó có được đưa vào C ++ 20 hay không.

Vì vậy, điều này tương tự như những gì bạn đang tìm kiếm bởi vì nó cung cấp cho mã quá tự tin không chính xác trước đó một bản sửa lỗi có hiệu lực trở lại.

Tôi không chắc liệu bạn có coi đây là một thay đổi vi phạm để sửa mã hay không, nhưng ...

Trước C ++ 11, các trình biên dịch được phép, nhưng không bắt buộc, để xử lý các bản sao trong một số trường hợp nhất định, ngay cả khi trình tạo bản sao có các tác dụng phụ có thể quan sát được. Bây giờ chúng tôi đã đảm bảo tách bản sao. Hành vi về cơ bản đi từ việc triển khai được xác định đến bắt buộc.

Điều này có nghĩa là các tác dụng phụ của hàm tạo bản sao của bạn có thể đã xảy ra với các phiên bản cũ hơn, nhưng sẽ không bao giờ xảy ra với các phiên bản mới hơn. Bạn có thể tranh luận rằng mã đúng không nên dựa vào kết quả do triển khai xác định, nhưng tôi không nghĩ rằng điều đó hoàn toàn giống với việc nói mã như vậy là không chính xác.

Hành vi khi đọc dữ liệu (số) từ một luồng và đọc không thành công, đã được thay đổi kể từ c ++ 11.

Ví dụ: đọc một số nguyên từ một luồng, trong khi nó không chứa một số nguyên:

#include <iostream>
#include <sstream>

int main(int, char **) 
{
    int a = 12345;
    std::string s = "abcd";         // not an integer, so will fail
    std::stringstream ss(s);
    ss >> a;
    std::cout << "fail = " << ss.fail() << " a = " << a << std::endl;        // since c++11: a == 0, before a still 12345 
}

Vì c ++ 11 sẽ đặt số nguyên đọc thành 0 khi nó bị lỗi; tại c ++ <11 số nguyên không bị thay đổi. Điều đó nói rằng, gcc, ngay cả khi buộc tiêu chuẩn trở lại c ++ 98 (với -std = c ++ 98) luôn hiển thị hành vi mới ít nhất kể từ phiên bản 4.4.7.

(Imho hành vi cũ thực sự tốt hơn: tại sao lại thay đổi giá trị thành 0, tự nó là hợp lệ, khi không thể đọc được gì?)

Tham khảo: xem https://en.cppreference.com/w/cpp/locale/num_get/get