แพลตฟอร์มใดมีสิ่งอื่นที่ไม่ใช่ถ่าน 8 บิต

136

ทุกขณะนี้แล้วคนอื่นที่ใช้จุดเพื่อออกว่าchar(aka 'ไบต์') ไม่จำเป็นต้องเป็น 8 บิต

ดูเหมือนว่า 8 บิตcharนั้นเกือบจะเป็นสากล ฉันจะคิดว่าสำหรับแพลตฟอร์มหลักจำเป็นต้องมี 8 บิตcharเพื่อให้แน่ใจว่ามีศักยภาพในตลาด

ทั้งในตอนนี้และในอดีตแพลตฟอร์มใดที่ใช้charไม่ได้เป็น 8 บิตและทำไมพวกเขาถึงแตกต่างจาก "ปกติ" 8 บิต

เมื่อเขียนโค้ดและคิดถึงการสนับสนุนข้ามแพลตฟอร์ม (เช่นสำหรับไลบรารีที่ใช้งานทั่วไป) สิ่งที่ควรคำนึงถึงในการให้แพลตฟอร์มที่ไม่ใช่ non-8-bit charคืออะไร

ในอดีตที่ผ่านมาฉันได้พบกับ Analog Devices DSP บางตัวซึ่งcharเป็น 16 บิต DSP เป็นบิตของสถาปัตยกรรมเฉพาะที่ฉันคิดว่า (จากนั้นอีกครั้งในขณะที่แอสเซมเบลอร์ที่เขียนด้วยมือสามารถเอาชนะสิ่งที่คอมไพเลอร์ C ที่มีอยู่สามารถทำได้ดังนั้นฉันจึงไม่ได้รับประสบการณ์มากกับ C บนแพลตฟอร์มนั้น)

c++ c cross-platform

— Craig McQueen
แหล่งที่มา

9

CDC Cyber series มีการเข้ารหัส 6/12 บิต ตัวละครที่ได้รับความนิยมมากที่สุดคือ 6 บิต อักขระที่เหลือใช้ 12 บิต

— โทมัสแมตทิวส์

2

PDP-11 ตอกลง ความคิดที่ว่าตัวละครสามารถเข้ารหัสในตัวละครนั้นล้าสมัยไปแล้วอย่างจริงจัง

— ฮันส์แพสแตนท์

7

"PDP-11 ตอกลง" - คุณหมายถึงเพราะ C ถูกนำไปใช้กับ PDP-11 ครั้งแรกด้วยไบต์ 8 บิต? แต่ C ถูกนำไปใช้กับเครื่อง Honeywell ขนาด 9 บิตต่อไป ดูรุ่น K&R 1 นอกจากนี้คำถามที่ถามเกี่ยวกับ char (เช่นไบต์) ไม่เกี่ยวกับตัวละคร (หนึ่งไบต์ขึ้นไปเข้ารหัสสิ่งที่ไม่ได้ถาม)

— โปรแกรมเมอร์ Windows

6

DEC-10 และ DEC-20 มีคำศัพท์ 36 บิต อักขระ ASCII 7 บิตห้าตัวต่อคำเป็นเรื่องปกติ นอกจากนี้ยังมีการใช้อักขระ 6 บิตหกตัว

— David R Tribble

3

@CraigMcQueen: ถ้าฉันจำได้อย่างถูกต้อง CodeVision สำหรับไมโครคอนโทรลเลอร์ Atmel ให้เลือกขนาดของถ่าน

— vsz

80

charยังเป็น 16 บิตสำหรับ Texas Instruments C54x DSPs ซึ่งเปิดตัวอย่างเช่นใน OMAP2 มีประมวลสัญญาณอื่น ๆ ออกมีกับ 16 และ 32 charบิต ฉันคิดว่าฉันเคยได้ยินเกี่ยวกับ DSP 24 บิต แต่ฉันจำไม่ได้ว่าอะไรดังนั้นฉันจึงอาจจินตนาการได้

