เหตุใดจึงไม่สามารถสร้างคอมไพเลอร์ที่สามารถระบุได้ว่าฟังก์ชัน C ++ จะเปลี่ยนค่าของตัวแปรเฉพาะหรือไม่?

ฉันอ่านบรรทัดนี้ในหนังสือ:

เป็นไปไม่ได้เลยที่จะสร้างคอมไพเลอร์ที่สามารถระบุได้ว่าฟังก์ชัน C ++ จะเปลี่ยนค่าของตัวแปรเฉพาะหรือไม่

ย่อหน้านี้กำลังพูดถึงสาเหตุที่คอมไพเลอร์เป็นแบบอนุรักษ์นิยมเมื่อตรวจสอบ const-ness

เหตุใดจึงไม่สามารถสร้างคอมไพเลอร์ดังกล่าวได้

คอมไพลเลอร์สามารถตรวจสอบได้ตลอดเวลาว่ามีการกำหนดตัวแปรใหม่หรือไม่ฟังก์ชันที่ไม่ใช่ const จะถูกเรียกใช้หรือหากมีการส่งผ่านเป็นพารามิเตอร์ที่ไม่ใช่ const ...

เหตุใดจึงไม่สามารถสร้างคอมไพเลอร์ดังกล่าวได้

ด้วยเหตุผลเดียวกับที่คุณไม่สามารถเขียนโปรแกรมที่จะตัดสินว่าโปรแกรมใด ๆ จะยุติลงหรือไม่ สิ่งนี้เรียกว่าปัญหาการหยุดชะงักและเป็นหนึ่งในสิ่งเหล่านั้นที่ไม่สามารถคำนวณได้

เพื่อความชัดเจนคุณสามารถเขียนคอมไพเลอร์ที่สามารถระบุได้ว่าฟังก์ชันเปลี่ยนตัวแปรได้ในบางกรณีแต่คุณไม่สามารถเขียนตัวแปรที่บอกคุณได้อย่างน่าเชื่อถือว่าฟังก์ชันจะเปลี่ยนหรือไม่เปลี่ยนตัวแปร (หรือหยุด) สำหรับ ทุกฟังก์ชั่นที่เป็นไปได้

นี่คือตัวอย่างง่ายๆ:

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

คอมไพเลอร์จะตรวจสอบได้อย่างไรจากการดูรหัสนั้นว่าfooจะเปลี่ยนแปลงไปaหรือไม่? ไม่ว่าจะเป็นหรือไม่ขึ้นอยู่กับเงื่อนไขภายนอกของฟังก์ชันนั่นคือการใช้งานbar. มีมากกว่านั้นในการพิสูจน์ว่าปัญหาการหยุดชะงักนั้นไม่สามารถคำนวณได้ แต่มีการอธิบายไว้อย่างดีในบทความ Wikipedia ที่เชื่อมโยงกัน (และในตำราทฤษฎีการคำนวณทุกเล่ม) ดังนั้นฉันจะไม่พยายามอธิบายอย่างถูกต้องที่นี่

ลองนึกภาพคอมไพเลอร์ดังกล่าวมีอยู่จริง สมมติว่าเพื่อความสะดวกมันมีฟังก์ชันไลบรารีที่ส่งคืน 1 หากฟังก์ชันที่ส่งผ่านแก้ไขตัวแปรที่กำหนดและ 0 เมื่อฟังก์ชันไม่ได้ แล้วโปรแกรมนี้ควรพิมพ์อะไร?

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;
}

อย่าสับสนว่า "จะหรือไม่แก้ไขตัวแปรที่กำหนดให้อินพุตเหล่านี้" for "มีเส้นทางการดำเนินการที่แก้ไขตัวแปร"

เดิมเรียกว่าการกำหนดเพรดิเคตทึบแสงและเป็นไปไม่ได้เลยที่จะตัดสินใจ - นอกเหนือจากการลดปัญหาการหยุดชะงักคุณสามารถชี้ให้เห็นว่าอินพุตอาจมาจากแหล่งที่ไม่รู้จัก (เช่นผู้ใช้) นี่เป็นความจริงในทุกภาษาไม่ใช่เฉพาะ C ++

