ทำไม Java ไม่สนับสนุน ints ที่ไม่ได้ลงชื่อ?

เหตุใด Java จึงไม่รวมการสนับสนุนสำหรับจำนวนเต็มที่ไม่มีเครื่องหมาย?

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

นอกจากนี้การใช้จำนวนเต็มที่ไม่ได้ลงนามอาจเป็นรูปแบบของเอกสารตนเองเนื่องจากพวกเขาระบุว่าค่าที่ int ที่ไม่ได้ลงชื่อซึ่งมีไว้เพื่อถือนั้นไม่ควรจะเป็นค่าลบ

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

ข้อเสียของการรวมสิ่งเหล่านี้คืออะไร?

นี่คือจากการสัมภาษณ์กับกอสลิงและอื่น ๆเกี่ยวกับความเรียบง่าย:

ลูกห่าน: สำหรับฉันในฐานะนักออกแบบภาษาซึ่งฉันไม่นับตัวเองว่าเป็นวันนี้สิ่งที่ "เรียบง่าย" จบลงด้วยความหมายที่แท้จริงฉันคาดหวังได้เลยว่า J. Random Developer จะถือสเป็คไว้ในหัวของเขา คำจำกัดความดังกล่าวบอกว่ายกตัวอย่างเช่น Java ไม่ใช่ - และในความเป็นจริงภาษาเหล่านี้ส่วนใหญ่จบลงด้วยการเป็นมุมเล็ก ๆ น้อย ๆ สิ่งที่ไม่มีใครเข้าใจจริงๆ ทำแบบทดสอบนักพัฒนา C ทุกคนเกี่ยวกับผู้ที่ไม่ได้ลงนามและในไม่ช้าคุณก็จะค้นพบว่าแทบจะไม่มีนักพัฒนา C คนใดที่เข้าใจสิ่งที่เกิดขึ้นโดยไม่ได้ลงนามสิ่งที่ไม่ได้ลงนามคืออะไร สิ่งที่ทำนั้นซับซ้อน C ฉันคิดว่าส่วนภาษาของ Java นั้นค่อนข้างเรียบง่าย ห้องสมุดที่คุณต้องค้นหา

อ่านระหว่างบรรทัดฉันคิดว่าตรรกะเป็นอะไรเช่นนี้:

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

ส่วนใหญ่ฉันจะบอกว่ามันเป็นการตัดสินใจที่สมเหตุสมผล อาจเป็นไปได้ที่ฉันจะมี:

• ทำ byte unsigned หรืออย่างน้อยก็ให้ทางเลือกที่ลงชื่อ / ไม่ได้ลงนามอาจมีชื่อแตกต่างกันสำหรับชนิดข้อมูลนี้ (ทำให้การลงชื่อนั้นดีสำหรับความสอดคล้อง แต่เมื่อใดที่คุณต้องการไบต์ที่ลงนามแล้ว)
• เสร็จแล้วด้วย 'สั้น' (เมื่อคุณใช้เลขคณิตแบบ 16 บิตครั้งล่าสุดเมื่อใด)

การดำเนินการกับค่าที่ไม่ได้ลงนามมากถึง 32 บิตนั้นยังไม่ดีนักและคนส่วนใหญ่ไม่ต้องการการแบ่งหรือเปรียบเทียบแบบ 64 บิตที่ไม่ได้ลงชื่อ

นี่เป็นคำถามที่เก่ากว่าและ pat พูดถึงตัวอักษรสั้น ๆ ฉันแค่คิดว่าฉันควรจะขยายเรื่องนี้ให้กับคนอื่น ๆ ที่จะมองสิ่งนี้ตามถนน ลองมาดูประเภท Java ดั้งเดิมอย่างละเอียด:

byte - เลขจำนวนเต็ม 8 บิต

short - เลขจำนวนเต็ม 16 บิตที่เซ็นชื่อ

int - จำนวนเต็มแบบ 32 บิต

long - จำนวนเต็มแบบ 64 บิต

char - อักขระ 16 บิต (จำนวนเต็มที่ไม่มีเครื่องหมาย)

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

