ในทางปฏิบัติทำไมคอมไพเลอร์ที่ต่างกันจึงคำนวณค่า int x = ++ i + ++ i ต่างกัน?

Question 1

พิจารณารหัสนี้:

int i = 1;
int x = ++i + ++i;

เรามีการคาดเดาว่าคอมไพเลอร์อาจทำอะไรกับโค้ดนี้โดยสมมติว่าคอมไพเลอร์

ทั้ง++iผลตอบแทนที่เกิดใน2x=4
หนึ่งใน++iผลตอบแทน2และผลตอบแทนอื่น ๆ ที่มีผลในการ3x=5
ทั้ง++iผลตอบแทนที่เกิดใน3x=6

สำหรับฉันอย่างที่สองดูเหมือนจะเป็นไปได้มากที่สุด หนึ่งในสอง++ตัวดำเนินการถูกดำเนินการด้วยi = 1ค่าที่iเพิ่มขึ้นและผลลัพธ์2จะถูกส่งกลับ จากนั้นตัว++ดำเนินการที่สองจะถูกดำเนินการด้วยi = 2ค่าที่iเพิ่มขึ้นและผลลัพธ์3จะถูกส่งกลับ แล้ว2และมีการเพิ่มเข้าด้วยกันเพื่อให้35

แต่ผมวิ่งรหัสนี้ใน Visual Studio 6และผลที่ได้ก็คือ ฉันพยายามทำความเข้าใจคอมไพเลอร์ให้ดีขึ้นและฉันสงสัยว่าอะไรอาจนำไปสู่ผลลัพธ์ของ6ไฟล์. ฉันเดาเพียงอย่างเดียวคือโค้ดสามารถทำงานพร้อมกัน "ในตัว" บางอย่างได้ สอง++ผู้ประกอบการถูกเรียกว่าแต่ละคนเพิ่มขึ้นก่อนที่จะกลับมาอีกแล้วพวกเขาทั้งสองกลับi 3สิ่งนี้จะขัดแย้งกับความเข้าใจของฉันเกี่ยวกับ call stack และจำเป็นต้องอธิบายออกไป

สิ่งใด (ที่สมเหตุสมผล) ที่C++คอมไพเลอร์สามารถทำได้ซึ่งจะนำไปสู่ผลลัพธ์4หรือผลลัพธ์หรือ6?

บันทึก

ตัวอย่างนี้เป็นตัวอย่างของพฤติกรรมที่ไม่ได้กำหนดไว้ในการเขียนโปรแกรมของ Bjarne Stroustrup: หลักการและการปฏิบัติโดยใช้ C ++ (C ++ 14)

ดูความคิดเห็นของอบเชย

Question 2

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

รหัส

int i = 1;
int x = ++i + ++i;

ประกอบด้วยคำแนะนำต่อไปนี้:

1. store 1 in i
2. read i as tmp1
3. add 1 to tmp1
4. store tmp1 in i
5. read i as tmp2
6. read i as tmp3
7. add 1 to tmp3
8. store tmp3 in i
9. read i as tmp4
10. add tmp2 and tmp4, as tmp5
11. store tmp5 in x

แต่ถึงแม้จะเป็นรายการลำดับเลขตามที่ฉันเขียน แต่ก็มีการอ้างอิงการสั่งซื้อเพียงไม่กี่รายการที่นี่: 1-> 2-> 3-> 4-> 5-> 10-> 11 และ 1-> 6-> 7- > 8-> 9-> 10-> 11 ต้องอยู่ตามลำดับญาติ นอกเหนือจากนั้นคอมไพลเลอร์สามารถจัดลำดับใหม่ได้อย่างอิสระและอาจกำจัดความซ้ำซ้อน

ตัวอย่างเช่นคุณสามารถจัดลำดับรายการดังนี้:

1. store 1 in i
2. read i as tmp1
6. read i as tmp3
3. add 1 to tmp1
7. add 1 to tmp3
4. store tmp1 in i
8. store tmp3 in i
5. read i as tmp2
9. read i as tmp4
10. add tmp2 and tmp4, as tmp5
11. store tmp5 in x

ทำไมคอมไพเลอร์ถึงทำเช่นนี้ได้? เนื่องจากไม่มีการจัดลำดับผลข้างเคียงของการเพิ่มขึ้น แต่ตอนนี้คอมไพเลอร์สามารถทำให้ง่ายขึ้น: ตัวอย่างเช่นมีร้านค้าที่ตายแล้วใน 4: ค่าจะถูกเขียนทับทันที นอกจากนี้ tmp2 และ tmp4 ก็เหมือนกัน

1. store 1 in i
2. read i as tmp1
6. read i as tmp3
3. add 1 to tmp1
7. add 1 to tmp3
8. store tmp3 in i
5. read i as tmp2
10. add tmp2 and tmp2, as tmp5
11. store tmp5 in x

และตอนนี้ทุกอย่างที่เกี่ยวข้องกับ tmp1 เป็นรหัสตาย: ไม่เคยใช้ และการอ่านซ้ำของฉันก็สามารถกำจัดได้เช่นกัน:

1. store 1 in i
6. read i as tmp3
7. add 1 to tmp3
8. store tmp3 in i
10. add tmp3 and tmp3, as tmp5
11. store tmp5 in x

ดูรหัสนี้จะสั้นกว่ามาก เครื่องมือเพิ่มประสิทธิภาพมีความสุข โปรแกรมเมอร์ไม่ได้เป็นเพราะฉันเพิ่มขึ้นเพียงครั้งเดียว อ๊ะ.

ลองดูอย่างอื่นที่คอมไพเลอร์สามารถทำได้แทน: กลับไปใช้เวอร์ชันดั้งเดิมกันเถอะ

1. store 1 in i
2. read i as tmp1
3. add 1 to tmp1
4. store tmp1 in i
5. read i as tmp2
6. read i as tmp3
7. add 1 to tmp3
8. store tmp3 in i
9. read i as tmp4
10. add tmp2 and tmp4, as tmp5
11. store tmp5 in x

คอมไพเลอร์สามารถจัดลำดับใหม่ได้ดังนี้:

1. store 1 in i
2. read i as tmp1
3. add 1 to tmp1
4. store tmp1 in i
6. read i as tmp3
7. add 1 to tmp3
8. store tmp3 in i
5. read i as tmp2
9. read i as tmp4
10. add tmp2 and tmp4, as tmp5
11. store tmp5 in x

แล้วสังเกตอีกครั้งว่าฉันอ่านสองครั้งดังนั้นให้กำจัดหนึ่งในนั้น:

1. store 1 in i
2. read i as tmp1
3. add 1 to tmp1
4. store tmp1 in i
6. read i as tmp3
7. add 1 to tmp3
8. store tmp3 in i
5. read i as tmp2
10. add tmp2 and tmp2, as tmp5
11. store tmp5 in x

เป็นสิ่งที่ดี แต่สามารถไปได้ไกลกว่านี้: สามารถใช้ tmp1 ซ้ำได้:

1. store 1 in i
2. read i as tmp1
3. add 1 to tmp1
4. store tmp1 in i
6. read i as tmp1
7. add 1 to tmp1
8. store tmp1 in i
5. read i as tmp2
10. add tmp2 and tmp2, as tmp5
11. store tmp5 in x

จากนั้นสามารถกำจัดการอ่านซ้ำของ i ใน 6:

1. store 1 in i
2. read i as tmp1
3. add 1 to tmp1
4. store tmp1 in i
7. add 1 to tmp1
8. store tmp1 in i
5. read i as tmp2
10. add tmp2 and tmp2, as tmp5
11. store tmp5 in x

ตอนนี้ 4 เป็นร้านค้าที่ตายแล้ว:

1. store 1 in i
2. read i as tmp1
3. add 1 to tmp1
7. add 1 to tmp1
8. store tmp1 in i
5. read i as tmp2
10. add tmp2 and tmp2, as tmp5
11. store tmp5 in x

และตอนนี้ 3 และ 7 สามารถรวมเป็นคำสั่งเดียว:

1. store 1 in i
2. read i as tmp1
3+7. add 2 to tmp1
8. store tmp1 in i
5. read i as tmp2
10. add tmp2 and tmp2, as tmp5
11. store tmp5 in x

กำจัดชั่วคราวสุดท้าย:

1. store 1 in i
2. read i as tmp1
3+7. add 2 to tmp1
8. store tmp1 in i
10. add tmp1 and tmp1, as tmp5
11. store tmp5 in x

และตอนนี้คุณได้รับผลลัพธ์ที่ Visual C ++ มอบให้คุณแล้ว

โปรดทราบว่าในทั้งสองเส้นทางการเพิ่มประสิทธิภาพการอ้างอิงลำดับที่สำคัญจะถูกเก็บรักษาไว้ตราบเท่าที่คำแนะนำไม่ได้ถูกลบออกเพื่อไม่ทำอะไรเลย

Question 3

แม้ว่านี่จะเป็น UB (ตามที่ OP โดยนัย) ต่อไปนี้เป็นวิธีสมมติที่คอมไพเลอร์จะได้ผลลัพธ์ 3 ทั้งสามจะให้ถูกต้องเหมือนกันxผลถ้าใช้กับที่แตกต่างกันตัวแปรแทนหนึ่งเดียวกันint i = 1, j = 1;i

ทั้ง ++ ฉันส่งคืน 2 ผลลัพธ์เป็น x = 4

int i = 1;
int i1 = i, i2 = i;   // i1 = i2 = 1
++i1;                 // i1 = 2
++i2;                 // i2 = 2
int x = i1 + i2;      // x = 4

หนึ่ง ++ ฉันส่งคืน 2 และอีกตัวส่งคืน 3 ทำให้ x = 5

int i = 1;
int i1 = ++i;           // i1 = 2
int i2 = ++i;           // i2 = 3
int x = i1 + i2;        // x = 5

ทั้ง ++ ฉันส่งคืน 3 ทำให้ x = 6

int i = 1;
int &i1 = i, &i2 = i;
++i1;                   // i = 2
++i2;                   // i = 3
int x = i1 + i2;        // x = 6

Question 4

สำหรับฉันอย่างที่สองดูเหมือนจะเป็นไปได้มากที่สุด

ฉันกำลังเลือกตัวเลือก # 4: ทั้งสองอย่าง ++iเกิดขึ้นพร้อมกัน

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

ฉันสามารถเห็นสภาพการแข่งขันที่ก่อให้เกิดพฤติกรรมที่ไม่ได้กำหนดหรือความผิดพลาดของบัสเนื่องจากการขัดแย้งของหน่วยความจำเดียวกัน - ทั้งหมดได้รับอนุญาตเนื่องจาก coder ละเมิดสัญญา C ++ ดังนั้น UB

คำถามของฉันคือสิ่งที่ (สมเหตุสมผล) ที่คอมไพเลอร์ C ++ สามารถทำสิ่งนั้นจะนำไปสู่ผลลัพธ์ของ 4 หรือผลลัพธ์หรือ 6

มันทำได้แต่อย่านับรวมในนั้น

อย่าใช้++i + ++iหรือคาดหวังผลลัพธ์ที่สมเหตุสมผล

Question 5

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

เพิ่มขึ้น i
เพิ่มขึ้น i
เพิ่มi+i

เมื่อiเพิ่มขึ้นสองครั้งค่าของมันจะเป็น 3 และเมื่อรวมเข้าด้วยกันผลรวมจะเป็น 6

สำหรับการตรวจสอบให้พิจารณาว่านี่เป็นฟังก์ชัน C ++:

int dblInc ()
{
    int i = 1;
    int x = ++i + ++i;
    return x;   
}