CHAR_BIT == 8การพิจารณาก็คือว่าเอกสาร POSIX ดังนั้นหากคุณใช้ POSIX คุณสามารถสันนิษฐานได้ หากในภายหลังมีใครบางคนต้องการย้ายรหัสของคุณไปยัง POSIX ใกล้จะเกิดขึ้นนั่นก็เกิดขึ้นกับฟังก์ชั่นที่คุณใช้ แต่ขนาดที่แตกต่างกันcharนั่นคือโชคร้ายของพวกเขา

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

— สตีฟเจสซอพ
แหล่งที่มา

2

TI C62xx และ C64xx DSPs ยังมีตัวอักษร 16 บิต (uint8_t ไม่ได้ถูกกำหนดไว้บนแพลตฟอร์มนั้น)

— myron-semack

7

DSP จำนวนมากสำหรับการประมวลผลเสียงเป็นเครื่อง 24 บิต BelaSignaประมวลสัญญาณจากบนกึ่งพ่วง (หลังจากที่พวกเขาซื้อ AMI กึ่ง); DSP56K / ซิมโฟนีเสียง DSPs จาก Freescale (หลังจากที่พวกเขาปั่นออกจากโมโตโรล่า)

— เดวิดแครี

2

@msemack C64xx มีฮาร์ดแวร์สำหรับ 8/16/32/40 และ 8bit ถ่าน

— user3528438

4

มากกว่าassert()(ถ้านั่นคือสิ่งที่คุณหมายถึง) ฉันจะใช้#if CHAR_BIT != 8... #error "I require CHAR_BIT == 8"...#endif

— Keith Thompson

1

@ KeithThompson มีเหตุผลstatic_assert()อะไรไหมที่จะไม่ใช้?

— Qix - MONICA ถูกยกเลิก

37

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

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

ตอนนี้อาจดูงี่เง่าแล้ว - " แน่นอนว่าทุกไบต์มี 8 บิต!" ฉันได้ยินคุณพูด แต่คนฉลาด ๆ จำนวนมากพึ่งพาสมมติฐานที่ไม่รับประกันแล้วทุกอย่างก็พัง ประวัติเต็มไปด้วยตัวอย่างเช่น

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

ผู้วิจารณ์คนหนึ่งถามว่าที่ไหนในมาตรฐานมันบอกว่าถ่านต้องมีอย่างน้อย 8 บิต มันอยู่ในส่วน5.2.4.2.1 ส่วนนี้กำหนดCHAR_BITจำนวนบิตในเอนทิตีที่สามารถกำหนดแอดเดรสได้น้อยที่สุดและมีค่าเริ่มต้นที่ 8 นอกจากนี้ยังกล่าวว่า:

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

ดังนั้นหมายเลขใด ๆ เท่ากับ 8 CHAR_BITหรือสูงกว่าเหมาะสำหรับการทดแทนโดยการดำเนินการออกเป็น

— John Feminella
แหล่งที่มา

6

ฉันไม่ได้เห็นปุ่มเทอร์โบในเวลาอย่างน้อย 20 ปีคุณคิดว่ามันดีจริงหรือเปล่า?

— Mark Ransom

29

@ Mark Ransom: นั่นคือจุดทั้งหมด นักพัฒนามักพึ่งพาสมมติฐานที่ดูเหมือนจะเป็นจริงในขณะนี้ แต่มีความแตกต่างมากกว่าที่พวกเขาปรากฏในตอนแรก (ไม่สามารถนับจำนวนครั้งที่ผมเคยทำที่ผิดพลาด!) ปุ่ม Turbo ควรจะเตือนความทรงจำที่เจ็บปวดไม่ได้ที่จะทำให้สมมติฐานที่ไม่จำเป็นและไม่แน่นอนที่จะทำให้สมมติฐานที่ไม่ได้รับการประกันโดยมาตรฐานภาษาราวกับว่าพวกเขา ข้อเท็จจริงไม่เปลี่ยนรูป

— John Feminella

1

คุณช่วยชี้ให้เห็นใน C ++ Standard ซึ่งบอกว่า bye มีอย่างน้อย 8 บิต? เป็นความเชื่อทั่วไป แต่ฉันเองไม่พบมันในมาตรฐาน สิ่งเดียวที่ฉันพบใน Standard คืออักขระที่ต้องสามารถแทนได้โดยcharมีมากกว่า 64 ตัวอักษรแต่น้อยกว่านั้นที่ 128 ดังนั้น 7 บิตจะเพียงพอ