char a = 0;
char b = 6;
a += 1;
a = (char) (a * b);
a = (char) (a + b);
a = (char) (a - 16);
b = (char) (b % 3);
b = (char) (b / a);
//a = -1; // Generates complier error, must be cast to char
System.out.println(a); // Prints ? 
System.out.println((int) a); // Prints 65532
System.out.println((short) a); // Prints -4
short c = -4;
System.out.println((int) c); // Prints -4, notice the difference with char
a *= 2;
a -= 6;
a /= 3;
a %= 7;
a++;
a--;

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

แก้ไข

ด้วย JDK8 มี API ใหม่สำหรับLongและIntegerให้วิธีการช่วยเหลือเมื่อทำการรักษาlongและintค่าเป็นค่าที่ไม่ได้ลงนาม

• compareUnsigned
• divideUnsigned
• parseUnsignedInt
• parseUnsignedLong
• remainderUnsigned
• toUnsignedLong
• toUnsignedString

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

Java มีประเภทที่ไม่ได้ลงนามหรืออย่างน้อยหนึ่งประเภท: char เป็นคำที่ไม่ได้ลงนาม ดังนั้นข้ออ้างอะไรก็ตามที่ลูกห่านโยนขึ้นมามันเป็นแค่ความไม่รู้ของเขาว่าทำไมไม่มีประเภทอื่น ๆ ที่ไม่ได้ลงชื่อ

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

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

http://skeletoncoder.blogspot.com/2006/09/java-tutorials-why-no-unsigned.html

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

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

สำหรับคำแนะนำการปฏิบัติ:

• หากค่าของคุณจะค่อนข้างขนาดโดยพลการและไม่พอดีกับการใช้งานint longหากพวกเขาไม่พอดีกับการใช้งานlongBigInteger

• ใช้ประเภทที่เล็กกว่าสำหรับอาร์เรย์เท่านั้นเมื่อคุณต้องการประหยัดพื้นที่

• หากคุณต้องการบิต 64/32/16/8 ให้ใช้long/ int/ short/ byteและหยุดกังวลเกี่ยวกับบิตเครื่องหมายยกเว้นการหารการเปรียบเทียบการเปลี่ยนที่ถูกต้องและการส่ง

ดูเพิ่มเติมที่คำตอบนี้เกี่ยวกับ "การย้ายเครื่องกำเนิดตัวเลขสุ่มจาก C ถึง Java"

ด้วยJDK8มันมีการสนับสนุนบางอย่างสำหรับพวกเขา

เราอาจเห็นการสนับสนุนประเภทที่ไม่ได้ลงนามใน Java อย่างเต็มที่แม้จะมีข้อกังวลของ Gosling

ฉันรู้ว่าโพสต์นี้เก่าเกินไป อย่างไรก็ตามเพื่อความสนใจของคุณใน Java 8 และใหม่กว่าคุณสามารถใช้intชนิดข้อมูลเพื่อแสดงจำนวนเต็ม 32 บิตที่ไม่ได้ลงนามซึ่งมีค่าต่ำสุด 0 และค่าสูงสุด 2 ³² −1 ใช้Integerระดับการใช้งานintประเภทข้อมูลเป็นจำนวนเต็มไม่ได้ลงนามและวิธีการคงเหมือนcompareUnsigned(), divideUnsigned()ฯลฯ ได้รับการเพิ่มIntegerระดับในการสนับสนุนการดำเนินการทางคณิตศาสตร์สำหรับจำนวนเต็มไม่ได้ลงนาม

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

ฉันเคยเรียนหลักสูตร C ++ กับใครบางคนในคณะกรรมการมาตรฐาน C ++ ซึ่งบอกเป็นนัยว่า Java ทำการตัดสินใจที่ถูกต้องเพื่อหลีกเลี่ยงการมีจำนวนเต็มที่ไม่ได้ลงนามเพราะ (1) โปรแกรมส่วนใหญ่ที่ใช้จำนวนเต็มที่ไม่ได้ลงนามสามารถทำได้เช่นกัน แง่ของวิธีที่ผู้คนคิดและ (2) การใช้จำนวนเต็มที่ไม่ได้ลงนามส่งผลให้ง่ายต่อการสร้าง แต่ยากที่จะแก้ปัญหาเช่นเลขจำนวนเต็มล้นและสูญเสียบิตที่สำคัญเมื่อแปลงระหว่างประเภทที่ลงนามและไม่ได้ลงนาม หากคุณลบ 1 จาก 0 โดยใช้เลขจำนวนเต็มที่โดยไม่ตั้งใจมันมักจะทำให้โปรแกรมของคุณพังได้ง่ายขึ้นและทำให้ค้นหาข้อผิดพลาดได้ง่ายกว่าถ้ามันล้อมรอบถึง 2 ^ 32 - 1 และคอมไพเลอร์และเครื่องมือวิเคราะห์แบบคงที่ สมมติว่าคุณรู้ว่าคุณกำลังทำอะไรอยู่ตั้งแต่คุณเลือกใช้เลขคณิตที่ไม่ได้ลงชื่อ นอกจากนี้

