Tại sao không thể xây dựng một trình biên dịch có thể xác định xem một hàm C ++ có thay đổi giá trị của một biến cụ thể hay không?

Tôi đọc dòng này trong một cuốn sách:

Rõ ràng là không thể xây dựng một trình biên dịch thực sự có thể xác định xem một hàm C ++ có thay đổi giá trị của một biến cụ thể hay không.

Đoạn văn đã nói về lý do tại sao trình biên dịch thận trọng khi kiểm tra const-ness.

Tại sao không thể xây dựng một trình biên dịch như vậy?

Trình biên dịch luôn có thể kiểm tra xem một biến có được gán lại hay không, một hàm không phải const đang được gọi trên đó hoặc nếu nó đang được chuyển vào dưới dạng tham số không const ...

Tại sao không thể xây dựng một trình biên dịch như vậy?

Vì lý do tương tự mà bạn không thể viết một chương trình sẽ xác định xem bất kỳ chương trình nhất định nào sẽ kết thúc hay không. Đây được gọi là vấn đề tạm dừng , và đó là một trong những điều không thể tính toán được.

Để rõ ràng hơn, bạn có thể viết một trình biên dịch có thể xác định rằng một hàm có thay đổi biến trong một số trường hợp , nhưng bạn không thể viết một trình biên dịch cho bạn biết một cách đáng tin cậy rằng hàm sẽ hoặc sẽ không thay đổi biến (hoặc tạm dừng) đối với mọi chức năng có thể.

Đây là một ví dụ dễ hiểu:

void foo() {
    if (bar() == 0) this->a = 1;
}

Làm thế nào một trình biên dịch có thể xác định, chỉ từ việc nhìn vào đoạn mã đó, liệu có foobao giờ thay đổi akhông? Cho dù nó có hay không phụ thuộc vào các điều kiện bên ngoài hàm, cụ thể là việc thực hiện bar. Còn nhiều điều hơn thế bằng chứng rằng vấn đề tạm dừng không thể tính toán được, nhưng nó đã được giải thích độc đáo tại bài viết Wikipedia được liên kết (và trong mọi sách giáo khoa lý thuyết tính toán), vì vậy tôi sẽ không cố gắng giải thích nó một cách chính xác ở đây.

Hãy tưởng tượng trình biên dịch như vậy tồn tại. Cũng giả sử rằng để thuận tiện, nó cung cấp một hàm thư viện trả về 1 nếu hàm được truyền vào sửa đổi một biến nhất định và 0 khi hàm không sửa đổi. Sau đó, những gì chương trình này nên in?

int variable = 0;

void f() {
    if (modifies_variable(f, variable)) {
        /* do nothing */
    } else {
        /* modify variable */
        variable = 1;
    }
}

int main(int argc, char **argv) {
    if (modifies_variable(f, variable)) {
        printf("Modifies variable\n");
    } else {
        printf("Does not modify variable\n");
    }

    return 0;
}

Đừng nhầm lẫn "sẽ hoặc sẽ không sửa đổi một biến với các đầu vào này" cho "có một đường dẫn thực thi sửa đổi một biến."

Điều trước đây được gọi là xác định vị từ không rõ ràng và không thể quyết định được - ngoài việc giảm thiểu vấn đề tạm dừng, bạn chỉ có thể chỉ ra các đầu vào có thể đến từ một nguồn không xác định (ví dụ: người dùng). Điều này đúng với tất cả các ngôn ngữ, không chỉ C ++.

Tuy nhiên, câu lệnh thứ hai có thể được xác định bằng cách xem xét cây phân tích cú pháp, đây là điều mà tất cả các trình biên dịch tối ưu hóa đều làm. Lý do họ làm là các hàm thuần túy (và các hàm trong suốt tham chiếu , đối với một số định nghĩa về minh bạch tham chiếu ) có tất cả các loại tối ưu hóa tốt có thể được áp dụng, như dễ nhập vào hoặc xác định giá trị của chúng tại thời điểm biên dịch; nhưng để biết một hàm có thuần túy hay không, chúng ta cần biết liệu nó có thể sửa đổi một biến hay không.

