เหตุใด C ++ จึงมี 'พฤติกรรมที่ไม่ได้กำหนด' (UB) และภาษาอื่น ๆ เช่น C # หรือ Java ไม่

โพสต์สแต็คโอเวอร์โฟลว์นี้แสดงรายการสถานการณ์ที่ค่อนข้างครอบคลุมซึ่งข้อกำหนดภาษา C / C ++ ประกาศว่าเป็น 'พฤติกรรมที่ไม่ได้กำหนด' อย่างไรก็ตามฉันต้องการเข้าใจว่าทำไมภาษาสมัยใหม่อื่น ๆ เช่น C # หรือ Java ไม่มีแนวคิดของ 'พฤติกรรมที่ไม่ได้กำหนด' มันหมายความว่าผู้ออกแบบคอมไพเลอร์สามารถควบคุมสถานการณ์ที่เป็นไปได้ทั้งหมด (C # และ Java) หรือไม่ (C และ C ++)?

พฤติกรรมที่ไม่ได้กำหนดเป็นหนึ่งในสิ่งเหล่านั้นที่ได้รับการยอมรับว่าเป็นความคิดที่ไม่ดีมากเฉพาะในการหวนกลับ

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

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

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

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

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

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

ตัวอย่างเช่นถ้าคุณจัดสรรอาร์เรย์ใน C ข้อมูลจะไม่ถูกกำหนด ใน Java ไบต์ทั้งหมดต้องเริ่มต้นเป็น 0 (หรือค่าที่ระบุอื่น ๆ ) ซึ่งหมายความว่ารันไทม์จะต้องผ่านการดำเนินการอาร์เรย์ (O (n)) ในขณะที่ C สามารถดำเนินการจัดสรรในทันที ดังนั้น C จะเร็วขึ้นสำหรับการดำเนินการดังกล่าว

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

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

ดูhttp://blog.llvm.org/2011/05/what-every-c-programmer-should-know.htmlดู

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

จำนวนเต็มมากเกินที่ลงนามแล้ว: หากการคำนวณทางคณิตศาสตร์เกี่ยวกับการพิมพ์ 'int' (ตัวอย่าง) ล้นผลลัพธ์จะไม่ได้กำหนด ตัวอย่างหนึ่งคือ "INT_MAX + 1" ไม่รับประกันว่าจะเป็น INT_MIN ลักษณะการทำงานนี้ช่วยให้คลาสของการปรับให้เหมาะสมบางอย่างที่มีความสำคัญสำหรับรหัสบางอย่าง ตัวอย่างเช่นการรู้ว่า INT_MAX + 1 ไม่ได้ถูกกำหนดอนุญาตให้ปรับ "X + 1> X" เป็น "true" ได้อย่างเหมาะสม การรู้การคูณ "ไม่สามารถ" ล้น (เพราะการทำเช่นนั้นจะไม่ได้กำหนด) ช่วยให้การเพิ่มประสิทธิภาพ "X * 2/2" เป็น "X" แม้ว่าสิ่งเหล่านี้อาจดูไม่สำคัญ แต่สิ่งต่าง ๆ เหล่านี้มักถูกเปิดเผยโดยการขยายตัวแบบอินไลน์และมาโคร การปรับให้เหมาะสมที่สำคัญยิ่งขึ้นที่สิ่งนี้อนุญาตสำหรับลูป "<=" เช่นนี้:

for (i = 0; i <= N; ++i) { ... }

ในลูปนี้คอมไพเลอร์สามารถสันนิษฐานได้ว่าลูปจะวนซ้ำ N + 1 เท่าหาก "i" ไม่ได้ถูกกำหนดบนโอเวอร์โฟลว์ซึ่งอนุญาตให้ลูปการปรับการลูปในวงกว้างให้ตรงกันในทางกลับกันหากตัวแปรถูกกำหนด ล้อมรอบโอเวอร์โฟลว์แล้วคอมไพเลอร์จะต้องสมมติว่าลูปอาจไม่มีที่สิ้นสุด (ซึ่งเกิดขึ้นหาก N คือ INT_MAX) - ซึ่งจะปิดใช้งานการปรับลูปที่สำคัญเหล่านี้ โดยเฉพาะอย่างยิ่งสิ่งนี้มีผลต่อแพลตฟอร์ม 64 บิตเนื่องจากรหัสจำนวนมากใช้ "int" เป็นตัวแปรเหนี่ยวนำ

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

