Thứ tự đánh giá các chỉ số mảng (so với biểu thức) trong C

Nhìn vào mã này:

static int global_var = 0;

int update_three(int val)
{
    global_var = val;
    return 3;
}

int main()
{
    int arr[5];
    arr[global_var] = update_three(2);
}

Những mảng nào được cập nhật? 0 hay 2?

Có một phần trong đặc tả của C chỉ ra mức độ ưu tiên của hoạt động trong trường hợp cụ thể này không?

Thứ tự các toán tử trái và phải

Để thực hiện gán trong arr[global_var] = update_three(2), việc thực hiện C phải đánh giá các toán hạng và, như một hiệu ứng phụ, cập nhật giá trị được lưu trữ của toán hạng bên trái. C 2018 6.5.16 (nói về bài tập) đoạn 3 cho chúng ta biết không có trình tự trong các toán hạng bên trái và bên phải:

Các đánh giá của toán hạng là không có kết quả.

Điều này có nghĩa là việc triển khai C được tự do tính toán giá trị arr[global_var] trước (bằng cách tính toán giá trị, chúng tôi có nghĩa là tìm ra biểu thức này đề cập đến điều gì), sau đó để đánh giá update_three(2)và cuối cùng là gán giá trị của giá trị sau cho giá trị trước; hoặc để đánh giá update_three(2)trước, sau đó tính toán giá trị, sau đó gán giá trị trước cho giá trị sau; hoặc để đánh giá giá trị và update_three(2)theo một số cách kết hợp và sau đó gán giá trị bên phải cho giá trị bên trái.

Trong mọi trường hợp, việc gán giá trị cho giá trị phải đến sau cùng, bởi vì 6.5.16 3 cũng cho biết:

Tác dụng phụ của việc cập nhật giá trị được lưu trữ của toán hạng bên trái được sắp xếp theo trình tự sau khi tính toán giá trị của toán hạng bên trái và bên phải

Vi phạm trình tự

Một số người có thể suy nghĩ về hành vi không xác định do cả việc sử dụng global_varvà cập nhật riêng nó vi phạm 6.5 2, cho biết:

Nếu một hiệu ứng phụ trên một đối tượng vô hướng không có kết quả tương ứng với một hiệu ứng phụ khác trên cùng một đối tượng vô hướng hoặc một tính toán giá trị sử dụng giá trị của cùng một đối tượng vô hướng, thì hành vi đó không được xác định

Một điều khá quen thuộc với nhiều học viên C là hành vi của các biểu thức như x + x++không được xác định bởi tiêu chuẩn C vì cả hai đều sử dụng giá trị xvà riêng biệt sửa đổi nó trong cùng một biểu thức mà không giải trình tự. Tuy nhiên, trong trường hợp này, chúng tôi có một lệnh gọi hàm, cung cấp một số trình tự. global_varđược sử dụng trong arr[global_var]và được cập nhật trong lệnh gọi hàm update_three(2).

6.5.2.2 10 cho chúng ta biết có một điểm thứ tự trước khi hàm được gọi:

Có một điểm thứ tự sau các đánh giá của người chỉ định hàm và các đối số thực tế nhưng trước lệnh gọi thực tế

Bên trong hàm, global_var = val;là một biểu thức đầy đủ , và 3trong return 3;6,8 4:

Một biểu hiện đầy đủ là một biểu hiện đó không phải là một phần của biểu thức khác, cũng không phải là một phần của một declarator hoặc declarator trừu tượng ...

Sau đó, có một điểm thứ tự giữa hai biểu thức này, một lần nữa trên 6.8 4:

Có một điểm thứ tự giữa việc đánh giá biểu thức đầy đủ và đánh giá biểu thức đầy đủ tiếp theo được đánh giá.

Do đó, việc thực hiện C có thể đánh giá arr[global_var]đầu tiên và sau đó thực hiện lệnh gọi hàm, trong trường hợp đó có một điểm thứ tự giữa chúng bởi vì có một điểm trước lệnh gọi hàm hoặc nó có thể đánh giá global_var = val;trong lệnh gọi hàm và sau đó arr[global_var], trong trường hợp đó có một điểm thứ tự giữa chúng bởi vì có một điểm sau biểu thức đầy đủ. Vì vậy, hành vi là không xác định được một trong hai điều đó có thể được đánh giá đầu tiên nhưng nó không được xác định.

Kết quả ở đây là không xác định .

Trong khi thứ tự của các hoạt động trong một biểu thức, quy định cách thức các biểu thức con được nhóm lại, được xác định rõ, thứ tự đánh giá không được chỉ định. Trong trường hợp này, điều đó có nghĩa là global_varcó thể được đọc trước hoặc cuộc gọi đến update_threecó thể xảy ra trước, nhưng không có cách nào để biết được.