นานมาแล้วเมื่อหน่วยความจำถูก จำกัด และตัวประมวลผลไม่ทำงานโดยอัตโนมัติใน 64 บิตในครั้งเดียวทุกบิตนับได้มากขึ้นดังนั้นเมื่อมีการลงชื่อไบต์หรือกางเกงขาสั้นที่ไม่ได้ลงนามจริง ๆ ก็มีความสำคัญมากกว่าบ่อยครั้ง วันนี้เพียงแค่ใช้ int ที่มีการลงชื่อก็เพียงพอแล้วในเกือบทุกกรณีของการเขียนโปรแกรมปกติและหากโปรแกรมของคุณต้องการใช้ค่าที่มากกว่า 2 ^ 31 - 1 คุณก็มักจะต้องการความยาวอยู่ดี เมื่อคุณเข้าสู่ดินแดนแห่งการใช้เวลานานมันก็ยากที่จะเกิดขึ้นด้วยเหตุผลที่ว่าทำไมคุณถึงไม่สามารถทำได้ด้วยจำนวนเต็มบวก 2 ^ 63 - 1 เมื่อใดก็ตามที่เราไปถึงตัวประมวลผล 128 บิตจะมีปัญหาน้อยลง

คำถามของคุณคือ "ทำไม Java จึงไม่สนับสนุน ints ที่ไม่ได้ลงชื่อ"?

และคำตอบของฉันสำหรับคำถามของคุณคือ Java ต้องการให้มันเป็นประเภทดั้งเดิมทั้งหมด: ไบต์ , ถ่าน , สั้น , intและlongควรถือว่าเป็นbyte , word , dwordและqwordตามลำดับเหมือนกับในชุดประกอบและตัวดำเนินการ Java ถูกลงนามการดำเนินงานในทุกประเภทของมันดั้งเดิมยกเว้นถ่านแต่เฉพาะถ่านพวกเขาจะไม่ได้ลงชื่อ 16 บิตเท่านั้น

ดังนั้นวิธีการคงที่ควรจะเป็นการดำเนินการที่ไม่ได้ลงนามด้วยสำหรับทั้ง 32 และ 64 บิต

คุณต้องการคลาสสุดท้ายซึ่งสามารถเรียกเมธอดแบบสแตติกสำหรับผู้ที่ไม่ได้ลงชื่อดำเนินการที่

คุณสามารถสร้างคลาสสุดท้ายนี้เรียกมันว่าชื่ออะไรก็ได้ที่คุณต้องการและใช้มันเป็นวิธีการคงที่

หากคุณไม่มีความคิดเกี่ยวกับวิธีการใช้วิธีการคงที่แล้วลิงค์นี้อาจช่วยคุณได้

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

นอกจากนี้ยังแตกต่างอย่างสิ้นเชิงในชื่อของภาษาโดยวิธี

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

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

นอกจากนี้ฉันขอแนะนำให้หลีกเลี่ยงการใช้สั้น , intและยาวดั้งเดิมและใช้word , dwordและqwordตามลำดับแทนและคุณกำลังจะเรียกวิธีการคงที่สำหรับการดำเนินการที่ไม่ได้ลงชื่อและ / หรือการดำเนินการที่ลงนามแทนการใช้ตัวดำเนินการ

หากคุณกำลังจะทำการดำเนินการที่ลงนามเท่านั้นและใช้ตัวดำเนินการเฉพาะในรหัสนี่ก็โอเคที่จะใช้ประเภทดั้งเดิมเหล่านี้ สั้น , intและยาว