นี่คือรหัสแอสเซมบลีที่ฉันได้รับจากการรวบรวมฟังก์ชันนั้นโดยใช้คอมไพเลอร์ GNU C ++ เวอร์ชันเก่า (win32, gcc เวอร์ชัน 3.4.2 (mingw-special)) ไม่มีการเพิ่มประสิทธิภาพแบบแฟนซีหรือมัลติเธรดเกิดขึ้นที่นี่:

__Z6dblIncv:
    push    ebp
    mov ebp, esp
    sub esp, 8
    mov DWORD PTR [ebp-4], 1
    lea eax, [ebp-4]
    inc DWORD PTR [eax]
    lea eax, [ebp-4]
    inc DWORD PTR [eax]
    mov eax, DWORD PTR [ebp-4]
    add eax, DWORD PTR [ebp-4]
    mov DWORD PTR [ebp-8], eax
    mov eax, DWORD PTR [ebp-8]
    leave
    ret

โปรดทราบว่าตัวแปรท้องถิ่นนั่งอยู่บนสแต็คในเวลาเพียงหนึ่งสถานที่เดียวที่อยู่i [ebp-4]ตำแหน่งนั้นจะเพิ่มขึ้นสองครั้ง (ในบรรทัดที่ 5-8 ของฟังก์ชันการประกอบรวมทั้งเห็นได้ชัดว่ามีการโหลดแอดเดรสนั้นซ้ำซ้อนeax) จากนั้นในบรรทัดที่ 9-10 ค่านั้นจะถูกโหลดเข้าไปeaxแล้วเพิ่มเข้าไปeax(นั่นคือคำนวณกระแสi + i) จากนั้นจะคัดลอกซ้ำซ้อนไปที่สแต็กและกลับไปที่eaxเป็นค่าส่งคืน (ซึ่งจะเห็นได้ชัดว่าเป็น 6)

อาจเป็นเรื่องที่น่าสนใจที่จะดูมาตรฐาน C ++ (ที่นี่เป็นมาตรฐานเก่า: ISO / IEC 14882: 1998 (E)) ซึ่งระบุไว้สำหรับนิพจน์ส่วน 5.4:

ยกเว้นในกรณีที่ระบุไว้ลำดับของการประเมินตัวถูกดำเนินการของแต่ละตัวดำเนินการและนิพจน์ย่อยของแต่ละนิพจน์และลำดับของผลข้างเคียงที่เกิดขึ้นไม่ได้ระบุไว้

ด้วยเชิงอรรถ:

ไม่ได้ระบุลำดับความสำคัญของตัวดำเนินการโดยตรง แต่สามารถได้มาจากไวยากรณ์

ในจุดนั้นจะมีตัวอย่างพฤติกรรมที่ไม่ระบุสองตัวอย่างซึ่งทั้งสองอย่างเกี่ยวข้องกับตัวดำเนินการส่วนเพิ่ม (ซึ่งหนึ่งในนั้นคือi = ++i + 1:)

ตอนนี้ถ้าใครต้องการก็สามารถ: สร้างคลาส wrapper จำนวนเต็ม (เช่น Java Integer); ฟังก์ชันโอเวอร์โหลดoperator+และoperator++ส่งคืนอ็อบเจ็กต์ค่ากลาง และด้วยเหตุนี้จึงเขียน++iObj + ++iObjและรับมันเพื่อส่งคืนวัตถุที่ถือ 5 (ฉันไม่ได้รวมโค้ดเต็มไว้ที่นี่เพื่อความกะทัดรัด)

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

Question 6

สิ่งที่สมเหตุสมผลที่คอมไพเลอร์สามารถทำได้คือ Common Subexpression Elimination นี่เป็นการเพิ่มประสิทธิภาพทั่วไปในคอมไพเลอร์อยู่แล้ว: หากนิพจน์ย่อยเช่น(x+1)เกิดขึ้นมากกว่าหนึ่งครั้งในนิพจน์ที่ใหญ่กว่าจะต้องคำนวณเพียงครั้งเดียว เช่นในa/(x+1) + b*(x+1)ไฟล์x+1ย่อยแสดงออกสามารถคำนวณได้ครั้งเดียว

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