Vì vậy, những gì có vẻ là một tuyên bố đáng ngạc nhiên về C ++ thực sự là một tuyên bố tầm thường về tất cả các ngôn ngữ.

Tôi nghĩ từ khóa trong "liệu một hàm C ++ có thay đổi giá trị của một biến cụ thể hay không" là "will". Chắc chắn có thể xây dựng một trình biên dịch kiểm tra xem một hàm C ++ có được phép thay đổi giá trị của một biến cụ thể hay không, bạn không thể nói chắc chắn rằng thay đổi sẽ xảy ra:

void maybe(int& val) {
    cout << "Should I change value? [Y/N] >";
    string reply;
    cin >> reply;
    if (reply == "Y") {
        val = 42;
    }
}

Tôi không nghĩ rằng cần phải gọi vấn đề tạm dừng để giải thích rằng bạn không thể biết về mặt thuật toán tại thời điểm biên dịch liệu một hàm đã cho có sửa đổi một biến nhất định hay không.

Thay vào đó, đủ để chỉ ra rằng hành vi của một hàm thường phụ thuộc vào các điều kiện thời gian chạy mà trình biên dịch không thể biết trước. Ví dụ

int y;

int main(int argc, char *argv[]) {
   if (argc > 2) y++;
}

Làm thế nào trình biên dịch có thể dự đoán một cách chắc chắn liệu ysẽ được sửa đổi?

Nó có thể được thực hiện và các trình biên dịch luôn làm việc đó cho một số chức năng , ví dụ như đây là một sự tối ưu hóa nhỏ cho các trình truy cập nội tuyến đơn giản hoặc nhiều chức năng thuần túy.

Điều gì là không thể là biết nó trong trường hợp chung.

Bất cứ khi nào có một lệnh gọi hệ thống hoặc một lệnh gọi hàm đến từ một mô-đun khác hoặc một lệnh gọi đến một phương thức có khả năng bị ghi đè, bất cứ điều gì có thể xảy ra, bao gồm cả việc tiếp quản thù địch từ việc sử dụng tràn ngăn xếp để thay đổi một biến không liên quan.

Tuy nhiên, bạn nên sử dụng const, tránh toàn cầu, ưu tiên tham chiếu đến con trỏ, tránh sử dụng lại các biến cho các tác vụ không liên quan, v.v. sẽ làm cho cuộc sống của trình biên dịch dễ dàng hơn khi thực hiện tối ưu hóa tích cực.

Có nhiều cách để giải thích điều này, một trong số đó là Vấn đề Tạm dừng :

Trong lý thuyết tính toán, bài toán tạm dừng có thể được phát biểu như sau: "Cho một mô tả của một chương trình máy tính tùy ý, quyết định xem chương trình chạy xong hay tiếp tục chạy mãi mãi". Điều này tương đương với vấn đề quyết định, cho một chương trình và một đầu vào, liệu chương trình cuối cùng sẽ dừng lại khi chạy với đầu vào đó, hay sẽ chạy mãi mãi.

Alan Turing đã chứng minh vào năm 1936 rằng không thể tồn tại một thuật toán chung để giải quyết vấn đề tạm dừng cho tất cả các cặp đầu vào chương trình có thể có.

Nếu tôi viết một chương trình giống như sau:

do tons of complex stuff
if (condition on result of complex stuff)
{
    change value of x
}
else
{
    do not change value of x
}

Giá trị có xthay đổi không? Để xác định điều này, trước tiên bạn sẽ phải xác định xem bộ do tons of complex stuffphận gây ra tình trạng cháy - hoặc thậm chí cơ bản hơn, liệu nó có tạm dừng hay không. Đó là điều mà trình biên dịch không làm được.

Thực sự ngạc nhiên rằng không có câu trả lời nào trực tiếp sử dụng vấn đề tạm dừng! Có một sự giảm rất đơn giản từ vấn đề này thành vấn đề dừng.