Java พยายามเป็นภาษาที่ปลอดภัยและง่ายกว่า C ++ มาก Java กำหนดความหมายของภาษาในแง่ของเครื่องเสมือนอย่างละเอียด สิ่งนี้ทำให้พื้นที่เล็ก ๆ น้อย ๆ สำหรับพฤติกรรมที่ไม่ได้กำหนดในทางกลับกันมันทำให้ข้อกำหนดที่อาจเป็นเรื่องยากสำหรับการใช้งานจาวาที่จะทำ (เช่นการมอบหมายการอ้างอิงนั้นต้องเป็นอะตอมมิก ที่ Java รองรับการดำเนินการที่อาจไม่ปลอดภัยพวกเขามักจะถูกตรวจสอบโดยเครื่องเสมือนที่รันไทม์ (ตัวอย่างเช่นบาง cast)

ภาษา JVM และ. NET มีความง่าย:

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

มีจุดที่ดีสำหรับการเลือกว่า:

1. การเขียนโปรแกรมระบบเป็นเกมที่แตกต่างกันอย่างสิ้นเชิงและการเพิ่มประสิทธิภาพของการเขียนโปรแกรมแอพพลิเคชั่นอย่างไม่น่าเชื่อแทนนั้นสมเหตุสมผล
2. เป็นที่ยอมรับว่ามีฮาร์ดแวร์ที่แปลกใหม่น้อยกว่าตลอดเวลา แต่ระบบฝังตัวเล็ก ๆ อยู่ที่นี่เพื่ออยู่ต่อ
3. GC เหมาะอย่างยิ่งสำหรับทรัพยากรที่ไม่สามารถเข้ากันได้และซื้อขายพื้นที่เพิ่มเติมเพื่อประสิทธิภาพที่ดี และการกำหนดค่าเริ่มต้นบังคับส่วนใหญ่ (แต่ไม่เกือบทั้งหมด) สามารถปรับให้เหมาะสมได้
4. มีข้อได้เปรียบในการแข่งขันที่มากขึ้น แต่คณะกรรมการหมายถึงการประนีประนอม
5. ทุกคนขอบเขตการตรวจสอบ- ทำเพิ่มขึ้นถึงแม้ว่าส่วนใหญ่สามารถที่ดีที่สุดออกไป การตรวจสอบตัวชี้ Null ส่วนใหญ่สามารถทำได้โดยการดักจับการเข้าถึงสำหรับค่าใช้จ่ายเป็นศูนย์ด้วยพื้นที่ที่อยู่เสมือนแม้ว่าการเพิ่มประสิทธิภาพยังคงถูกยับยั้ง

เมื่อมีการระบุ escape-hatches ผู้ที่เชิญพฤติกรรมที่ไม่ได้กำหนดเต็มรูปแบบกลับมา แต่อย่างน้อยพวกมันมักใช้ในการเหยียดสั้น ๆ ไม่กี่ครั้งเท่านั้นซึ่งง่ายต่อการตรวจสอบด้วยตนเอง

Java และ C # โดดเด่นด้วยผู้ขายที่โดดเด่นอย่างน้อยในช่วงต้นของการพัฒนาของพวกเขา (Sun และ Microsoft ตามลำดับ) C และ C ++ แตกต่างกัน พวกเขามีการใช้งานการแข่งขันหลายครั้งตั้งแต่ต้น C โดยเฉพาะวิ่งบนแพลตฟอร์มฮาร์ดแวร์ที่แปลกใหม่เช่นกัน เป็นผลให้มีการเปลี่ยนแปลงระหว่างการใช้งาน คณะกรรมการ ISO ที่มาตรฐาน C และ C ++ สามารถเห็นด้วยกับตัวหารร่วมขนาดใหญ่ แต่ที่ขอบที่การใช้งานแตกต่างมาตรฐานออกจากห้องสำหรับการดำเนินงาน

นี่ก็เป็นเพราะการเลือกพฤติกรรมหนึ่งอาจมีราคาแพงในสถาปัตยกรรมฮาร์ดแวร์ที่มีอคติต่อตัวเลือกอื่น - endianness เป็นตัวเลือกที่ชัดเจน

เหตุผลที่แท้จริงเกิดขึ้นจากความแตกต่างพื้นฐานในเจตนาระหว่าง C และ C ++ ในมือข้างหนึ่งและ Java และ C # (สำหรับตัวอย่างเพียงสองสาม) ที่อื่น ๆ ด้วยเหตุผลทางประวัติศาสตร์การสนทนาส่วนใหญ่ที่นี่พูดถึง C มากกว่า C ++ แต่ (อย่างที่คุณอาจทราบแล้ว) C ++ เป็นผู้สืบทอดโดยตรงของ C ดังนั้นสิ่งที่บอกว่าเกี่ยวกับ C ใช้กับ C ++ อย่างเท่าเทียมกัน

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

เพื่อให้บรรลุผลนั้น C จำเป็นต้องให้การเข้าถึงฮาร์ดแวร์ในระดับใกล้เคียงกับภาษาแอสเซมบลี PDP-11 (ตัวอย่างหนึ่ง) แมป I / O ที่ลงทะเบียนไปยังที่อยู่ที่เฉพาะเจาะจง ตัวอย่างเช่นคุณจะอ่านตำแหน่งหน่วยความจำหนึ่งแห่งเพื่อตรวจสอบว่ามีการกดคีย์บนคอนโซลระบบหรือไม่ มีการตั้งค่าบิตหนึ่งในตำแหน่งนั้นเมื่อมีข้อมูลรอการอ่าน จากนั้นคุณจะอ่านไบต์จากตำแหน่งอื่นที่ระบุเพื่อดึงรหัส ASCII ของคีย์ที่ถูกกด

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

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

แน่นอนว่านี่เป็นปัญหาที่ค่อนข้างร้ายแรง: ไม่ใช่ว่าทุกเครื่องในโลกจะมีหน่วยความจำวางเหมือนกับ PDP-11 ตั้งแต่ต้นปี 1970 ดังนั้นเมื่อคุณใช้จำนวนเต็มนั้นให้แปลงเป็นตัวชี้แล้วอ่านหรือเขียนผ่านตัวชี้นั้นไม่มีใครสามารถรับประกันได้อย่างสมเหตุสมผลเกี่ยวกับสิ่งที่คุณจะได้รับ สำหรับตัวอย่างที่ชัดเจนการอ่านและการเขียนอาจแมปเพื่อแยกการลงทะเบียนในฮาร์ดแวร์ดังนั้นคุณ (ตรงกันข้ามกับหน่วยความจำปกติ) ถ้าคุณเขียนอะไรแล้วลองอ่านกลับสิ่งที่คุณอ่านอาจไม่ตรงกับสิ่งที่คุณเขียน

ฉันเห็นความเป็นไปได้สองสามอย่างที่เหลืออยู่:

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

ในบรรดาสิ่งเหล่านี้ 1 ดูเหมือนว่าผิดปกติมากพอที่จะไม่คุ้มค่ากับการอภิปรายเพิ่มเติม 2 เป็นการทิ้งความตั้งใจพื้นฐานของภาษาออกไป นั่นทำให้ตัวเลือกที่สามเป็นหลักอย่างเดียวเท่านั้นที่พวกเขาสามารถพิจารณาได้อย่างสมเหตุสมผล

จุดอื่นที่เกิดขึ้นค่อนข้างบ่อยคือขนาดของประเภทจำนวนเต็ม C รับตำแหน่ง "" ที่intควรเป็นขนาดธรรมชาติที่แนะนำโดยสถาปัตยกรรม ดังนั้นถ้าฉันเขียนโปรแกรม VAX แบบint32 บิตน่าจะเป็น 32 บิต แต่ถ้าฉันเขียนโปรแกรม Univac แบบint36 บิตน่าจะเป็น 36 บิต (เป็นต้น) อาจไม่สมเหตุสมผล (และอาจไม่สามารถทำได้) ในการเขียนระบบปฏิบัติการสำหรับคอมพิวเตอร์ 36 บิตโดยใช้ชนิดเท่านั้นที่รับประกันว่าจะมีขนาดทวีคูณ 8 บิต บางทีฉันอาจเป็นเพียงผิวเผิน แต่ดูเหมือนว่าถ้าฉันกำลังเขียนระบบปฏิบัติการสำหรับเครื่อง 36 บิตฉันอาจต้องการใช้ภาษาที่รองรับชนิด 36 บิต

จากมุมมองของภาษาสิ่งนี้นำไปสู่พฤติกรรมที่ไม่ได้กำหนดเพิ่มเติม ถ้าฉันใช้ค่ามากที่สุดที่พอดีกับ 32 บิตจะเกิดอะไรขึ้นเมื่อฉันเพิ่ม 1 สำหรับฮาร์ดแวร์แบบ 32 บิตโดยทั่วไปมันจะพลิก (หรืออาจจะเป็นความผิดพลาดของฮาร์ดแวร์บางอย่าง) ในทางตรงกันข้ามถ้ามันทำงานบนฮาร์ดแวร์ 36 บิตมันจะ ... เพิ่มอีกอัน หากภาษากำลังจะสนับสนุนการเขียนระบบปฏิบัติการคุณไม่สามารถรับประกันได้ว่าพฤติกรรมใด - คุณต้องยอมให้ทั้งขนาดของประเภทและพฤติกรรมของการไหลล้นแตกต่างกันไปในแต่ละแบบ

Java และ C # สามารถเพิกเฉยได้ทั้งหมด พวกเขาไม่ได้มีวัตถุประสงค์เพื่อสนับสนุนการเขียนระบบปฏิบัติการ คุณมีทางเลือกสองทาง หนึ่งคือการทำให้ฮาร์ดแวร์สนับสนุนสิ่งที่พวกเขาต้องการ - เนื่องจากพวกเขาต้องการประเภทที่ 8, 16, 32 และ 64 บิตเพียงแค่สร้างฮาร์ดแวร์ที่รองรับขนาดเหล่านั้น ความเป็นไปได้อื่น ๆ ที่ชัดเจนคือภาษานั้นจะทำงานบนซอฟต์แวร์อื่นที่มีสภาพแวดล้อมที่พวกเขาต้องการโดยไม่คำนึงถึงสิ่งที่ฮาร์ดแวร์พื้นฐานต้องการ

ในกรณีส่วนใหญ่นี่ไม่ใช่ตัวเลือก / หรือตัวเลือกจริงๆ แต่การใช้งานจำนวนมากทำทั้งสองอย่างเล็กน้อย ปกติแล้วคุณจะรัน Java บน JVM ที่รันบนระบบปฏิบัติการ บ่อยครั้งที่ระบบปฏิบัติการเขียนใน C และ JVM ใน C ++ หาก JVM ทำงานบนซีพียู ARM มีโอกาสค่อนข้างดีที่ซีพียูจะรวมส่วนขยาย Jazelle ของ ARM เพื่อปรับแต่งฮาร์ดแวร์ให้ใกล้เคียงกับความต้องการของจาวามากขึ้นดังนั้นความต้องการซอฟต์แวร์ในจาวาน้อยลงและโค้ดจาวาทำงานได้เร็วขึ้น ช้าๆ)