ผลลัพธ์อาจint x = ++i + ++i;เป็นไปint __cse = i++; int x = __cse << 1ตามนั้น (CSE ตามด้วยการลดความแรงซ้ำ)

Question 7

ในทางปฏิบัติคุณกำลังเรียกร้องพฤติกรรมที่ไม่ได้กำหนด อะไรจะเกิดขึ้นไม่ได้เป็นเพียงสิ่งที่คุณพิจารณาว่า "เหตุผล" และมักจะสิ่งที่ทำเกิดขึ้นได้ที่คุณไม่ได้พิจารณาที่เหมาะสม ทุกอย่างเป็นไปตามคำจำกัดความ "สมเหตุสมผล"

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

Downvoter: GCC ไม่เห็นด้วยกับคุณอย่างยิ่ง

Question 8

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

เดี๋ยวนะ! ไม่ชัดเจนว่าจะต้องเกิดอะไรขึ้น? นอกจากนี้ความต้องการผลของการเพิ่มที่สองเพื่อให้เห็นได้ชัดว่าเหล่านี้จะต้องเกิดขึ้นเป็นครั้งแรก แล้วเราก็ไปซ้ายไปขวาเลย ... อ๊าก! ถ้ามันง่ายมาก โชคไม่ดีที่ไม่ใช่อย่างนั้น เราไม่เดินจากซ้ายไปขวานั่นคือปัญหา

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

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

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

คอมไพเลอร์เป็นโดยใช้ถ้อยคำของมาตรฐานอนุญาตให้ให้ผลลัพธ์ใด ๆ แก่คุณแม้ว่าฉันจะคิดว่า 6 บันทึก "fuck you" จากแผนก Obnoxious โดยส่วนตัวเนื่องจากเป็นสิ่งที่ไม่คาดคิด (ถูกกฎหมายหรือไม่ การพยายามให้เซอร์ไพรส์น้อยที่สุดอยู่เสมอเป็นสิ่งที่ควรทำ!) แม้ว่าจะเห็นว่าพฤติกรรมที่ไม่ได้กำหนดมีส่วนเกี่ยวข้องอย่างไร แต่น่าเศร้าที่เราไม่สามารถโต้แย้งเกี่ยวกับ "ไม่คาดคิด" ได้ใช่ไหม

แล้วโค้ดที่คุณมีอยู่ในคอมไพเลอร์คืออะไร? ขอเสียงดังซึ่งจะแสดงให้เราเห็นว่าเราถามอย่างดี (วิงวอนด้วย-ast-dump -fsyntax-only):

ast.cpp:4:9: warning: multiple unsequenced modifications to 'i' [-Wunsequenced]
int x = ++i + ++i;
        ^     ~~