Hãy tưởng tượng rằng trình biên dịch có thể cho biết liệu một hàm có thay đổi giá trị của một biến hay không. Sau đó, nó chắc chắn sẽ có thể biết liệu hàm sau có thay đổi giá trị của y hay không, giả sử rằng giá trị của x có thể được theo dõi trong tất cả các lệnh gọi trong suốt phần còn lại của chương trình:

foo(int x){
   if(x)
       y=1;
}

Bây giờ, đối với bất kỳ chương trình nào chúng ta thích, hãy viết lại nó thành:

int y;
main(){
    int x;
    ...
    run the program normally
    ...
    foo(x);
}

Lưu ý rằng, nếu và chỉ khi, chương trình của chúng ta thay đổi giá trị của y, thì nó mới kết thúc - foo () là điều cuối cùng nó thực hiện trước khi thoát. Điều này có nghĩa là chúng tôi đã giải quyết được vấn đề tạm dừng!

Những gì giảm ở trên cho chúng ta thấy là vấn đề xác định xem giá trị của một biến có thay đổi hay không ít nhất là khó như vấn đề tạm dừng. Vấn đề tạm dừng được biết là không thể thay đổi, vì vậy vấn đề này cũng phải như vậy.

Ngay khi một hàm gọi một hàm khác mà trình biên dịch không "nhìn thấy" nguồn của nó, nó sẽ phải giả định rằng biến đó đã bị thay đổi, hoặc mọi thứ có thể còn sai ở bên dưới. Ví dụ: giả sử chúng tôi có điều này trong "foo.cpp":

 void foo(int& x)
 {
    ifstream f("f.dat", ifstream::binary);
    f.read((char *)&x, sizeof(x));
 }

và chúng tôi có cái này trong "bar.cpp":

void bar(int& x)
{
  foo(x);
}

Làm thế nào trình biên dịch có thể "biết" xlà không thay đổi (hoặc IS đang thay đổi, thích hợp hơn) trong bar?

Tôi chắc rằng chúng ta có thể nghĩ ra một thứ gì đó phức tạp hơn, nếu điều này không đủ phức tạp.

Không thể nói chung để cho trình biên dịch để xác định xem biến sẽ được thay đổi, như đã được chỉ ra.

Khi kiểm tra const-ness, câu hỏi quan tâm dường như là liệu biến có thể được thay đổi bởi một hàm hay không. Ngay cả điều này cũng khó trong các ngôn ngữ hỗ trợ con trỏ. Bạn không thể kiểm soát những gì mã khác thực hiện với một con trỏ, thậm chí nó có thể được đọc từ một nguồn bên ngoài (mặc dù không chắc). Trong các ngôn ngữ hạn chế quyền truy cập vào bộ nhớ, các loại đảm bảo này có thể có và cho phép tối ưu hóa tích cực hơn C ++.

Để làm cho câu hỏi cụ thể hơn, tôi đề xuất một loạt các ràng buộc sau đây có thể là điều mà tác giả cuốn sách có thể đã nghĩ đến:

1. Giả sử trình biên dịch đang kiểm tra hành vi của một hàm cụ thể liên quan đến const-ness của một biến. Đối với tính đúng đắn, một trình biên dịch sẽ phải giả sử (vì răng cưa như được giải thích bên dưới) nếu hàm được gọi là một hàm khác mà biến bị thay đổi, vì vậy giả định # 1 chỉ áp dụng cho các đoạn mã không thực hiện lệnh gọi hàm.
2. Giả sử biến không bị sửa đổi bởi hoạt động không đồng bộ hoặc đồng thời.
3. Giả sử trình biên dịch chỉ xác định xem biến có thể được sửa đổi hay không, chứ không phải liệu nó có được sửa đổi hay không. Nói cách khác, trình biên dịch chỉ thực hiện phân tích tĩnh.
4. Giả sử trình biên dịch chỉ đang xem xét mã hoạt động chính xác (không xem xét vượt quá / chạy dưới mảng, con trỏ xấu, v.v.)

