เหตุใด int ที่ไม่ได้ลงนามจึงไม่สอดคล้องกับ CLS


111

เหตุใดจำนวนเต็มที่ไม่ได้ลงนามจึงไม่สอดคล้องกับ CLS

ฉันเริ่มคิดว่าข้อกำหนดประเภทมีไว้เพื่อประสิทธิภาพเท่านั้นไม่ใช่เพื่อความถูกต้อง

คำตอบ:


88

ไม่ใช่ทุกภาษาที่มีแนวคิดของ ints ที่ไม่ได้ลงนาม ตัวอย่างเช่น VB 6 ไม่มีแนวคิดเกี่ยวกับ ints ที่ไม่ได้ลงนามซึ่งฉันสงสัยว่าจะผลักดันการตัดสินใจของนักออกแบบของ VB7 / 7.1 ที่จะไม่นำไปใช้เช่นกัน (ตอนนี้นำไปใช้ใน VB8)

อ้างถึง:

http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

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

อัปเดต: ฉันสงสัยเกี่ยวกับเรื่องนี้เมื่อหลายปีก่อนและในขณะที่ฉันไม่เห็นว่าทำไม UInt ถึงไม่สามารถตรวจสอบความปลอดภัยประเภทได้ฉันเดาว่าพวก CLS ต้องมีจุดตัดที่ไหนสักแห่งว่าอะไรจะเป็นพื้นฐานขั้นต่ำ จำนวนประเภทค่าที่รองรับ นอกจากนี้เมื่อคุณคิดถึงระยะยาวที่มีการย้ายภาษาไปยัง CLR มากขึ้นเรื่อย ๆ เหตุใดจึงบังคับให้พวกเขาใช้ ints ที่ไม่ได้ลงนามเพื่อให้สอดคล้องกับ CLS หากไม่มีแนวคิดเลย?


@ เควิน: ฉันแค่สงสัยเกี่ยวกับหัวข้อ คุณตอบดูเหมือนตรรกะ ฉันชอบที่จะคิดเกี่ยวกับหัวข้อ ฉันคิดว่ามันน่าเสียดายที่ประเภทที่คล้ายภาษาปาสคาลไม่ได้ทำให้เป็น CLR แต่ข้อโต้แย้งของคุณเกี่ยวกับภาษาอื่น: นั่นไม่ได้หยุด IronPython โดยใช้การพิมพ์แบบไดนามิกอย่างมาก (DLR) ใน CLR ที่พิมพ์แบบคงที่
doekman

@doekman: ในขณะที่ใช่ IronPython และ IronRuby แสดงให้เห็นว่า CLR สามารถจัดหาแพลตฟอร์มที่คุณสามารถสร้างภาษาที่พิมพ์แบบไดนามิกได้เป้าหมายของ CLS คือการจัดเตรียมชุดมาตรฐานที่ก้าวข้ามฟังก์ชันการทำงานของภาษาและอนุญาตให้ทำงานร่วมกันได้สำเร็จและปลอดภัย ฉันไม่คิดว่าภาษาจะทำอะไรได้บ้างในแง่ของการพูดว่าการเพิ่มคุณสมบัติ DL นั้นเกี่ยวข้องโดยตรงกับสิ่งที่ควรเข้าสู่ CLS / CTS
Kev

จากความเข้าใจของฉัน CLR มีประเภทดั้งเดิมจำนวนเต็ม 32 บิตซึ่งมีคำแนะนำแยกต่างหากสำหรับการเพิ่มที่ลงชื่อด้วยการตรวจสอบการล้นการเพิ่มที่ไม่ได้ลงนามด้วยการตรวจสอบการล้นและ mod การเพิ่มที่ไม่เชื่อเรื่องพระเจ้า 2 ^ 32 เป็นต้น เมื่อถูกขอให้แปลงการอ้างอิงอ็อบเจ็กต์เป็นแบบดั้งเดิมจำนวนเต็ม 32 บิต CLR ไม่ทราบและไม่สนใจว่าโค้ดที่ใช้ตัวเลขนั้นคาดว่าจะมีการเซ็นชื่อหรือไม่ได้ลงนาม ไม่ว่าคอมไพลเลอร์จะเชื่อว่ามีการลงนามหรือไม่ได้ลงชื่อโดยทั่วไปจะมีผลต่อคำสั่งใดที่คอมไพลเลอร์สร้างขึ้นสำหรับการดำเนินการกับมัน แต่นั่นคือภาษา - ไม่ใช่ปัญหา CLR
supercat

23