อันที่จริงคำ , dwordและqword ไม่ได้ทำมีอยู่ในภาษา แต่คุณสามารถสร้างคลาสใหม่สำหรับแต่ละและการดำเนินงานของแต่ละคนควรจะเป็นเรื่องง่ายมาก:

ชั้นคำถือชนิดดั้งเดิมสั้นเพียงชั้นDWORDถือชนิดดั้งเดิมintเท่านั้นและชั้นqwordถือชนิดดั้งเดิมยาวเท่านั้น ขณะนี้วิธีการที่ไม่ได้ลงนามและที่ลงนามเป็นแบบคงที่หรือไม่เป็นทางเลือกของคุณคุณสามารถใช้ในแต่ละชั้นเรียนเช่นการดำเนินการ 16 บิตทั้งที่ไม่ได้ลงชื่อและลงนามโดยให้ชื่อที่มีความหมายกับคลาสคำลงนามโดยการให้ชื่อความหมายกับคลาสdwordและการดำเนินการ 64 บิตทั้งที่ไม่ได้ลงชื่อและลงนามโดยให้ชื่อความหมายกับคลาสqword

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

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

เกี่ยวกับการส่งผ่านค่าและผ่านการอ้างอิง:

หากฉันไม่ผิดเช่นใน C # วัตถุดั้งเดิมจะถูกส่งผ่านตามค่าตามธรรมชาติ แต่คลาสอ็อบเจ็กต์จะถูกส่งผ่านโดยการอ้างอิงตามธรรมชาติดังนั้นหมายความว่าวัตถุประเภทByte , word , dwordและqwordจะถูกส่งผ่านโดยการอ้างอิงไม่ใช่ตามค่า โดยค่าเริ่มต้น. ฉันหวังว่า Java มีstructวัตถุเป็น C # มีดังนั้นสิ่งไบต์ , คำ , DWORDและqwordสามารถดำเนินการให้เป็นstructแทนระดับดังนั้นโดยค่าเริ่มต้นพวกเขาถูกส่งผ่านโดยค่าและไม่ใช่โดยการอ้างอิงโดยค่าเริ่มต้นเช่นวัตถุ struct ใด ๆ ใน C # เช่นประเภทดั้งเดิมจะถูกส่งผ่านโดยค่าและไม่โดยอ้างอิงโดยค่าเริ่มต้น แต่เพราะ Java นั้นเลวร้ายยิ่งกว่า C # และเรา เพื่อจัดการกับสิ่งนั้นมีเพียงคลาสและอินเตอร์เฟสที่ถูกส่งผ่านโดยการอ้างอิงไม่ใช่ตามค่าเริ่มต้น ดังนั้นหากคุณต้องการผ่านByte , word , dwordและ qwordตามค่าและไม่ใช่โดยการอ้างอิงเช่น object class อื่น ๆ ใน Java และใน C # คุณจะต้องใช้ตัวสร้าง copy และนั่นคือมัน

นั่นเป็นทางออกเดียวที่ฉันคิดได้ ฉันแค่หวังว่าฉันจะสามารถพิมพ์ชนิดดั้งเดิมเป็น word, dword และ qword ได้ แต่ Java ไม่รองรับ typedef หรือใช้เลยเหมือน C # ที่รองรับใช้ซึ่งเทียบเท่ากับ typedef ของ C

เกี่ยวกับผลลัพธ์:

สำหรับลำดับของบิตเดียวกันเดียวกันคุณสามารถพิมพ์ได้หลายวิธี: ในฐานะไบนารีเป็นทศนิยม (เช่นความหมายของ% u ใน C printf) เป็นฐานแปด (เช่นความหมายของ% o ใน C printf) เป็นเลขฐานสิบหก (เช่น ความหมายของ% x ใน C printf) และเป็นจำนวนเต็ม (เช่นความหมายของ% d ใน C printf)

โปรดทราบว่า C printf ไม่ทราบชนิดของตัวแปรที่ส่งผ่านเป็นพารามิเตอร์ไปยังฟังก์ชันดังนั้น printf จึงรู้ประเภทของตัวแปรแต่ละตัวจากออบเจ็กต์ char * ที่ส่งไปยังพารามิเตอร์แรกของฟังก์ชัน