— Adam Badura

6

ส่วนที่ 18.2.2 เรียกใช้มาตรฐาน C สำหรับมัน ในมาตรฐาน C คือส่วน 7.10 และจากนั้นส่วน 5.4.2.4.1 หน้า 22 ในมาตรฐาน C

— โปรแกรมเมอร์ Windows

2

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

— Jerry Jeremiah

34

เครื่องที่มีสถาปัตยกรรมแบบ 36 บิตมีขนาด 9 บิต ตามวิกิพีเดียเครื่องจักรที่มีสถาปัตยกรรม 36 บิตประกอบด้วย:

Corporation อุปกรณ์ดิจิตอล PDP-6/10
IBM 701/704/709/7090/7094
UNIVAC 1103 / 1103A / 1105/1100/2200

— R Samuel Klatchko
แหล่งที่มา

7

นอกจากนี้เครื่องจักรของ Honeywell เช่นอาจเป็นเครื่องจักรที่สองที่มีการนำ C มาใช้ ดู K&R เวอร์ชั่น 1

— โปรแกรมเมอร์ของ Windows

5

ที่จริง ธ.ค. 10 ก็ยังได้มีตัวละคร 6 บิต - คุณสามารถแพ็ค 6 ของเหล่านี้เป็นคำ 36 บิต (อดีต ธ.ค. 10 โปรแกรมเมอร์พูด)

2

DEC-20 ใช้อักขระ ASCII 7 บิตห้าตัวต่อคำ 36 บิตบน TOPS-20 O / S

— David R Tribble

3

เรื่องตลกนั้นถูกนำไปใช้จริงสำหรับการสนับสนุน Unicode ในสถาปัตยกรรมนี้

— Joshua

9

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

— bames53

18

ที่ฉันรู้บาง:

ธ.ค. PDP-10: ตัวแปร แต่ส่วนใหญ่มักจะเป็นตัวอักษร 7 บิตบรรจุ 5 ต่อคำ 36 บิตหรืออื่น ๆ 9 บิตตัวอักษร 4 ต่อคำ
เมนเฟรมข้อมูลควบคุม (CDC-6400, 6500, 6600, 7600, Cyber 170, Cyber 176 ฯลฯ ) ตัวอักษรขนาด 6 บิตบรรจุ 10 ตัวต่อคำ 60 บิต
Unisys mainframes: 9 bits / byte
Windows CE: ไม่รองรับประเภท `char` เลย - ต้องใช้ wchar_t 16 บิตแทน

— Jerry Coffin
แหล่งที่มา

2

@ephemient: ฉันค่อนข้างแน่ใจว่ามีคอมไพเลอร์ C อย่างน้อยหนึ่งมาตรฐานสำหรับ PDP-10 / DecSystem 10 / DecSystem 20 ฉันจะแปลกใจมากที่คอมไพเลอร์ C สำหรับเมนเฟรมของ CDC แม้ว่า (พวกเขาคือ ส่วนใหญ่ใช้สำหรับงานที่เป็นตัวเลขดังนั้นคอมไพเลอร์ Fortran จึงเป็นเรื่องใหญ่ที่นั่น) ฉันค่อนข้างมั่นใจว่าคนอื่นมีคอมไพเลอร์ C

— Jerry Coffin

3

คอมไพเลอร์ Windows CE ไม่รองรับcharชนิดเลยหรือไม่? ฉันรู้ว่าไลบรารี่ของระบบรองรับเฉพาะฟังก์ชั่น char แบบกว้างที่รับสายและอย่างน้อย WinCE บางรุ่นก็ลบฟังก์ชั่นสตริง ANSI เช่น strlen เพื่อหยุดการจัดการสตริงอักขระ char แต่จริงๆแล้วมันไม่มีถ่านประเภทนี้เลยเหรอ? อะไรคือสิ่งที่sizeof(TCHAR)? malloc ชนิดใดที่ส่งคืน? byteชนิดของJava ถูกนำไปใช้อย่างไร

— Steve Jessop

10

