จำนวนเต็มใช้เป็นประเภทข้อมูลมากเกินไปหรือไม่

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

บางอย่างดูน่ากลัวเล็กน้อยเกี่ยวกับรหัสเช่นนี้

TStuffRec = record
   recordID : Integer;
   thingID : Integer;
   otherThingID : Integer;
end;

เมื่อมันสามารถเขียนเป็น

TStuffRec = record
   recordID : Cardinal;
   thingID : Cardinal;
   otherThingID : Cardinal;
end;

ฟังก์ชั่นบันทึกเหล่านี้มักจะทำงานเหมือนเดิม (และหวังว่าจะยังคงทำงานเหมือนเดิมแม้ใน Delphi 64 บิต) แต่จำนวนมากจะมีปัญหาการแปลง

แต่มีข้อเสียคือการใช้ int ที่ไม่ได้ลงชื่อเช่นกัน สาเหตุหลักมาจากการผสมสองอย่างนี้เข้าด้วยกัน

คำถามจริงคือสิ่งนี้จริง ๆ แล้วคิดหรือรวมอยู่ในแนวทางปฏิบัติที่ดีที่สุดหรือไม่? มันมักจะขึ้นอยู่กับนักพัฒนาหรือไม่

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

for i := 0 to List.Count - 1 do
  //do something here

ฉันได้iประกาศว่าเป็นจำนวนเต็มไม่ได้ลงนาม (หลังจากทั้งหมดมันเป็นดัชนีในรายการที่เริ่มต้นที่ 0 มันไม่จำเป็นต้องเป็นลบใช่ไหม?) แต่เมื่อList.Countเป็น 0 มันจะไม่ทำให้เกิดการวนซ้ำตามที่คาดไว้เพราะ0 - 1หาค่าเป็นจำนวนบวกที่สูงจริงๆ อ๊ะ!

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

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

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

• ลูป บ่อยครั้งที่ฉันเขียนลูป "จาก i: = 0 ถึง Count-1" จะเกิดอะไรขึ้นถ้า "i" เป็นไบต์และ Count = 0 คือลูปนั้นจะเริ่มจาก 0 ถึง 255 ไม่ใช่ว่าฉันต้องการมัน

• Uniforming ง่ายต่อการจดจำและใช้ "var i: integer;" กว่าที่จะหยุดในแต่ละกรณีและคิดว่า"หืมม .. ที่นี่เรากำลังติดต่อกับ 0..120 ช่วง .. ไบต์ .. ไม่รอเราอาจต้อง -1 สำหรับการเตรียมการเบื้องต้น .. ย่อ .. .. ถ้า 128 คือ ไม่พอ .. หรือ"ทำไมจึงเป็นขนาดเล็กในสถานที่นี้ไม่ใช่ shortint?"

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

• -1 แม้เมื่อค่าอยู่ในช่วง 0..n-1 ฉันมักต้องตั้งค่า "ไม่มีค่า / ไม่รู้จัก / ไม่รู้จัก / ไม่กำหนด / ว่างเปล่า" ซึ่งเป็นวิธีปฏิบัติทั่วไป -1

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

ป.ล. ฉันจะใช้ประเภทอื่นเมื่อใด

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

แนวทางปฏิบัติที่ดีที่สุดคือการใช้ประเภทข้อมูลที่เหมาะกับความต้องการข้อมูลที่ใช้ (ข้อมูลที่คาดหวัง)

ตัวอย่าง C #: หากฉันต้องการรองรับ 0 ถึง 255 ฉันจะใช้ไบต์

ถ้าฉันต้องการสนับสนุน 1,000,000 ลบและบวกแล้ว int

ใหญ่กว่า 4.2 พันล้านจากนั้นใช้เป็นเวลานาน

โดยการเลือกประเภทที่ถูกต้องโปรแกรมจะใช้จำนวนหน่วยความจำที่เหมาะสมที่สุดและประเภทที่แตกต่างใช้หน่วยความจำที่แตกต่าง

นี่คือการอ้างอิง C # int จาก MSDN

int 
 -2,147,483,648 to 2,147,483,647
 Signed 32-bit integer

uint 
 0 to 4,294,967,295
 Unsigned 32-bit integer

long 
 -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807
 Signed 64-bit integer

ulong 
 0 to 18,446,744,073,709,551,615
 Unsigned 64-bit integer

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

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

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