Có không xác định hành vi ở đây vì một cuộc gọi chức năng giới thiệu một điểm chuỗi, cũng như tất cả các tuyên bố trong các chức năng trong đó có một mà sửa đổi global_var.

Để làm rõ, tiêu chuẩn C định nghĩa hành vi không xác định trong phần 3.4.3 là:

hành vi không xác định

hành vi, khi sử dụng một cấu trúc chương trình không thể truy cập hoặc có lỗi hoặc dữ liệu sai, mà Tiêu chuẩn quốc tế này áp đặt không có yêu cầu

và định nghĩa hành vi không xác định trong mục 3.4.4 là:

hành vi không xác định

sử dụng một giá trị không xác định hoặc hành vi khác trong đó Tiêu chuẩn quốc tế này cung cấp hai hoặc nhiều khả năng và không áp dụng thêm các yêu cầu nào được chọn trong bất kỳ trường hợp nào

Tiêu chuẩn quy định rằng thứ tự đánh giá của các đối số hàm là không xác định, trong trường hợp này có nghĩa là arr[0]được đặt thành 3 hoặc arr[2]được đặt thành 3.

Tôi đã thử và tôi đã nhận được mục 0 cập nhật.

Tuy nhiên, theo câu hỏi này: phần bên phải của biểu thức luôn được đánh giá đầu tiên

Thứ tự đánh giá là không xác định và không có kết quả. Vì vậy, tôi nghĩ rằng một mã như thế này nên tránh.

Vì việc phát mã cho một phép gán trước khi bạn có giá trị cần gán rất ít, hầu hết các trình biên dịch C trước tiên sẽ phát mã gọi hàm và lưu kết quả ở đâu đó (đăng ký, ngăn xếp, v.v.), sau đó chúng sẽ phát ra mã ghi giá trị này đến đích cuối cùng của nó và do đó họ sẽ đọc biến toàn cục sau khi nó được thay đổi. Chúng ta hãy gọi đây là "trật tự tự nhiên", không được xác định bởi bất kỳ tiêu chuẩn nào mà bằng logic thuần túy.

Tuy nhiên, trong quá trình tối ưu hóa, trình biên dịch sẽ cố gắng loại bỏ bước trung gian lưu tạm thời giá trị ở đâu đó và cố gắng viết kết quả hàm trực tiếp nhất có thể đến đích cuối cùng và trong trường hợp đó, chúng thường sẽ phải đọc chỉ mục trước , ví dụ như một thanh ghi, để có thể di chuyển trực tiếp kết quả hàm vào mảng. Điều này có thể khiến biến toàn cục được đọc trước khi nó được thay đổi.

Vì vậy, đây về cơ bản là hành vi không xác định với thuộc tính rất xấu mà rất có thể kết quả sẽ khác nhau, tùy thuộc vào việc tối ưu hóa được thực hiện và mức độ tối ưu hóa này mạnh mẽ như thế nào. Nhiệm vụ của bạn là nhà phát triển để giải quyết vấn đề đó bằng cách mã hóa:

int idx = global_var;
arr[idx] = update_three(2);

hoặc mã hóa:

int temp = update_three(2);
arr[global_var] = temp;

Như một quy tắc tốt: Trừ khi các biến toàn cục là const(hoặc chúng không nhưng bạn biết rằng sẽ không có mã nào thay đổi chúng như một tác dụng phụ), bạn không bao giờ nên sử dụng chúng trực tiếp trong mã, như trong môi trường đa luồng, như trong một môi trường đa luồng, thậm chí điều này có thể không được xác định:

int result = global_var + (2 * global_var);
// Is not guaranteed to be equal to `3 * global_var`!

Vì trình biên dịch có thể đọc nó hai lần và một luồng khác có thể thay đổi giá trị ở giữa hai lần đọc. Tuy nhiên, một lần nữa, tối ưu hóa chắc chắn sẽ khiến mã chỉ đọc một lần, do đó bạn có thể lại có kết quả khác mà giờ cũng phụ thuộc vào thời gian của một luồng khác. Do đó, bạn sẽ bớt đau đầu hơn rất nhiều nếu bạn lưu trữ các biến toàn cục vào một biến ngăn xếp tạm thời trước khi sử dụng. Hãy ghi nhớ nếu trình biên dịch nghĩ rằng điều này an toàn, rất có thể nó sẽ tối ưu hóa ngay cả khi đó và thay vào đó sử dụng biến toàn cục trực tiếp, vì vậy cuối cùng, nó có thể không tạo ra sự khác biệt trong hiệu suất hoặc sử dụng bộ nhớ.