(some lines omitted)
`-CompoundStmt 0x2b3e628 <line:2:1, line:5:1>
  |-DeclStmt 0x2b3e4b8 <line:3:1, col:10>
  | `-VarDecl 0x2b3e430 <col:1, col:9> col:5 used i 'int' cinit
  |   `-IntegerLiteral 0x2b3e498 <col:9> 'int' 1
  `-DeclStmt 0x2b3e610 <line:4:1, col:18>
    `-VarDecl 0x2b3e4e8 <col:1, col:17> col:5 x 'int' cinit
      `-BinaryOperator 0x2b3e5f0 <col:9, col:17> 'int' '+'
        |-ImplicitCastExpr 0x2b3e5c0 <col:9, col:11> 'int' <LValueToRValue>
        | `-UnaryOperator 0x2b3e570 <col:9, col:11> 'int' lvalue prefix '++'
        |   `-DeclRefExpr 0x2b3e550 <col:11> 'int' lvalue Var 0x2b3e430 'i' 'int'
        `-ImplicitCastExpr 0x2b3e5d8 <col:15, col:17> 'int' <LValueToRValue>
          `-UnaryOperator 0x2b3e5a8 <col:15, col:17> 'int' lvalue prefix '++'
            `-DeclRefExpr 0x2b3e588 <col:17> 'int' lvalue Var 0x2b3e430 'i' 'int'

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

หมายเหตุคำเตือน: "การแก้ไข" i "โดยไม่ได้รับผลกระทบหลายรายการ โอ้ฟังดูไม่ดี หมายความว่าอย่างไร? [basic.exec]บอกเราเกี่ยวกับผลข้างเคียงและการจัดลำดับและจะบอกเรา (ย่อหน้าที่ 10) ว่าโดยค่าเริ่มต้นเว้นแต่จะกล่าวไว้อย่างชัดเจนการประเมินตัวถูกดำเนินการของแต่ละตัวดำเนินการและนิพจน์ย่อยของนิพจน์แต่ละรายการจะไม่เกิดขึ้นตามมา เอาละนั่นคือกรณีoperator+- ไม่มีการพูดเป็นอย่างอื่นดังนั้น ...

แต่เราสนใจเกี่ยวกับลำดับก่อนหลังไม่แน่นอนลำดับหรือไม่ตามมา? ใครอยากรู้ล่ะก็

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

Question 9

มีกฎ :

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

ดังนั้นแม้แต่ x = 100 ก็เป็นผลลัพธ์ที่ใช้ได้

สำหรับฉันผลลัพธ์ที่สมเหตุสมผลที่สุดในตัวอย่างคือ 6 เพราะเราเพิ่มค่าของ i เป็นสองเท่าและมันก็เพิ่มให้ตัวมันเอง เป็นการยากที่จะทำการบวกก่อนค่าการคำนวณจากทั้งสองด้านของ "+"

แต่นักพัฒนาคอมไพเลอร์สามารถใช้ตรรกะอื่น ๆ ได้

Question 10

ดูเหมือนว่า ++ ฉันจะส่งคืนค่า lvalue แต่ i ++ ส่งกลับค่า rvalue
ดังนั้นรหัสนี้ก็โอเค:

int i = 1;
++i = 10;
cout << i << endl;

อันนี้ไม่ใช่:

int i = 1;
i++ = 10;
cout << i << endl;

สองข้อความข้างต้นสอดคล้องกับ VisualC ++, GCC7.1.1, CLang และ Embarcadero
นั่นคือเหตุผลที่โค้ดของคุณใน VisualC ++ และ GCC7.1.1 คล้ายกับโค้ดต่อไปนี้

int i = 1;
... do something there for instance: ++i; ++i; ...
int x = i + i;

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

Question 11

โดยส่วนตัวฉันไม่เคยคาดหวังว่าคอมไพเลอร์จะส่งออก 6 ในตัวอย่างของคุณ มีคำตอบที่ดีและละเอียดสำหรับคำถามของคุณอยู่แล้ว ฉันจะลองเวอร์ชันสั้น ๆ

โดยทั่วไป++iเป็นกระบวนการ 2 ขั้นตอนในบริบทนี้:

เพิ่มมูลค่าของ i
อ่านค่าของ i

ในบริบทของ++i + ++iทั้งสองด้านของการเพิ่มอาจได้รับการประเมินในลำดับใดก็ได้ตามมาตรฐาน ซึ่งหมายความว่าการเพิ่มทั้งสองครั้งถือเป็นอิสระ นอกจากนี้ไม่มีการพึ่งพาระหว่างสองคำ การเพิ่มและการอ่านiจึงอาจแทรกสลับกันได้ สิ่งนี้ให้ลำดับที่เป็นไปได้:

การเพิ่มiสำหรับตัวถูกดำเนินการด้านซ้าย
การเพิ่มขึ้นiสำหรับตัวถูกดำเนินการด้านขวา
อ่านย้อนกลับiสำหรับตัวถูกดำเนินการด้านซ้าย
อ่านย้อนกลับiสำหรับตัวถูกดำเนินการที่ถูกต้อง
ผลรวมสอง: ให้ผล 6

ตอนนี้ที่ผมคิดเกี่ยวกับเรื่องนี้ 6 เหมาะสมที่สุดตามมาตรฐาน สำหรับผลลัพธ์ของ 4 เราจำเป็นต้องมี CPU ซึ่งก่อนอื่นอ่านiอย่างอิสระจากนั้นจึงเพิ่มและเขียนค่ากลับเข้าไปในตำแหน่งเดิม โดยทั่วไปสภาพการแข่งขัน สำหรับค่า 5 เราจำเป็นต้องมีคอมไพเลอร์ที่แนะนำจังหวะ

แต่มาตรฐานบอกว่าให้++iเพิ่มตัวแปรก่อนที่จะส่งคืนกล่าวคือก่อนที่จะเรียกใช้บรรทัดรหัสปัจจุบันจริง ตัวดำเนินการผลรวม+ต้องมีผลรวมi + iหลังจากใช้การเพิ่ม ฉันจะบอกว่า C ++ จำเป็นต้องทำงานกับตัวแปรไม่ใช่กับค่าความหมาย ดังนั้นสำหรับฉัน 6 ทำให้ตอนนี้มีความหมายมากที่สุดเนื่องจากอาศัยความหมายของภาษาไม่ใช่รูปแบบการดำเนินการของซีพียู

Question 12

#include <stdio.h>


void a1(void)
{
    int i = 1;
    int x = ++i;
    printf("i=%d\n",i);
    printf("x=%d\n",x);
    x = x + ++i;    // Here
    printf("i=%d\n",i);
    printf("x=%d\n",x);
}


void b2(void)
{
    int i = 1;
    int x = ++i;
    printf("i=%d\n",i);
    printf("x=%d\n",x);
    x = i + ++i;    // Here
    printf("i=%d\n",i);
    printf("x=%d\n",x);
}


void main(void)
{
    a1();
    // b2();
}

Question 13

ขึ้นอยู่กับการออกแบบของคอมไพเลอร์ดังนั้นคำตอบจะขึ้นอยู่กับวิธีที่คอมไพลเลอร์ถอดรหัสคำสั่งการใช้ตัวแปรที่แตกต่างกันสองตัว ++ x และ ++ y แทนเพื่อสร้างตรรกะจะเป็นทางเลือกที่ดีกว่า หมายเหตุ: ouput ขึ้นอยู่กับเวอร์ชันของภาษาเวอร์ชันล่าสุดใน ms visual studio หากมีการอัปเดตดังนั้นหากกฎมีการเปลี่ยนแปลงผลลัพธ์จะออกมา

Question 14

ลองสิ่งนี้

int i = 1;
int i1 = i, i2 = i;   // i1 = i2 = 1
++i1;                 // i1 = 2
++i2;                 // i2 = 2
int x = i1 + i2;      // x = 4

Question 15

จากลิงค์ลำดับการประเมินผล :

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

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

แต่ถ้าจุดลำดับอยู่ระหว่างนิพจน์ย่อย Exp1 และ Exp2 การคำนวณค่าและผลข้างเคียงของ Exp1 จะเรียงลำดับก่อนการคำนวณค่าทุกครั้งและผลข้างเคียงของ Exp2

Question 16

ในทางปฏิบัติคุณกำลังเรียกร้องพฤติกรรมที่ไม่ได้กำหนด อะไรจะเกิดขึ้นไม่ได้เป็นเพียงสิ่งที่คุณพิจารณาว่า "เหตุผล" และมักจะสิ่งที่จะเกิดขึ้นได้ที่คุณไม่ได้พิจารณาที่เหมาะสม ทุกอย่างเป็นไปตามคำจำกัดความ "สมเหตุสมผล"

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