อย่างไรก็ตามคำสั่งหลังสามารถพิจารณาได้โดยดูที่โครงสร้างการแยกวิเคราะห์ซึ่งเป็นสิ่งที่คอมไพเลอร์ที่ปรับให้เหมาะสมทั้งหมดทำ เหตุผลที่พวกเขาทำคือฟังก์ชันบริสุทธิ์ (และฟังก์ชันโปร่งใสอ้างอิงสำหรับคำจำกัดความของความโปร่งใสอ้างอิงบางส่วน )มีการเพิ่มประสิทธิภาพที่ดีทุกประเภทที่สามารถนำไปใช้เช่นไม่สามารถปรับเปลี่ยนได้ง่ายหรือมีการกำหนดค่าในเวลาคอมไพล์ แต่หากต้องการทราบว่าฟังก์ชันบริสุทธิ์เราจำเป็นต้องทราบว่าสามารถแก้ไขตัวแปรได้หรือไม่

ดังนั้นสิ่งที่ดูเหมือนจะเป็นคำพูดที่น่าแปลกใจเกี่ยวกับ C ++ นั้นเป็นคำพูดที่ไม่สำคัญเกี่ยวกับทุกภาษา

ฉันคิดว่าคำสำคัญใน "ไม่ว่าฟังก์ชัน C ++ จะเปลี่ยนค่าของตัวแปรเฉพาะ" เป็น "จะ" หรือไม่ เป็นไปได้อย่างแน่นอนที่จะสร้างคอมไพเลอร์ที่ตรวจสอบว่าฟังก์ชัน C ++ ได้รับอนุญาตให้เปลี่ยนค่าของตัวแปรเฉพาะหรือไม่คุณไม่สามารถพูดได้ด้วยความมั่นใจว่าการเปลี่ยนแปลงจะเกิดขึ้น:

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

ฉันไม่คิดว่าจำเป็นต้องเรียกใช้ปัญหาการหยุดเพื่ออธิบายว่าคุณไม่สามารถรู้อัลกอริทึมในเวลาคอมไพล์ได้ว่าฟังก์ชันที่กำหนดจะแก้ไขตัวแปรบางอย่างหรือไม่

แต่ก็เพียงพอแล้วที่จะชี้ให้เห็นว่าพฤติกรรมของฟังก์ชันมักขึ้นอยู่กับเงื่อนไขรันไทม์ซึ่งคอมไพเลอร์ไม่สามารถรู้ล่วงหน้าได้ เช่น

int y;

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

คอมไพเลอร์จะคาดเดาได้อย่างไรว่าyจะถูกแก้ไขหรือไม่?

สามารถทำได้และคอมไพเลอร์กำลังทำอยู่ตลอดเวลาสำหรับบางฟังก์ชันตัวอย่างเช่นการเพิ่มประสิทธิภาพเล็กน้อยสำหรับตัวเข้าถึงอินไลน์แบบธรรมดาหรือฟังก์ชันบริสุทธิ์มากมาย

สิ่งที่เป็นไปไม่ได้คือการรู้ในกรณีทั่วไป

เมื่อใดก็ตามที่มีการเรียกระบบหรือการเรียกใช้ฟังก์ชันที่มาจากโมดูลอื่นหรือการเรียกใช้เมธอดที่อาจลบล้างสิ่งที่อาจเกิดขึ้นรวมถึงการครอบครองที่ไม่เป็นมิตรจากการใช้สแต็กโอเวอร์โฟลว์ของแฮ็กเกอร์เพื่อเปลี่ยนตัวแปรที่ไม่เกี่ยวข้อง

อย่างไรก็ตามคุณควรใช้ const หลีกเลี่ยง globals ชอบการอ้างอิงถึงพอยน์เตอร์หลีกเลี่ยงการนำตัวแปรกลับมาใช้ใหม่สำหรับงานที่ไม่เกี่ยวข้อง ฯลฯ ซึ่งจะทำให้ชีวิตของคอมไพเลอร์ง่ายขึ้นเมื่อทำการเพิ่มประสิทธิภาพเชิงรุก