(Chỉ trong trường hợp ai đó hỏi tại sao mọi người sẽ làm x + 2 * xthay vì 3 * x- trên một số bổ sung CPU là cực nhanh và nhân với một công suất hai vì trình biên dịch sẽ biến chúng thành bit shift ( 2 * x == x << 1), nhưng nhân với số tùy ý có thể rất chậm , do đó, thay vì nhân 3, bạn nhận được mã nhanh hơn nhiều bằng cách dịch chuyển x 1 và thêm x vào kết quả - và thậm chí mẹo đó được thực hiện bởi các trình biên dịch hiện đại nếu bạn nhân 3 và bật tối ưu hóa tích cực trừ khi đó là mục tiêu hiện đại CPU trong đó phép nhân cũng nhanh như nhau kể từ đó, thủ thuật sẽ làm chậm quá trình tính toán.)

Chỉnh sửa toàn cầu: xin lỗi các bạn, tôi đã bị sa thải và viết rất nhiều điều vô nghĩa. Chỉ là một lão già gặm nhấm.

Tôi muốn tin rằng C đã được tha, nhưng than ôi kể từ C11, nó đã được đưa lên ngang hàng với C ++. Rõ ràng, việc biết trình biên dịch sẽ làm gì với các hiệu ứng phụ trong các biểu thức đòi hỏi phải giải quyết một câu đố toán học nhỏ liên quan đến việc sắp xếp một phần các chuỗi mã dựa trên "được đặt trước điểm đồng bộ hóa".

Tôi tình cờ đã thiết kế và triển khai một vài hệ thống nhúng thời gian thực quan trọng trong những ngày K & R (bao gồm cả bộ điều khiển của một chiếc xe điện có thể khiến mọi người đâm vào bức tường gần nhất nếu động cơ không được kiểm tra, công nghiệp 10 tấn robot có thể đè bẹp con người vào bột giấy nếu không được chỉ huy đúng cách và một lớp hệ thống, mặc dù vô hại, sẽ có vài chục bộ xử lý hút bus dữ liệu của chúng khô với hệ thống dưới 1%).

Tôi có thể quá già hoặc ngu ngốc để có được sự khác biệt giữa không xác định và không xác định, nhưng tôi nghĩ rằng tôi vẫn có một ý tưởng khá tốt về việc thực thi đồng thời và truy cập dữ liệu có nghĩa là gì. Theo ý kiến ​​được cho là thông tin của tôi, nỗi ám ảnh về C ++ và bây giờ là những người C với ngôn ngữ thú cưng của họ tiếp quản các vấn đề đồng bộ hóa là một giấc mơ đắt giá. Hoặc bạn biết thực thi đồng thời là gì và bạn không cần bất kỳ gizmos nào, hoặc bạn không, và bạn sẽ làm cho thế giới rộng lớn không cố gắng gây rối với nó.