Windows CE รองรับถ่านซึ่งเป็นไบต์ ดูความคิดเห็นของ Craig McQueen ต่อคำตอบของ Richard Pennington ไบต์มีความจำเป็นเช่นเดียวกับใน Windows CE เช่นเดียวกับที่อื่นไม่ว่าจะมีขนาดใดก็ตาม

— โปรแกรมเมอร์ Windows

2

มีการใช้งาน C อย่างน้อยสองรายการสำหรับ PDP-10: KCC และพอร์ต gcc ( pdp10.nocrew.org/gcc )

— AProgrammer

3

มาตรฐาน C จะไม่อนุญาตให้ใช้ตัวอักษรขนาด 7 บิตที่บรรจุ 5 ตัวต่อคำแบบ 36 บิต (ตามที่คุณกล่าวถึงสำหรับ PDP-10) และจะไม่อนุญาตให้ใช้ตัวอักษรแบบ 6 บิตตามที่คุณกล่าวถึงสำหรับเมนเฟรมข้อมูลการควบคุม ดูparashift.com/c++-faq-lite/intrinsic-types.html#faq-26.6

— Ken Bloom

15

ไม่มีสิ่งเช่นรหัสพกพาอย่างสมบูรณ์ :-)

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

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

ตกลง. คุณสามารถทำการแปลงคำสั่งไบต์และย้ายสมาชิกโครงสร้าง (เช่นuint32_tหรือคล้ายกัน) โดยใช้memcpyลงในบัฟเฟอร์ ทำไมmemcpy? เนื่องจากมีแพลตฟอร์มจำนวนมากที่ไม่สามารถเขียนแบบ 32 บิต (16- บิต, 64- บิต - ไม่แตกต่างกัน) เมื่อที่อยู่เป้าหมายไม่ได้รับการจัดตำแหน่งอย่างเหมาะสม

ดังนั้นคุณได้ทำไปแล้วหลายอย่างเพื่อให้สามารถพกพาได้

และตอนนี้คำถามสุดท้าย เรามีบัฟเฟอร์ ข้อมูลจากมันถูกส่งไปยังเครือข่าย TCP / IP เครือข่ายดังกล่าวถือว่า 8 บิต คำถามคือบัฟเฟอร์ประเภทใดควรเป็นอย่างไร ถ้าตัวอักษรของคุณเป็น 9 บิต? ถ้าเป็น 16 บิต 24? บางทีถ่านแต่ละตัวนั้นตรงกับหนึ่งไบต์ 8 บิตที่ส่งไปยังเครือข่ายและใช้เพียง 8 บิตเท่านั้น หรืออาจมีหลายไบต์เครือข่ายที่บรรจุในตัวอักษรขนาด 24/16/9 บิต? นั่นเป็นคำถามและยากที่จะเชื่อว่ามีคำตอบเดียวที่เหมาะกับทุกกรณี หลายสิ่งขึ้นอยู่กับการใช้ซ็อกเก็ตสำหรับแพลตฟอร์มเป้าหมาย

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

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

— Ellioh
แหล่งที่มา

4

หากหนึ่งเก็บหนึ่ง octet ต่อunsigned charค่าไม่ควรมีปัญหาการพกพาเว้นแต่รหัสจะใช้เทคนิคนามแฝงแทนการเลื่อนเพื่อแปลงลำดับของ octet เป็น / จากประเภทจำนวนเต็มขนาดใหญ่ โดยส่วนตัวแล้วฉันคิดว่ามาตรฐาน C ควรกำหนดอินทรินติกส์ในการแพ็ค / คลายจำนวนเต็มจากลำดับของประเภทที่สั้นกว่า (โดยทั่วไปแล้วchar) จัดเก็บจำนวนบิตต่อชิ้น (8 ต่อunsigned char16 unsigned shortหรือ 32 ต่อunsigned long)

— supercat

9

ดูเหมือนว่าคุณยังสามารถซื้อ IM6100 (เช่น PDP-8 บนชิป) จากคลังสินค้าได้ นั่นเป็นสถาปัตยกรรมแบบ 12 บิต

— dmckee --- ลูกแมวผู้ดูแลอดีต
แหล่งที่มา

9

ชิป DSP หลายคนมี 16 หรือ char32 TI ทำชิปเช่นนี้เป็นประจำ