ดังนั้นในแต่ละชั้นเรียน: Byte , word , dwordและqwordคุณสามารถใช้วิธีการพิมพ์และรับฟังก์ชั่นการทำงานของ printf แม้ว่าการลงนามในชั้นเรียนแบบดั้งเดิมจะยังคงไม่ได้ลงนามโดยทำตามขั้นตอนวิธีที่เกี่ยวข้อง การดำเนินการทางตรรกะและ shift เพื่อรับตัวเลขเพื่อพิมพ์ไปยังเอาต์พุต

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

นั่นคือทั้งหมดที่ฉันสามารถตอบคำถามของคุณและแนะนำคุณ

เพราะ unsignedประเภทคือความชั่วร้ายบริสุทธิ์

ความจริงที่ว่าใน C unsigned - intผลิตunsignedความชั่วร้ายมากยิ่งขึ้น

นี่คือภาพรวมของปัญหาที่เผาฉันมากกว่าหนึ่งครั้ง:

// We have odd positive number of rays, 
// consecutive ones at angle delta from each other.
assert( rays.size() > 0 && rays.size() % 2 == 1 );

// Get a set of ray at delta angle between them.
for( size_t n = 0; n < rays.size(); ++n )
{
    // Compute the angle between nth ray and the middle one.
    // The index of the middle one is (rays.size() - 1) / 2,
    // the rays are evenly spaced at angle delta, therefore
    // the magnitude of the angle between nth ray and the 
    // middle one is: 
    double angle = delta * fabs( n - (rays.size() - 1) / 2 ); 

    // Do something else ...
}

คุณสังเกตเห็นข้อผิดพลาดหรือยัง ฉันสารภาพฉันเห็น แต่หลังจากก้าวเข้ามาพร้อมกับเครื่องมือดีบั๊กแล้ว

เพราะnเป็นประเภทที่ไม่ได้ลงชื่อsize_tการแสดงออกทั้งประเมินเป็นn - (rays.size() - 1) / 2 unsignedการแสดงออกนั้นตั้งใจจะเป็นตำแหน่งที่เซ็นชื่อของnรังสีดวงที่หนึ่งจากจุดกึ่งกลาง: รังสีดวงที่ 1 จากจุดกึ่งกลางทางด้านซ้ายจะมีตำแหน่ง -1, อันที่ 1 ทางด้านขวาจะมีตำแหน่ง +1 เป็นต้น รับค่า abs และคูณด้วยdeltaมุมฉันจะได้มุมระหว่างnเรย์ th กับอันตรงกลาง

น่าเสียดายสำหรับฉันนิพจน์ด้านบนมีสิ่งชั่วร้ายที่ไม่ได้ลงนามและแทนที่จะประเมินให้พูดว่า -1 จะได้รับการประเมินเป็น 2 ^ 32-1 การแปลงที่ตามมาเป็นdoubleปิดผนึกข้อผิดพลาด

หลังจากบั๊กหรือสองอันเกิดจากการใช้unsignedเลขคณิตในทางที่ผิดจะต้องเริ่มสงสัยว่าบิตพิเศษที่ได้รับนั้นมีค่ามากหรือไม่ ฉันพยายามเท่าที่จะทำได้เพื่อหลีกเลี่ยงการใช้unsignedประเภทใด ๆในการคำนวณแม้ว่าจะยังคงใช้สำหรับการดำเนินการที่ไม่ใช่ทางคณิตศาสตร์เช่นไบนารีมาสก์

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

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

ฉันเดาว่าถ้ามีใครจะได้รับ Dennis Ritchie ปรับเปลี่ยนอัตตาเพื่อให้คำแนะนำกับทีมออกแบบของ Gosling มันจะแนะนำให้ Signed เป็น "ศูนย์ที่ไม่มีที่สิ้นสุด" เพื่อให้คำขอออฟเซ็ตออฟที่อยู่ทั้งหมดจะเพิ่มขนาด ALGEBRAIC RING

ด้วยวิธีนี้การชดเชยออฟเซตที่อาร์เรย์ไม่สามารถสร้าง SEGFAULT ได้ ตัวอย่างเช่นในคลาสที่ห่อหุ้มซึ่งฉันเรียก RingArray ของคู่ที่ต้องการพฤติกรรมที่ไม่ได้ลงนาม - ในบริบท "วงหมุนด้วยตนเอง":