มีหลายวิธีในการอธิบายสิ่งนี้ซึ่งหนึ่งในนั้นคือปัญหาการหยุดชะงัก :

ในทฤษฎีความสามารถในการคำนวณปัญหาการหยุดชะงักสามารถระบุได้ดังนี้: "ให้คำอธิบายของโปรแกรมคอมพิวเตอร์โดยพลการตัดสินใจว่าโปรแกรมจะทำงานเสร็จหรือยังคงทำงานตลอดไป" สิ่งนี้เทียบเท่ากับปัญหาในการตัดสินใจกำหนดโปรแกรมและอินพุตว่าในที่สุดโปรแกรมจะหยุดทำงานเมื่อรันด้วยอินพุตนั้นหรือจะทำงานตลอดไป

อลันทัวริงพิสูจน์ให้เห็นในปี 2479 ว่าอัลกอริทึมทั่วไปในการแก้ปัญหาการหยุดชะงักของคู่โปรแกรมอินพุตทั้งหมดที่เป็นไปได้

ถ้าฉันเขียนโปรแกรมที่มีลักษณะดังนี้:

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

คุณค่าของxการเปลี่ยนแปลงหรือไม่? ในการพิจารณาสิ่งนี้ก่อนอื่นคุณจะต้องพิจารณาว่าชิ้นdo tons of complex stuffส่วนนั้นทำให้เกิดอาการไฟไหม้หรือไม่หรือพื้นฐานกว่านั้นไม่ว่าจะหยุดหรือไม่ นั่นเป็นสิ่งที่คอมไพเลอร์ไม่สามารถทำได้

แปลกใจจริงๆที่ไม่มีคำตอบว่าใช้การหยุดปัญหาโดยตรง! การลดลงอย่างตรงไปตรงมามากจากปัญหานี้ไปสู่ปัญหาการหยุดชะงัก

ลองนึกภาพว่าคอมไพลเลอร์สามารถบอกได้ว่าฟังก์ชันเปลี่ยนค่าของตัวแปรหรือไม่ จากนั้นจะสามารถบอกได้อย่างแน่นอนว่าฟังก์ชันต่อไปนี้เปลี่ยนค่าของ y หรือไม่โดยสมมติว่าสามารถติดตามค่าของ x ในการเรียกทั้งหมดตลอดส่วนที่เหลือของโปรแกรม:

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

ตอนนี้สำหรับโปรแกรมใด ๆ ที่เราชอบลองเขียนใหม่เป็น:

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

สังเกตว่าถ้าและเฉพาะในกรณีที่โปรแกรมของเราเปลี่ยนค่าของ y มันจะยุติ - foo () เป็นสิ่งสุดท้ายที่ทำก่อนออก ซึ่งหมายความว่าเราได้แก้ไขปัญหาการหยุดชะงักแล้ว!

สิ่งที่การลดลงข้างต้นแสดงให้เราเห็นก็คือปัญหาในการพิจารณาว่าค่าของตัวแปรเปลี่ยนแปลงไปอย่างน้อยก็ยากพอ ๆ กับปัญหาการหยุดชะงัก ปัญหาการหยุดชะงักเป็นที่ทราบกันดีว่าไม่สามารถโต้แย้งได้ดังนั้นจึงต้องมีปัญหานี้ด้วย

ทันทีที่ฟังก์ชั่นเรียกใช้ฟังก์ชันอื่นที่คอมไพลเลอร์ไม่ "เห็น" ที่มาของมันก็จะต้องถือว่าตัวแปรมีการเปลี่ยนแปลงหรือสิ่งต่างๆอาจผิดพลาดเพิ่มเติมด้านล่าง ตัวอย่างเช่นสมมติว่าเรามีสิ่งนี้ใน "foo.cpp":

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

และเรามีสิ่งนี้ใน "bar.cpp":

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

คอมไพเลอร์จะ "รู้" ที่xไม่เปลี่ยนแปลงได้อย่างไร (หรือ IS เปลี่ยนแปลงเหมาะสมกว่า) ในbar?

ฉันแน่ใจว่าเราสามารถหาอะไรที่ซับซ้อนกว่านี้ได้ถ้ามันไม่ซับซ้อนพอ