— Alok Singhal
แหล่งที่มา

5

ตัวอย่างเช่นภาษาการเขียนโปรแกรม C และ C ++ กำหนดไบต์เป็น "หน่วยแอดเดรสของข้อมูลที่มีขนาดใหญ่พอที่จะเก็บสมาชิกของชุดอักขระพื้นฐานของสภาพแวดล้อมการดำเนินการ" (ข้อ 3.6 ของมาตรฐาน C) เนื่องจากชนิดข้อมูลที่รวม C char ต้องมีอย่างน้อย 8 บิต (ข้อ 5.2.4.2.1) ไบต์ใน C อย่างน้อยจึงสามารถเก็บค่าได้ 256 ค่า การใช้งานที่หลากหลายของ C และ C ++ กำหนดไบต์เป็น 8, 9, 16, 32 หรือ 36 บิต

อ้างถึงจากhttp://en.wikipedia.org/wiki/Byte#History

ไม่แน่ใจเกี่ยวกับภาษาอื่น ๆ

http://en.wikipedia.org/wiki/IBM_7030_Stretch#Data_Formats

กำหนดไบต์บนเครื่องนั้นให้เป็นความยาวผันแปรได้

— petantik
แหล่งที่มา

1

"ไม่แน่ใจเกี่ยวกับภาษาอื่น ๆ " - ในอดีตภาษาส่วนใหญ่อนุญาตให้สถาปัตยกรรมของเครื่องกำหนดขนาดไบต์ของตัวเอง ที่จริงแล้วในอดีต C ทำเช่นนั้นจนกระทั่งมาตรฐานกำหนดขอบเขตที่ต่ำกว่าที่ 8

— โปรแกรมเมอร์ Windows

4

ครอบครัว DEC PDP-8 มีคำศัพท์ 12 บิตแม้ว่าคุณมักจะใช้ 8 บิต ASCII สำหรับเอาท์พุท (บน Teletype ส่วนใหญ่) อย่างไรก็ตามยังมีรหัสอักขระ 6 บิตที่อนุญาตให้คุณเข้ารหัส 2 ตัวอักษรในคำ 12 บิตเดียว

— PrgTrdr
แหล่งที่มา

3

สำหรับหนึ่งอักขระ Unicode มีความยาวมากกว่า 8 บิต ดังที่มีคนพูดถึงก่อนหน้านี้ข้อมูลจำเพาะ C กำหนดประเภทข้อมูลตามขนาดขั้นต่ำของพวกเขา ใช้sizeofและค่าในlimits.hหากคุณต้องการสอบถามประเภทข้อมูลของคุณและค้นพบขนาดที่เหมาะสมสำหรับการกำหนดค่าและสถาปัตยกรรมของคุณ

ด้วยเหตุนี้ฉันจึงพยายามยึดติดกับชนิดข้อมูลเช่นuint16_tเมื่อฉันต้องการชนิดข้อมูลที่มีความยาวบิตเฉพาะ

แก้ไข:ขออภัยฉันเริ่มอ่านคำถามของคุณผิด

ข้อมูลจำเพาะ C บอกว่าcharวัตถุมีขนาด "ใหญ่พอที่จะเก็บสมาชิกของชุดอักขระการดำเนินการ" limits.hแสดงรายการขนาดต่ำสุด 8 บิต แต่คำจำกัดความเป็นขนาดสูงสุดของการcharเปิด

ดังนั้น a charอย่างน้อยตราบใดที่อักขระที่ใหญ่ที่สุดจากชุดการดำเนินการของสถาปัตยกรรมของคุณ (โดยทั่วไปจะปัดเศษขึ้นเป็นขอบเขต 8 บิตที่ใกล้ที่สุด) หากสถาปัตย์ของคุณมีรหัสที่ยาวกว่าcharขนาดของคุณอาจจะยาวกว่า

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

