Một số trường hợp phổ biến mà thứ tự đánh giá cho đến nay vẫn chưa được xác định , được chỉ định và hợp lệ với C++17. Thay vào đó, một số hành vi không xác định được chuyển thành không xác định.
i = 1;
f(i++, i)
là không xác định, nhưng bây giờ nó không được xác định. Cụ thể, những gì không được chỉ định là thứ tự mà mỗi đối số fđược đánh giá so với các đối số khác. i++có thể được đánh giá trước đó ihoặc ngược lại. Thật vậy, nó có thể đánh giá cuộc gọi thứ hai theo một thứ tự khác, mặc dù nằm trong cùng một trình biên dịch.
Tuy nhiên, việc đánh giá mỗi đối số được yêu cầu thực thi hoàn toàn, với tất cả các tác dụng phụ, trước khi thực thi bất kỳ đối số nào khác. Vì vậy, bạn có thể nhận được f(1, 1)(đối số thứ hai được đánh giá đầu tiên) hoặc f(1, 2)(đối số thứ nhất được đánh giá trước). Nhưng bạn sẽ không bao giờ có được f(2, 2)hoặc bất cứ thứ gì khác có tính chất đó.
std::cout << f() << f() << f();
là không xác định, nhưng nó sẽ trở nên tương thích với ưu tiên của toán tử để đánh giá đầu tiên của fsẽ xuất hiện đầu tiên trong luồng (ví dụ bên dưới).
f(g(), h(), j());
vẫn có thứ tự đánh giá không xác định của g, h và j. Lưu ý rằng đối với getf()(g(),h(),j()), trạng thái quy tắc getf()sẽ được đánh giá trước đó g, h, j.
Cũng lưu ý ví dụ sau từ văn bản đề xuất:
std::string s = "but I have heard it works even if you don't believe in it"
s.replace(0, 4, "").replace(s.find("even"), 4, "only")
.replace(s.find(" don't"), 6, "");
Ví dụ đến từ Ngôn ngữ lập trình C ++ , phiên bản thứ 4, Stroustrup, và được sử dụng là hành vi không xác định, nhưng với C ++ 17, nó sẽ hoạt động như mong đợi. Có những vấn đề tương tự với các hàm có thể tiếp tục lại ( .then( . . . )).
Như một ví dụ khác, hãy xem xét những điều sau:
#include <iostream>
#include <string>
#include <vector>
#include <cassert>
struct Speaker{
int i =0;
Speaker(std::vector<std::string> words) :words(words) {}
std::vector<std::string> words;
std::string operator()(){
assert(words.size()>0);
if(i==words.size()) i=0;
auto word = words[i] + (i+1==words.size()?"\n":",");
++i;
return word;
}
};
int main() {
auto spk = Speaker{{"All", "Work", "and", "no", "play"}};
std::cout << spk() << spk() << spk() << spk() << spk() ;
}
Với C ++ 14 trở về trước, chúng tôi có thể (và sẽ) nhận được các kết quả như
play
no,and,Work,All,
thay vì
All,work,and,no,play
Lưu ý rằng những điều trên có hiệu lực giống như
(((((std::cout << spk()) << spk()) << spk()) << spk()) << spk()) ;
Tuy nhiên, trước C ++ 17, không có gì đảm bảo rằng các lệnh gọi đầu tiên sẽ xuất hiện trước trong luồng.
Tài liệu tham khảo: Từ đề xuất được chấp nhận :
Biểu thức hậu tố được đánh giá từ trái sang phải. Điều này bao gồm các lệnh gọi hàm và biểu thức lựa chọn thành viên.
Biểu thức gán được đánh giá từ phải sang trái. Điều này bao gồm các bài tập ghép.
Toán hạng để dịch chuyển toán tử được đánh giá từ trái sang phải. Tóm lại, các biểu thức sau được đánh giá theo thứ tự a, sau đó b, sau đó c, sau đó d:
- ab
- a-> b
- a -> * b
- a (b1, b2, b3)
- b @ = a
- a [b]
- a << b
- a >> b
Hơn nữa, chúng tôi đề xuất quy tắc bổ sung sau: thứ tự đánh giá biểu thức liên quan đến toán tử nạp chồng được xác định bởi thứ tự được liên kết với toán tử tích hợp tương ứng, không phải quy tắc cho lời gọi hàm.
Chỉnh sửa ghi chú: Câu trả lời ban đầu của tôi bị hiểu sai a(b1, b2, b3). Trình tự b1, b2, b3vẫn còn chưa được xác định. (cảm ơn @KABoissonneault, tất cả những người bình luận.)
Tuy nhiên, (như @Yakk chỉ ra) và điều này là rất quan trọng: Ngay cả khi b1, b2, b3là những biểu hiện không tầm thường, mỗi người trong số họ hoàn toàn đánh giá và gắn liền với tham số chức năng tương ứng trước khi những người khác đang bắt đầu được đánh giá. Tiêu chuẩn nói rõ như thế này:
§5.2.2 - Lệnh gọi hàm 5.2.2.4:
. . . Biểu thức hậu tố được sắp xếp theo thứ tự trước mỗi biểu thức trong danh sách biểu thức và bất kỳ đối số mặc định nào. Mọi phép tính giá trị và hiệu ứng phụ liên quan đến việc khởi tạo một tham số và chính quá trình khởi tạo, đều được giải trình tự trước mọi phép tính giá trị và hiệu ứng phụ liên quan đến việc khởi tạo bất kỳ tham số tiếp theo nào.
Tuy nhiên, một trong những câu mới này bị thiếu trong bản nháp GitHub :
Mọi phép tính giá trị và hiệu ứng phụ liên quan đến việc khởi tạo một tham số và chính quá trình khởi tạo, đều được giải trình tự trước mọi phép tính giá trị và hiệu ứng phụ liên quan đến việc khởi tạo bất kỳ tham số tiếp theo nào.
Ví dụ là ở đó. Nó giải quyết các vấn đề đã tồn tại hàng thập kỷ ( theo giải thích của Herb Sutter ) với sự an toàn ngoại lệ ở những nơi như
f(std::unique_ptr<A> a, std::unique_ptr<B> b);
f(get_raw_a(), get_raw_a());
sẽ bị rò rỉ nếu một trong các lệnh gọi xuất hiện get_raw_a()trước khi con trỏ thô khác được gắn với tham số con trỏ thông minh của nó.
Như đã chỉ ra bởi TC, ví dụ này có sai sót vì cấu trúc unique_ptr từ con trỏ thô là rõ ràng, ngăn điều này biên dịch. *
Cũng lưu ý câu hỏi cổ điển này (được gắn thẻ C , không phải C ++ ):
int x=0;
x++ + ++x;
vẫn chưa được xác định.