Trong bối cảnh thiết kế trình biên dịch, tôi nghĩ rằng các giả định 1,3,4 có ý nghĩa hoàn hảo trong quan điểm của một người viết trình biên dịch trong bối cảnh tính đúng đắn của gen mã và / hoặc tối ưu hóa mã. Giả định 2 có ý nghĩa khi không có từ khóa biến động. Và những giả định này cũng tập trung câu hỏi đủ để làm cho việc đánh giá một câu trả lời được đề xuất chắc chắn hơn nhiều :-)

Với những giả định đó, lý do chính khiến không thể giả định const-ness là do răng cưa biến. Trình biên dịch không thể biết liệu một biến khác có trỏ đến biến const hay không. Việc đặt biệt hiệu có thể là do một chức năng khác trong cùng một đơn vị biên dịch, trong trường hợp đó, trình biên dịch có thể xem xét các chức năng và sử dụng cây lệnh gọi để xác định tĩnh rằng hiện tượng răng cưa có thể xảy ra. Nhưng nếu bí danh là do một thư viện hoặc mã ngoại lai khác, thì trình biên dịch không có cách nào để biết khi nhập hàm liệu các biến có phải là bí danh hay không.

Bạn có thể tranh luận rằng nếu một biến / đối số được đánh dấu là const thì nó sẽ không thể thay đổi thông qua bí danh, nhưng đối với một người viết trình biên dịch thì điều đó khá rủi ro. Một lập trình viên con người thậm chí có thể gặp rủi ro khi khai báo một biến const như một phần của dự án lớn, nơi anh ta không biết hành vi của toàn bộ hệ thống, hoặc hệ điều hành hoặc thư viện, để thực sự biết một biến đã thắng ' t thay đổi.

Ngay cả khi một biến được khai báo const, không có nghĩa là một số mã bị viết sai có thể ghi đè lên nó.

//   g++ -o foo foo.cc

#include <iostream>
void const_func(const int&a, int* b)
{
   b[0] = 2;
   b[1] = 2;
}

int main() {
   int a = 1;
   int b = 3;

   std::cout << a << std::endl;
   const_func(a,&b);
   std::cout << a << std::endl;
}

đầu ra:

1
2

Để mở rộng các nhận xét của tôi, nội dung cuốn sách đó không rõ ràng, điều gì làm xáo trộn vấn đề.

Như tôi đã nhận xét, cuốn sách đó đang cố gắng nói, "chúng ta hãy lấy vô số con khỉ để viết mọi hàm C ++ có thể tưởng tượng được mà có thể được viết. Sẽ có trường hợp nếu chúng ta chọn một biến (một số hàm cụ thể mà lũ khỉ đã viết) sử dụng, chúng tôi không thể tìm hiểu liệu hàm có thay đổi biến đó hay không. "

Tất nhiên đối với một số (thậm chí nhiều) chức năng trong bất kỳ ứng dụng nhất định nào, điều này có thể được xác định bởi trình biên dịch và rất dễ dàng. Nhưng không phải cho tất cả (hoặc nhất thiết là hầu hết).

Có thể dễ dàng phân tích chức năng này:

static int global;

void foo()
{
}

"foo" rõ ràng không sửa đổi "toàn cầu". Nó không sửa đổi bất cứ điều gì và một trình biên dịch có thể giải quyết vấn đề này rất dễ dàng.

Chức năng này không thể được phân tích như vậy:

static int global;

int foo()
{
    if ((rand() % 100) > 50)
    {
        global = 1;
    }
    return 1;

Vì các hành động của "foo" phụ thuộc vào một giá trị có thể thay đổi trong thời gian chạy , nó thường không thể được xác định tại thời điểm biên dịch liệu nó có sửa đổi "toàn cục" hay không.

Toàn bộ khái niệm này dễ hiểu hơn nhiều so với các nhà khoa học máy tính tạo ra nó. Nếu hàm có thể làm điều gì đó khác biệt dựa trên những thứ có thể thay đổi trong thời gian chạy, thì bạn không thể tìm ra nó sẽ làm gì cho đến khi nó chạy và mỗi lần nó chạy nó có thể làm điều gì đó khác. Dù có thể chứng minh là không thể hay không, thì rõ ràng là không thể.