stdint.hเมื่อความคิดเกี่ยวกับการสนับสนุนหลายแพลตฟอร์มใช้ประโยชน์จากประเภทที่กำหนดไว้ใน ถ้าคุณใช้ (เช่นบริการ) uint16_t แล้วคุณสามารถมั่นใจได้ว่าค่านี้เป็นค่าไม่ได้ลงนาม 16 บิตบนสถาปัตยกรรมสิ่งที่ไม่ว่าจะสอดคล้องกับค่า 16 บิตไปchar, short, intหรือสิ่งอื่น การทำงานหนักส่วนใหญ่ทำโดยผู้เขียนคอมไพเลอร์ / ไลบรารีมาตรฐานของคุณ

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

— BTA
แหล่งที่มา

2

คำถามไม่ได้ถามถึงตัวละคร (ไม่ว่าจะเป็น Unicode หรือไม่ก็ตาม) มันถามเรื่องถ่านซึ่งเป็นไบต์

— โปรแกรมเมอร์ Windows

1

นอกจากนี้ชุดอักขระการดำเนินการไม่มีส่วนเกี่ยวข้องกับ opcodes เป็นชุดอักขระที่ใช้ในการดำเนินการคิดว่าเป็นตัวรวบรวมข้าม

— ninjalj

"อดีต opcode ของแพลตฟอร์ม x86 มีความยาวหนึ่งไบต์": น่ารักมาก ในอดีต C ได้รับการพัฒนาบน PDP-11 (1972) นานก่อนที่จะมีการคิดค้น x86 (1978)

— Martin Bonner สนับสนุน Monica

3

สิ่งที่ควรคำนึงถึงในการพิจารณาให้กับแพลตฟอร์มที่ไม่ใช่ถ่าน 8 บิต

จำนวนเวทมนตร์เกิดขึ้นเช่นเมื่อขยับ;

ส่วนใหญ่สามารถจัดการได้ง่ายๆโดยใช้ CHAR_BIT และเช่น UCHAR_MAX แทน 8 และ 255 (หรือคล้ายกัน)

หวังว่าการติดตั้งของคุณจะเป็นตัวกำหนด :)

เหล่านี้คือปัญหา "ทั่วไป" .....

ปัญหาทางอ้อมอีกอย่างหนึ่งก็คือคุณมี:

struct xyz {
   uchar baz;
   uchar blah;
   uchar buzz; 
}

สิ่งนี้อาจใช้ "เพียง" (กรณีที่ดีที่สุด) 24 บิตบนแพลตฟอร์มเดียว แต่อาจใช้เวลาเช่น 72 บิตที่อื่น .....

หาก uchar แต่ละคนถือ "ธงบิต" และ uchar แต่ละคนมีบิตหรือธงที่มีนัยสำคัญ "2" ที่คุณใช้อยู่และคุณจัดระเบียบพวกเขาเป็น 3 uchars สำหรับ "ชัดเจน" ดังนั้นมันอาจจะค่อนข้าง "เสียมากกว่า" เช่นใน แพลตฟอร์มที่มี uchars 24 บิต .....

ไม่มีอะไร bitfields ไม่สามารถแก้ไขได้ แต่พวกเขามีสิ่งอื่น ๆ ที่ต้องระวัง ....

ในกรณีนี้เพียงแค่ enum เพียงอันเดียวอาจเป็นวิธีที่จะได้จำนวนเต็มที่น้อยที่สุดที่คุณต้องการ ....

อาจไม่ใช่ตัวอย่างจริง แต่สิ่งนี้ "บิต" ฉันเมื่อย้าย / เล่นด้วยรหัสบางอย่าง .....

ความจริงที่ว่าถ้า uchar นั้นใหญ่กว่าสามเท่าที่คาดไว้ "ปกติ" 100 โครงสร้างดังกล่าวอาจเสียหน่วยความจำจำนวนมากในบางแพลตฟอร์ม ..... ที่ "ปกติ" ไม่ใช่เรื่องใหญ่ .... .

ดังนั้นสิ่งต่าง ๆ ยังสามารถ "เสีย" หรือในกรณีนี้ "เสียหน่วยความจำจำนวนมากอย่างรวดเร็ว" เนื่องจากข้อสันนิษฐานว่า uchar คือ "ไม่สิ้นเปลือง" ในแพลตฟอร์มหนึ่งเทียบกับ RAM ที่มีอยู่มากกว่าบนแพลตฟอร์มอื่น ... ..

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