สรุป

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

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

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

C ++ และ c ทั้งสองมีมาตรฐานอธิบาย (รุ่น ISO อยู่แล้ว)

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

Java และ C # (หรือ Visual C # ซึ่งผมถือว่าคุณหมายถึง) มีกำหนดมาตรฐาน พวกเขาบอกคุณว่ามีอะไรในภาษาที่แน่นอนล่วงหน้าวิธีการทำงานและสิ่งที่ถือว่าเป็นพฤติกรรมที่ได้รับอนุญาต

สำคัญกว่านั้น Java จริง ๆ แล้วมี "การใช้งานอ้างอิง" ใน Open-JDK (ฉันคิดว่าRoslynนับเป็นการนำการอ้างอิง Visual C # ไปใช้ แต่ไม่พบแหล่งที่มาสำหรับสิ่งนั้น)

ในกรณีของ Java หากมีความกำกวมในมาตรฐานและ Open-JDK จะเป็นวิธีที่แน่นอน วิธีที่ Open-JDK เป็นมาตรฐาน

พฤติกรรมที่ไม่ได้กำหนดช่วยให้คอมไพเลอร์สามารถสร้างโค้ดที่มีประสิทธิภาพมากในสถาปัตยกรรมที่หลากหลาย คำตอบของ Erik กล่าวถึงการปรับให้เหมาะสม แต่มันไปไกลกว่านั้น

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

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

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

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

ภาษาที่ใหม่กว่าเช่น Java และ C # ที่ต้องการกำจัดพฤติกรรมที่ไม่ได้กำหนดเหนือประสิทธิภาพดิบ

เรียกได้ว่า Java ก็มีเช่นกัน สมมติว่าคุณให้ผู้เปรียบเทียบไม่ถูกต้องกับ Arrays.sort มันสามารถโยนยกเว้นมันตรวจพบมัน มิฉะนั้นจะเรียงลำดับอาร์เรย์ด้วยวิธีที่ไม่รับประกันว่าจะเป็นแบบใดโดยเฉพาะ

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

C ++ เป็นไปต่อไปเพื่อให้สถานการณ์ที่ไม่ได้กำหนดเพิ่มเติม (หรือมากกว่า Java ตัดสินใจที่จะกำหนดการดำเนินการเพิ่มเติม) และมีชื่อสำหรับมัน