โดยทั่วไปแล้วเป็นไปไม่ได้ที่คอมไพลเลอร์จะพิจารณาว่าตัวแปรจะถูกเปลี่ยนแปลงหรือไม่ตามที่ได้ระบุไว้

เมื่อตรวจสอบ const-ness คำถามที่น่าสนใจดูเหมือนว่าตัวแปรสามารถเปลี่ยนแปลงได้โดยฟังก์ชัน แม้แต่ภาษาที่รองรับคำแนะนำก็ยาก คุณไม่สามารถควบคุมว่าโค้ดอื่น ๆ ทำอะไรกับตัวชี้ได้แม้จะอ่านได้จากแหล่งภายนอก (แม้ว่าจะไม่น่าเป็นไปได้ก็ตาม) ในภาษาที่ จำกัด การเข้าถึงหน่วยความจำการค้ำประกันประเภทนี้สามารถทำได้และอนุญาตให้มีการเพิ่มประสิทธิภาพเชิงรุกมากกว่าที่ C ++ ทำ

เพื่อให้คำถามมีความเฉพาะเจาะจงมากขึ้นฉันขอแนะนำให้ใช้ข้อ จำกัด ชุดต่อไปนี้ซึ่งอาจเป็นสิ่งที่ผู้เขียนหนังสืออาจมีอยู่ในใจ:

1. สมมติว่าคอมไพเลอร์กำลังตรวจสอบพฤติกรรมของฟังก์ชันเฉพาะที่เกี่ยวกับความเป็นไปได้ของตัวแปร เพื่อความถูกต้องคอมไพเลอร์จะต้องถือว่า (เนื่องจากการใช้นามแฝงตามที่อธิบายไว้ด้านล่าง) หากฟังก์ชันที่เรียกว่าฟังก์ชันอื่นตัวแปรมีการเปลี่ยนแปลงดังนั้นสมมติฐาน # 1 จะใช้กับส่วนของโค้ดที่ไม่เรียกใช้ฟังก์ชันเท่านั้น
2. สมมติว่าตัวแปรไม่ได้ถูกแก้ไขโดยกิจกรรมแบบอะซิงโครนัสหรือพร้อมกัน
3. สมมติว่าคอมไพลเลอร์กำหนดเฉพาะว่าตัวแปรสามารถแก้ไขได้หรือไม่ไม่ใช่ว่าจะถูกแก้ไข กล่าวอีกนัยหนึ่งคอมไพเลอร์กำลังทำการวิเคราะห์แบบคงที่เท่านั้น
4. สมมติว่าคอมไพเลอร์กำลังพิจารณาเฉพาะโค้ดที่ทำงานได้อย่างถูกต้องเท่านั้น (ไม่พิจารณาการโอเวอร์รัน / อันเดอร์อาเรย์ตัวชี้ที่ไม่ดี ฯลฯ )

ในบริบทของการออกแบบคอมไพเลอร์ฉันคิดว่าสมมติฐานที่ 1,3,4 มีความหมายที่สมบูรณ์แบบในมุมมองของผู้เขียนคอมไพเลอร์ในบริบทของความถูกต้องของรหัสและ / หรือการเพิ่มประสิทธิภาพโค้ด สมมติฐานที่ 2 มีเหตุผลในกรณีที่ไม่มีคำหลักที่ผันผวน และสมมติฐานเหล่านี้ยังมุ่งเน้นไปที่คำถามมากพอที่จะทำให้การตัดสินคำตอบที่เสนอมีความชัดเจนมากขึ้น :-)

จากสมมติฐานเหล่านั้นสาเหตุสำคัญที่ทำให้ไม่สามารถสันนิษฐาน const-ness ได้เนื่องจากตัวแปรนามแฝง คอมไพเลอร์ไม่สามารถทราบได้ว่าตัวแปรอื่นชี้ไปที่ตัวแปร const หรือไม่ การใช้นามแฝงอาจเกิดจากฟังก์ชันอื่นในหน่วยคอมไพเลอร์เดียวกันซึ่งในกรณีนี้คอมไพลเลอร์สามารถค้นหาฟังก์ชันต่างๆและใช้แผนผังการเรียกเพื่อกำหนดแบบคงที่ว่าการตั้งนามแฝงอาจเกิดขึ้นได้ แต่ถ้าการตั้งนามแฝงเกิดจากไลบรารีหรือรหัสแปลกปลอมอื่น ๆ คอมไพเลอร์จะไม่มีทางทราบได้ว่ามีการกำหนดชื่อตัวแปรหรือไม่