Tất cả các khối lượng trừu tượng của rào cản bộ nhớ tưới nước này chỉ đơn giản là do một số hạn chế tạm thời của các hệ thống bộ đệm đa CPU, tất cả đều có thể được gói gọn trong các đối tượng đồng bộ hóa hệ điều hành phổ biến như, ví dụ, các biến thể và biến điều kiện C ++ cung cấp.
Chi phí của việc đóng gói này là nhưng hiệu suất giảm một phút so với việc sử dụng các hướng dẫn CPU cụ thể có thể đạt được là một số trường hợp.
Các volatiletừ khóa (hoặc một#pragma dont-mess-with-that-variableđối với tất cả tôi, với tư cách là một lập trình viên hệ thống, quan tâm) sẽ là khá đủ để nói với trình biên dịch ngừng sắp xếp lại các truy cập bộ nhớ. Mã tối ưu có thể dễ dàng được tạo ra bằng các chỉ thị asm trực tiếp để rắc trình điều khiển và mã hệ điều hành cấp thấp với các hướng dẫn cụ thể của CPU ad hoc. Nếu không có kiến ​​thức sâu sắc về cách thức hoạt động của phần cứng cơ bản (hệ thống bộ đệm hoặc giao diện bus), bạn chắc chắn sẽ viết mã vô dụng, không hiệu quả hoặc bị lỗi.

Một phút điều chỉnh volatiletừ khóa và Bob sẽ là tất cả mọi người trừ chú của các lập trình viên cấp thấp khó tính nhất. Thay vào đó, các nhóm toán học C ++ thông thường đã có một ngày thực địa thiết kế một sự trừu tượng khó hiểu khác, mang lại xu hướng điển hình của họ là thiết kế các giải pháp tìm kiếm các vấn đề không tồn tại và nhầm lẫn định nghĩa của ngôn ngữ lập trình với thông số kỹ thuật của trình biên dịch.

Chỉ lần này, sự thay đổi cần thiết để làm mất đi một khía cạnh cơ bản của C, vì những "rào cản" này phải được tạo ra ngay cả trong mã C cấp thấp để hoạt động chính xác. Điều đó, trong số những thứ khác, rèn sự định nghĩa trong biểu thức, không có lời giải thích hay biện minh nào.

Kết luận, việc một trình biên dịch có thể tạo ra một mã máy nhất quán từ đoạn C vô lý này chỉ là hậu quả xa vời của cách những kẻ C ++ đối phó với sự không nhất quán tiềm tàng của các hệ thống bộ đệm vào cuối những năm 2000.
Nó đã tạo ra một mớ hỗn độn khủng khiếp về một khía cạnh cơ bản của C (định nghĩa biểu thức), do đó, phần lớn các lập trình viên C - những người không đưa ra một hệ thống bộ nhớ cache chết tiệt, và đúng như vậy - giờ đây buộc phải dựa vào các bậc thầy để giải thích sự khác biệt giữa a = b() + c()và a = b + c.

Cố gắng đoán những gì sẽ trở thành của mảng không may này là mất thời gian và nỗ lực ròng. Bất kể trình biên dịch sẽ làm gì với nó, mã này là sai về mặt bệnh lý. Điều duy nhất có trách nhiệm phải làm với nó là gửi nó vào thùng.
Về mặt khái niệm, các tác dụng phụ luôn có thể được chuyển ra khỏi các biểu thức, với nỗ lực tầm thường là để cho phép sửa đổi xảy ra trước hoặc sau khi đánh giá, trong một tuyên bố riêng.
Loại mã shitty này có thể đã được chứng minh vào những năm 80, khi bạn không thể mong đợi một trình biên dịch để tối ưu hóa bất cứ điều gì. Nhưng bây giờ các trình biên dịch từ lâu đã trở nên thông minh hơn hầu hết các lập trình viên, tất cả những gì còn lại là một đoạn mã shitty.

Tôi cũng không hiểu tầm quan trọng của cuộc tranh luận không xác định / không xác định này. Hoặc bạn có thể dựa vào trình biên dịch để tạo mã với hành vi nhất quán hoặc bạn không thể. Cho dù bạn gọi đó là không xác định hoặc không xác định có vẻ như một điểm moot.

Theo ý kiến ​​được cho là của tôi, C đã đủ nguy hiểm trong trạng thái K & R của nó. Một sự tiến hóa hữu ích sẽ là thêm các biện pháp an toàn thông thường. Ví dụ, sử dụng công cụ phân tích mã nâng cao này, thông số kỹ thuật buộc trình biên dịch phải thực hiện ít nhất là tạo cảnh báo về mã bonkers, thay vì âm thầm tạo mã có khả năng không đáng tin cậy đến mức cực đoan.
Nhưng thay vào đó, các chàng trai đã quyết định, ví dụ, để xác định một thứ tự đánh giá cố định trong C ++ 17. Bây giờ mọi phần mềm imbecile đều được kích hoạt để đưa các tác dụng phụ vào mã của anh ấy / cô ấy một cách có chủ đích, dựa trên sự chắc chắn rằng các trình biên dịch mới sẽ háo hức xử lý obfuscation theo cách xác định.

K & R là một trong những tuyệt tác thực sự của thế giới điện toán. Trong hai mươi đô la, bạn có một đặc tả toàn diện về ngôn ngữ (Tôi đã thấy các cá nhân đơn lẻ viết trình biên dịch hoàn chỉnh chỉ bằng cách sử dụng cuốn sách này), một hướng dẫn tham khảo tuyệt vời (mục lục thường sẽ chỉ cho bạn trong một vài trang câu trả lời của bạn câu hỏi), và một cuốn sách giáo khoa sẽ dạy bạn sử dụng ngôn ngữ một cách hợp lý. Hoàn thành với những lý lẽ, ví dụ và những lời cảnh báo khôn ngoan về vô số cách bạn có thể lạm dụng ngôn ngữ để làm những việc rất, rất ngu ngốc.

Phá hủy di sản đó để kiếm được rất ít dường như là một sự lãng phí tàn nhẫn đối với tôi. Nhưng một lần nữa tôi rất có thể không nhìn thấy điểm hoàn toàn. Có lẽ một linh hồn tốt bụng nào đó có thể chỉ cho tôi theo hướng của một ví dụ về mã C mới có lợi thế đáng kể của các tác dụng phụ này?