ส่วนหนึ่งของปัญหาที่ฉันสงสัยว่าเกี่ยวข้องกับความจริงที่ว่าประเภทจำนวนเต็มที่ไม่ได้ลงชื่อใน C จำเป็นต้องทำตัวเป็นสมาชิกของวงแหวนพีชคณิตนามธรรมแทนที่จะเป็นตัวเลข [หมายถึงตัวอย่างเช่นว่าหากตัวแปรจำนวนเต็ม 16 บิตที่ไม่ได้ลงนามเท่ากับศูนย์จำเป็นต้องมีการลดทอนเพื่อให้ได้ 65,535 และถ้ามันเท่ากับ 65,535 การเพิ่มจะต้องให้ผลเป็นศูนย์] มีหลายครั้งที่พฤติกรรมดังกล่าวมีประโยชน์อย่างยิ่ง แต่ประเภทตัวเลขแสดงพฤติกรรมดังกล่าวอาจขัดต่อจิตวิญญาณของบางภาษา ฉันจะคาดเดาได้ว่าการตัดสินใจที่จะละเว้นประเภทที่ไม่ได้ลงนามอาจเกิดขึ้นก่อนการตัดสินใจที่จะสนับสนุนบริบทตัวเลขทั้งที่เลือกและไม่เลือก โดยส่วนตัวแล้วฉันหวังว่าจะมีประเภทจำนวนเต็มแยกกันสำหรับตัวเลขที่ไม่ได้ลงชื่อและวงแหวนพีชคณิต การใช้ตัวดำเนินการ unary ลบกับหมายเลข 32 บิตที่ไม่ได้ลงนามควรให้ผลลัพธ์ที่ลงนาม 64 บิต [การลบสิ่งอื่นที่ไม่ใช่ศูนย์จะให้จำนวนลบ] แต่การใช้เครื่องหมายยูนารีลบกับประเภทของวงแหวนควรให้ผลผกผันของส่วนเติมแต่งภายในวงแหวนนั้น

ไม่ว่าในกรณีใดก็ตามสาเหตุที่จำนวนเต็มไม่ได้ลงนามไม่สอดคล้องกับ CLS คือ Microsoft ตัดสินใจว่าภาษาไม่จำเป็นต้องรองรับจำนวนเต็มที่ไม่ได้ลงชื่อเพื่อให้ถือว่า "เข้ากันได้กับ CLS"


คำอธิบายที่ยอดเยี่ยมจากมุมมองทางคณิตศาสตร์!
dizarter

6

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

เป็นไปตามมาตรฐาน CLS มีวัตถุประสงค์เพื่อให้ชั้นเรียนสามารถใช้ประโยชน์ได้จากหลายภาษา ...

จำไว้ว่าไม่มีใครทำให้คุณเป็นไปตามมาตรฐาน CLS

คุณยังคงสามารถใช้ ints ที่ไม่ได้ลงชื่อได้ ภายในเมธอดหรือใช้พาร์มกับเมธอดส่วนตัวได้เนื่องจากเป็น API สาธารณะที่เข้ากันได้กับ CLS เท่านั้น


16
สิ่งเหล่านี้มีความสำคัญมากหากคุณกำลังคำนวณเลขคณิตอย่างชาญฉลาด
nicodemus13

@ nicodemus13 ครั้งสุดท้ายที่คุณเห็นระบบผู้ดูแลระบบธุรกิจที่มีการคำนวณทางคณิตศาสตร์ที่ชาญฉลาดในโดเมนปัญหาคือเมื่อใด (เช่นประเภทของซอฟต์แวร์ที่โปรแกรมเมอร์ VB.NET เขียน)
Ian Ringrose

38
อะไรก็ตามที่มีการตรวจสอบจะใช้เลขคณิตที่ชาญฉลาดซึ่งเป็นเรื่องธรรมดาและดูเหมือนเป็นเรื่องแปลกสำหรับฉันที่จะลากภาษาอื่น ๆ ลงไปเพราะ VB ไม่รองรับจำนวนเต็มที่ไม่ได้ลงชื่อ .NET มีไว้เพื่อใช้งานทั่วไปเช่นกันไม่ใช่เฉพาะสำหรับนักเขียน VB ของแอป LOB เมื่อคุณพูดว่า '1 type of int' คุณไม่คิดว่าการมี byte, short, int, long ก็เป็นความเจ็บปวดเช่นกัน? ฉันไม่ค่อยเห็นว่าทำไมการเซ็นสัญญาถึงดูอึดอัดไปกว่านี้
nicodemus13

5

จำนวนเต็มที่ไม่ได้ลงนามไม่สอดคล้องกับ CLS เนื่องจากไม่สามารถทำงานร่วมกันระหว่างภาษาบางภาษาได้

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.