// ...
// Housekeeping state variable
long entrycount;     // A sequence number
int cycle;           // Number of loops cycled
int size;            // Active size of the array because size<modulus during cycle 0
int modulus;         // Maximal size of the array

// Ring state variables
private int head;   // The 'head' of the Ring
private int tail;   // The ring iterator 'cursor'
// tail may get the current cursor position
// and head gets the old tail value
// there are other semantic variations possible

// The Array state variable
double [] darray;    // The array of doubles

// somewhere in constructor
public RingArray(int modulus) {
    super();
    this.modulus = modulus;
    tail =  head =  cycle = 0;
    darray = new double[modulus];
// ...
}
// ...
double getElementAt(int offset){
    return darray[(tail+modulus+offset%modulus)%modulus];
}
//  remember, the above is treating steady-state where size==modulus
// ...

RingArray ด้านบนจะไม่ 'รับ' จากดัชนีลบแม้ว่าผู้ร้องขอที่เป็นอันตรายจะพยายาม โปรดจำไว้ว่ายังมีคำขอที่ถูกต้องตามกฎหมายจำนวนมากสำหรับการขอค่าดัชนี (เชิงลบ) ก่อนหน้านี้

หมายเหตุ:% โมดูลัสด้านนอกยกเลิกการอ้างอิงคำร้องขอที่ถูกกฎหมายในขณะที่% โมดูลัสด้านในออกมาพูดอาฆาตพยาบาทจากเชิงลบมากกว่าโมดูลัส หากสิ่งนี้เคยปรากฏใน Java + .. + 9 || 8+ .. + spec แล้วปัญหาจะกลายเป็น 'โปรแกรมเมอร์ที่ไม่สามารถ "หมุนตัวเอง" FAULT' อย่างแท้จริง

ฉันแน่ใจว่า Java ที่เรียกว่า 'การขาด' ที่ไม่ได้ลงชื่อซึ่งสามารถถูกสร้างขึ้นโดยใช้หนึ่งซับด้านบน

PS: เพียงเพื่อให้บริบทข้างต้น RingArray แม่บ้านนี่คือการดำเนินการของผู้สมัครเพื่อให้ตรงกับการดำเนินงานองค์ประกอบ 'รับ' ข้างต้น:

void addElement(long entrycount,double value){ // to be called only by the keeper of entrycount
    this.entrycount= entrycount;
    cycle = (int)entrycount/modulus;
    if(cycle==0){                       // start-up is when the ring is being populated the first time around
        size = (int)entrycount;         // during start-up, size is less than modulus so use modulo size arithmetic
        tail = (int)entrycount%size;    //  during start-up
    }
    else {
        size = modulus;
        head = tail;
        tail = (int)entrycount%modulus; //  after start-up
    }
    darray[head] = value;               //  always overwrite old tail
}

ฉันนึกถึงผลข้างเคียงที่โชคร้ายอย่างหนึ่ง ในฐานข้อมูลแบบฝังของจาวาจำนวนรหัสที่คุณสามารถมีได้ด้วยฟิลด์รหัส 32 บิตคือ 2 ^ 31 ไม่ใช่ 2 ^ 32 (~ 2 พันล้านไม่ใช่ ~ 4 พันล้าน)

เหตุผลที่ IMHO นั้นเป็นเพราะพวกเขา / ขี้เกียจเกินกว่าที่จะใช้ / แก้ไขข้อผิดพลาดนั้น การแนะนำว่าโปรแกรมเมอร์ C / C ++ ไม่เข้าใจโครงสร้างที่ไม่ได้ลงนาม, union, union, bit flag ... เป็นเรื่องที่ผิดปกติ

อีเธอร์ที่คุณกำลังพูดคุยกับโปรแกรมเมอร์พื้นฐาน / bash / java ที่กำลังจะเริ่มเขียนโปรแกรม la C โดยไม่ต้องมีความรู้ภาษานี้จริง ๆ หรือคุณแค่พูดออกมาจากใจของคุณเอง ;)

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

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

กระแสตรง