คุณสามารถโต้แย้งได้ว่าหากตัวแปร / อาร์กิวเมนต์ถูกทำเครื่องหมายเป็น const ก็ไม่ควรมีการเปลี่ยนแปลงผ่านนามแฝง แต่สำหรับผู้เขียนคอมไพเลอร์นั้นค่อนข้างเสี่ยง แม้แต่โปรแกรมเมอร์ที่เป็นมนุษย์อาจมีความเสี่ยงในการประกาศตัวแปร const ซึ่งเป็นส่วนหนึ่งของโครงการขนาดใหญ่ที่เขาไม่ทราบพฤติกรรมของทั้งระบบหรือ OS หรือไลบรารีเพื่อให้ทราบว่าตัวแปรได้รับจริง ' t เปลี่ยน.

แม้ว่าจะมีการประกาศตัวแปรconstแต่ก็ไม่ได้หมายความว่าโค้ดที่เขียนไม่ดีบางตัวสามารถเขียนทับได้

//   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;
}

เอาต์พุต:

1
2

หากต้องการขยายความคิดเห็นของฉันข้อความในหนังสือเล่มนั้นไม่ชัดเจนซึ่งทำให้ปัญหาสับสน

ตามที่ฉันแสดงความคิดเห็นหนังสือเล่มนั้นพยายามจะพูดว่า "ขอให้มีลิงจำนวนไม่ จำกัด เพื่อเขียนทุกฟังก์ชัน C ++ ที่เป็นไปได้ซึ่งสามารถเขียนได้จะมีบางกรณีที่ถ้าเราเลือกตัวแปรที่ (ฟังก์ชันเฉพาะบางอย่างที่ลิงเขียน) ใช้เราไม่สามารถสรุปได้ว่าฟังก์ชันจะเปลี่ยนตัวแปรนั้นหรือไม่ "

แน่นอนสำหรับบางฟังก์ชั่น (แม้กระทั่งหลายอย่าง) ในแอปพลิเคชันใด ๆ สิ่งนี้สามารถกำหนดได้โดยคอมไพเลอร์และทำได้ง่ายมาก แต่ไม่ใช่สำหรับทุกคน (หรือจำเป็นที่สุด)

ฟังก์ชันนี้สามารถวิเคราะห์ได้อย่างง่ายดาย:

static int global;

void foo()
{
}

"foo" ไม่แก้ไข "global" อย่างชัดเจน มันไม่ได้ปรับเปลี่ยนอะไรเลยและคอมไพเลอร์สามารถทำงานนี้ได้อย่างง่ายดาย

ฟังก์ชันนี้ไม่สามารถวิเคราะห์ได้:

static int global;

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

เนื่องจากการกระทำของ "foo" ขึ้นอยู่กับค่าที่สามารถเปลี่ยนแปลงได้ในขณะรันไทม์จึงไม่สามารถระบุได้ในขณะคอมไพล์ว่าจะแก้ไข "global" หรือไม่

แนวคิดทั้งหมดนี้เข้าใจง่ายกว่าที่นักวิทยาศาสตร์คอมพิวเตอร์กำหนดไว้ หากฟังก์ชันสามารถทำสิ่งที่แตกต่างไปจากสิ่งที่สามารถเปลี่ยนแปลงได้ในขณะรันไทม์คุณจะไม่สามารถคำนวณได้ว่าจะทำอะไรจนกว่าจะทำงานและทุกครั้งที่เรียกใช้ฟังก์ชันอาจทำบางอย่างที่แตกต่างออกไป ไม่ว่าจะเป็นไปไม่ได้ที่พิสูจน์ได้หรือไม่ก็เป็นไปไม่ได้อย่างชัดเจน