"ปกติ" คุณอาจแบ่งออกเป็น 2 uchars แต่เช่นด้วย uchar แบบ 24 บิตคุณต้องใช้เพียง .....

ดังนั้น enum อาจเป็นทางออกที่ดีกว่า "ทั่วไป" ....

ขึ้นอยู่กับว่าคุณเข้าถึงบิตเหล่านั้นอย่างไร :)

ดังนั้นอาจมี "ข้อบกพร่องการออกแบบ" ที่อยู่ด้านหลังศีรษะของพวกเขา .... แม้ว่ารหัสอาจยังทำงาน / ทำงานได้ดีโดยไม่คำนึงถึงขนาดของ uchar หรือ uint ...

มีบางอย่างที่ต้องระวังแม้ว่าจะไม่มี "หมายเลขเวทมนตร์" ในรหัสของคุณ ...

หวังว่ามันจะสมเหตุสมผล :)

— วว
แหล่งที่มา

1

...อะไร? ทำไมคุณคิดว่าenumน่าจะมีขนาดเล็กกว่าชนพื้นเมืองประเภทอื่น ๆ คุณทราบintหรือไม่ว่าเป็นค่าเริ่มต้นสำหรับที่เก็บข้อมูลเดียวกันกับ "คุณมีโครงสร้างบางอย่างที่ต้องการ 15 บิตดังนั้นคุณจึงติดไว้ใน int แต่บนแพลตฟอร์มอื่น ๆ บางอย่าง int คือ 48 บิตหรืออะไรก็ตาม ..... " - #include <cstdint>และทำให้เป็นint16_tโอกาสที่ดีที่สุดในการลดการใช้บิต . ฉันไม่แน่ใจจริงๆว่าสิ่งที่คุณคิดว่าคุณพูดในรูปวงรีเหล่านั้น

— underscore_d

1

int เคยเป็น 16 บิต (pdp11 เป็นต้น) การไปที่สถาปัตยกรรม 32 บิตนั้นยาก ผู้คนเริ่มดีขึ้น: แทบไม่มีใครคิดว่าตัวชี้จะพอดีกับอีกต่อไปอีกต่อไป หรือไฟล์ออฟเซ็ตหรือเวลาบันทึกหรือ ...

อักขระ 8 บิตมีความผิดปกติอยู่แล้ว เราต้องการ 32 บิตเพื่อเก็บชุดตัวละครทั้งหมดของโลก

— ริชาร์ดเพนนิงตัน
แหล่งที่มา

2

จริง ชื่อcharนี้ค่อนข้างแปลกตาในวัน Unicode ฉันสนใจเพิ่มเติมเกี่ยวกับหน่วย 8 บิต (octet) เมื่อจัดการกับข้อมูลไบนารีเช่นที่เก็บไฟล์การสื่อสารเครือข่าย uint8_tมีประโยชน์มากขึ้น

— Craig McQueen

3

Unicode ไม่ต้องการบิตเต็ม 32 อันที่จริงแล้ว พวกเขาวางแผนที่เดิมในวันที่ 31 (ดูต้นฉบับ UTF-8 ที่ทำงาน) แต่ตอนนี้พวกเขากำลังเนื้อหาที่มีเพียง 21 บิต พวกเขาอาจรู้ว่าพวกเขาจะไม่สามารถพิมพ์หนังสือได้อีกต่อไปหากต้องการ 31 บิตทั้งหมด: P

— me22

2

@ me22, Unicode เดิมวางแผนไว้สำหรับ 16 บิต "อักขระ Unicode มีความกว้างอย่างสม่ำเสมอ 16 บิตโดยไม่คำนึงถึงภาษา ... " Unicode 1.0.0 unicode.org/versions/Unicode1.0.0/ch01.pdf

— แชนนอนชดเชย

1

ISO 10646 เดิมเป็นบิต 31 บิตและ Unicode ผสานกับ ISO 10646 ดังนั้นจึงอาจเลอะเทอะหากกล่าวว่า Unicode เป็น 31 บิต แต่ก็ไม่จริง โปรดทราบว่าพวกเขาจะไม่พิมพ์ตารางรหัสแบบเต็มอีกต่อไป

— prosfilaes