Nền tảng nào có thứ gì khác ngoài char 8 bit?


136

Thỉnh thoảng, ai đó trên SO chỉ ra rằng char(còn gọi là 'byte') không nhất thiết phải là 8 bit .

Có vẻ như 8-bit charlà gần như phổ quát. Tôi sẽ phải suy nghĩ rằng cho các nền tảng chủ đạo, nó là cần thiết để có một 8-bit charđể đảm bảo tính khả thi của nó trên thị trường.

Cả bây giờ và trong lịch sử, nền tảng nào sử dụng char8 bit không phải là 8 bit và tại sao chúng lại khác với 8 bit "bình thường"?

Khi viết mã và suy nghĩ về hỗ trợ đa nền tảng (ví dụ: đối với các thư viện sử dụng chung), loại cân nhắc nào đáng để đưa ra cho các nền tảng không có 8 bit char?

Trước đây, tôi đã bắt gặp một số DSP thiết bị tương tự có char16 bit. DSP là một chút của một kiến ​​trúc thích hợp tôi cho rằng. (Sau đó, một lần nữa, tại thời điểm trình biên dịch mã hóa bằng tay dễ dàng đánh bại những gì trình biên dịch C có sẵn có thể làm, vì vậy tôi không thực sự có được nhiều kinh nghiệm với C trên nền tảng đó.)


9
Sê-ri CDC Cyber ​​có mã hóa 6/12 bit. Các ký tự phổ biến nhất là 6 bit. Các ký tự còn lại sử dụng 12 bit.
Thomas Matthews

2
PDP-11 đóng đinh nó xuống. Khái niệm rằng một nhân vật có thể được mã hóa trong char là lỗi thời nghiêm trọng.
Hans Passant

7
"PDP-11 đóng đinh nó xuống" - Ý bạn là vì C lần đầu tiên được triển khai cho PDP-11 với 8 bit byte? Nhưng C đã được triển khai tiếp theo cho các máy Honeywell có 9 bit byte. Xem phiên bản K & R 1. Ngoài ra, câu hỏi được hỏi về char (tức là byte) không phải về ký tự (một hoặc nhiều byte mã hóa thứ gì đó không được hỏi về).
Lập trình viên Windows

6
DEC-10 và DEC-20 có các từ 36 bit. Năm ký tự ASCII 7 bit cho mỗi từ là khá phổ biến. Ngoài ra sáu ký tự 6 bit đã được sử dụng.
David R Tribble

3
@CraigMcQueen: Nếu tôi nhớ chính xác, CodeVision cho bộ vi điều khiển Atmel cho phép một người chọn kích thước của char
vsz

Câu trả lời:


80

charcũng là 16 bit trên DSP C54x của Texas, được bật lên trong OMAP2. Có các DSP khác ngoài đó với 16 và 32 bit char. Tôi nghĩ tôi thậm chí đã nghe về DSP 24 bit, nhưng tôi không thể nhớ những gì, vì vậy có lẽ tôi đã tưởng tượng ra nó.

Một xem xét khác là các nhiệm vụ POSIX CHAR_BIT == 8. Vì vậy, nếu bạn đang sử dụng POSIX, bạn có thể sử dụng nó. Nếu sau này ai đó cần chuyển mã của bạn sang POSIX sắp triển khai, điều đó thật sự có chức năng bạn sử dụng nhưng có kích thước khác char, đó là điều không may mắn của họ.

Tuy nhiên, nói chung, tôi nghĩ rằng hầu như luôn luôn dễ dàng giải quyết vấn đề hơn là nghĩ về nó. Chỉ cần gõ CHAR_BIT. Nếu bạn muốn một loại 8 bit chính xác, sử dụng int8_t. Mã của bạn sẽ thất bại trong việc biên dịch các triển khai không cung cấp một mã, thay vì âm thầm sử dụng kích thước bạn không mong đợi. Ít nhất, nếu tôi gặp phải một trường hợp mà tôi có lý do chính đáng để thừa nhận nó, thì tôi sẽ khẳng định điều đó.


2
Các DSP TI C62xx và C64xx cũng có ký tự 16 bit. (uint8_t không được xác định trên nền tảng đó.)
myron-semack

7
Nhiều DSP để xử lý âm thanh là máy 24 bit; các DSPS của MaisonSigna từ On Semi (sau khi họ mua AMI Semi); các DSP56K / Symphony âm thanh DSP từ Freescale (sau khi họ đã tách ra từ Motorola).
David Cary

2
@msemack C64xx có phần cứng cho ngày 16/8/2016 và 8bit char
user3528438

4
Thay vì assert()(nếu đó là ý bạn), tôi sẽ sử dụng #if CHAR_BIT != 8... #error "I require CHAR_BIT == 8"...#endif
Keith Thompson

1
@KeithThndry Có lý do nào để không sử dụng static_assert()không?
Qix - MONICA ĐƯỢC PHÂN BIỆT 17/2/2017

37

Khi viết mã và suy nghĩ về hỗ trợ đa nền tảng (ví dụ: đối với các thư viện sử dụng chung), loại cân nhắc nào đáng để đưa ra cho các nền tảng có char không 8 bit?

Nó không quá nhiều đến nỗi nó "đáng để xem xét" cho một cái gì đó vì nó đang chơi theo luật. Ví dụ, trong C ++, tiêu chuẩn cho biết tất cả các byte sẽ có "ít nhất" 8 bit. Nếu mã của bạn giả định rằng byte có chính xác 8 bit, bạn đang vi phạm tiêu chuẩn.

Điều này có vẻ ngớ ngẩn bây giờ - " tất nhiên tất cả các byte có 8 bit!", Tôi nghe bạn nói. Nhưng rất nhiều người rất thông minh đã dựa vào các giả định không đảm bảo, và rồi mọi thứ vỡ lở. Lịch sử là đầy đủ với các ví dụ như vậy.

Ví dụ, hầu hết các nhà phát triển đầu thập niên 90 cho rằng một độ trễ thời gian CPU không hoạt động cụ thể trong một số chu kỳ cố định sẽ mất một khoảng thời gian cố định, bởi vì hầu hết các CPU tiêu dùng đều có công suất tương đương. Thật không may, máy tính đã nhanh hơn rất nhanh. Điều này đã tạo ra sự gia tăng của các hộp với các nút "Turbo" - với mục đích, trớ trêu thay, là làm chậm máy tính để các trò chơi sử dụng kỹ thuật trì hoãn thời gian có thể được chơi ở tốc độ hợp lý.


Một người bình luận hỏi nơi nào trong tiêu chuẩn nói rằng char phải có ít nhất 8 bit. Nó nằm trong mục 5.2.4.2.1 . Phần này định nghĩa CHAR_BIT, số bit trong thực thể có địa chỉ nhỏ nhất và có giá trị mặc định là 8. Nó cũng cho biết:

Các giá trị được xác định khi thực hiện của chúng phải bằng hoặc lớn hơn về độ lớn (giá trị tuyệt đối) với các giá trị được hiển thị, có cùng dấu.

Vì vậy, bất kỳ số nào bằng 8 hoặc cao hơn là phù hợp để thay thế bằng cách thực hiện thành CHAR_BIT.


6
Tôi đã không thấy một nút Turbo trong ít nhất 20 năm - bạn có thực sự nghĩ rằng đó là nguyên nhân của câu hỏi không?
Đánh dấu tiền chuộc

29
@Mark Ransom: Đó là toàn bộ vấn đề. Các nhà phát triển thường dựa vào các giả định có vẻ là đúng vào thời điểm này, nhưng nó run hơn nhiều so với lúc đầu chúng xuất hiện. (Không thể đếm số lần tôi mắc lỗi đó !) Nút Turbo phải là một lời nhắc nhở đau đớn để không đưa ra các giả định không cần thiết và chắc chắn không đưa ra các giả định không được đảm bảo theo tiêu chuẩn ngôn ngữ như thể chúng là sự thật bất biến.
John Women'sella

1
Bạn có thể chỉ ra để đặt trong C ++ Standard nói rằng bye có ít nhất 8 bit không? Đó là một niềm tin phổ biến tuy nhiên cá nhân tôi đã không tìm thấy nó trong Tiêu chuẩn. Điều duy nhất tôi tìm thấy trong Standard là các ký tự phải được thể hiện bằng cách charcó hơn 64 trong số chúng nhưng ít hơn 128 bit thì 7 bit là đủ.
Adam Badura

6
Mục 18.2.2 gọi tiêu chuẩn C cho nó. Trong tiêu chuẩn C, phần 7.10 và sau đó là phần 5.4.2.4.1. Trang 22 trong tiêu chuẩn C.
Lập trình viên Windows

2
Vì vậy, các câu trả lời và nhận xét khác đề cập đến các máy có byte 5 bit, 6 bit và 7 bit. Điều đó có nghĩa là bạn không thể chạy chương trình C trên máy đó phù hợp với tiêu chuẩn?
Jerry Jeremiah

34

Các máy có kiến ​​trúc 36 bit có byte 9 bit. Theo Wikipedia, các máy có kiến ​​trúc 36 bit bao gồm:

  • Tổng công ty thiết bị kỹ thuật số PDP-6/10
  • IBM 701/704/709/7090/7094
  • UNIVAC 1103 / 1103A / 1105/1002/2100,

7
Ngoài ra các máy Honeywell, chẳng hạn như có thể là máy thứ hai nơi C được triển khai. Xem phiên bản K & R 1.
Lập trình viên Windows

5
Trên thực tế, Dec-10 cũng đã ký tự 6-bit - bạn có thể đóng gói 6 trong số này thành một từ 36-bit (ví dụ-Dec-10 lập trình viên nói chuyện)

2
DEC-20 đã sử dụng năm ký tự ASCII 7 bit cho mỗi từ 36 bit trên TOPS-20 O / S.
David R Tribble

3
Trò đùa đó thực sự đã được triển khai để hỗ trợ Unicode trên kiến ​​trúc này.
Joshua

9
Tôi tưởng tượng rằng lý do bát phân thực sự được sử dụng là vì 3 chữ số bát phân biểu thị gọn gàng một byte 9 bit, giống như chúng ta thường sử dụng thập lục phân ngày nay bởi vì hai chữ số thập lục phân đại diện gọn gàng cho một byte 8 bit.
bames53

18

Một vài trong số đó tôi biết:

  • DEC PDP-10: biến, nhưng hầu hết các ký tự 7 bit được đóng gói 5 trên mỗi từ 36 bit, hoặc các ký tự 9 bit khác, 4 ký tự mỗi từ
  • Các máy tính lớn dữ liệu điều khiển (CDC-6400, 6500, 6600, 7600, Cyber ​​170, Cyber ​​176, v.v.) ký tự 6 bit, đóng gói 10 trên mỗi từ 60 bit.
  • Unisys máy tính lớn: 9 bit / byte
  • Windows CE: đơn giản là hoàn toàn không hỗ trợ kiểu `char` - yêu cầu wchar_t 16 bit

2
@ephemient: Tôi khá chắc chắn rằng có ít nhất một trình biên dịch C (tiền chuẩn) cho PDP-10 / DecSystem 10 / DecSystem 20. Mặc dù vậy, tôi rất ngạc nhiên về trình biên dịch C cho các máy tính lớn CDC (chúng là được sử dụng chủ yếu cho công việc số, vì vậy trình biên dịch Fortran là thứ lớn ở đó). Tôi khá chắc chắn những người khác có trình biên dịch C.
Jerry Coffin

3
Trình biên dịch Windows CE có thực sự không hỗ trợ charkiểu này không? Tôi biết rằng các thư viện hệ thống chỉ hỗ trợ các phiên bản char rộng của các hàm có chuỗi và ít nhất một số phiên bản WinCE đã loại bỏ các hàm chuỗi ANSI như strlen, để ngăn bạn thực hiện xử lý chuỗi char. Nhưng nó thực sự không có một loại char nào cả? Là bao nhiêu sizeof(TCHAR)? Loại malloc đã trở lại? byteKiểu Java được triển khai như thế nào?
Steve Jessop

10
Windows CE hỗ trợ char, là một byte. Xem bình luận của Craig McQueen về câu trả lời của Richard Pennington. Byte là cần thiết trong Windows CE như mọi nơi khác, bất kể kích thước của chúng ở mọi nơi khác.
Lập trình viên Windows

2
Có (đã?) Ít nhất hai lần triển khai C cho PDP-10: KCC và cổng gcc ( pdp10.nocrew.org/gcc ).
AProgrammer

3
Tiêu chuẩn C sẽ không cho phép các ký tự 7 bit được đóng gói 5 trên mỗi từ 36 bit (như bạn đã đề cập cho PDP-10), cũng như không cho phép các ký tự 6 bit, như bạn đã đề cập cho các khung chính của Dữ liệu điều khiển. Xem parashift.com/c++-faq-lite/intrinsic-types.html#faq-26.6
Ken Bloom

15

Không có thứ gọi là mã di động hoàn toàn. :-)

Có, có thể có nhiều kích cỡ byte / char. Có, có thể có các triển khai C / C ++ cho các nền tảng có giá trị rất khác thường CHAR_BITUCHAR_MAX. Có, đôi khi có thể viết mã không phụ thuộc vào kích thước char.

Tuy nhiên, hầu như bất kỳ mã thực sự không phải là độc lập. Ví dụ, bạn có thể đang viết một mã gửi tin nhắn nhị phân đến mạng (giao thức không quan trọng). Bạn có thể xác định cấu trúc có chứa các trường cần thiết. Hơn bạn phải tuần tự hóa nó. Chỉ sao chép nhị phân một cấu trúc vào bộ đệm đầu ra là không khả dụng: nói chung bạn không biết thứ tự byte cho nền tảng, cũng như căn chỉnh thành viên cấu trúc, do đó cấu trúc chỉ giữ dữ liệu, nhưng không mô tả cách dữ liệu được tuần tự hóa .

Đồng ý. Bạn có thể thực hiện các phép biến đổi thứ tự byte và di chuyển các thành viên cấu trúc (ví dụ uint32_thoặc tương tự) bằng cách sử dụng memcpyvào bộ đệm. Tại sao memcpy? Bởi vì có rất nhiều nền tảng trong đó không thể ghi 32 bit (16 bit, 64 bit - không có sự khác biệt) khi địa chỉ đích không được căn chỉnh chính xác.

Vì vậy, bạn đã làm rất nhiều để đạt được tính di động.

Và bây giờ là câu hỏi cuối cùng. Chúng tôi có một bộ đệm. Dữ liệu từ nó được gửi đến mạng TCP / IP. Mạng như vậy giả sử byte 8 bit. Câu hỏi là: loại đệm nên là gì? Nếu ký tự của bạn là 9 bit? Nếu chúng là 16-bit? 24? Có lẽ mỗi char tương ứng với một byte 8 bit được gửi đến mạng và chỉ có 8 bit được sử dụng? Hoặc có thể nhiều byte mạng được đóng gói thành các ký tự 24/16 / 9-bit? Đó là một câu hỏi, và thật khó để tin rằng có một câu trả lời duy nhất phù hợp với mọi trường hợp. Rất nhiều thứ phụ thuộc vào việc thực hiện socket cho nền tảng đích.

Vì vậy, những gì tôi đang nói về. Thông thường mã có thể tương đối dễ dàng thực hiện di động ở một mức độ nhất định . Điều này rất quan trọng để làm như vậy nếu bạn muốn sử dụng mã trên các nền tảng khác nhau. Tuy nhiên, việc cải thiện tính di động vượt ra ngoài biện pháp đó là một việc đòi hỏi rất nhiều nỗ lực và thường mang lại rất ít , vì mã thực sự hầu như luôn phụ thuộc vào mã khác (thực hiện socket trong ví dụ trên). Tôi chắc chắn rằng với khoảng 90% khả năng mã để hoạt động trên các nền tảng có byte khác 8 bit là gần như vô dụng, vì nó sử dụng môi trường bị ràng buộc với 8 bit. Chỉ cần kiểm tra kích thước byte và thực hiện xác nhận thời gian biên dịch. Bạn gần như chắc chắn sẽ phải viết lại rất nhiều cho một nền tảng rất khác thường.

Nhưng nếu mã của bạn rất "độc lập" - tại sao không? Bạn có thể viết nó theo cách cho phép các kích cỡ byte khác nhau.


4
Nếu một người lưu trữ một octet trên mỗi unsigned chargiá trị thì sẽ không có vấn đề về tính di động trừ khi mã sử dụng các thủ thuật răng cưa thay vì dịch chuyển để chuyển chuỗi các octet thành / từ các loại số nguyên lớn hơn. Cá nhân, tôi nghĩ rằng tiêu chuẩn C nên xác định nội tại để đóng gói / giải nén số nguyên từ các chuỗi loại ngắn hơn (điển hình nhất char) lưu trữ số bit có sẵn được bảo đảm cố định cho mỗi mục (8 mỗi unsigned char, 16 mỗi unsigned shorthoặc 32 mỗi unsigned long).
supercat


9

Nhiều chip DSP có 16 hoặc 32 bit char. TI thường xuyên làm cho các chip như vậy chẳng hạn .


5

Ví dụ, ngôn ngữ lập trình C và C ++, định nghĩa byte là "đơn vị dữ liệu có thể định địa chỉ đủ lớn để chứa bất kỳ thành viên nào trong bộ ký tự cơ bản của môi trường thực thi" (điều 3.6 của tiêu chuẩn C). Do kiểu dữ liệu tích phân C char phải chứa ít nhất 8 bit (điều 5.2.4.2.1), một byte trong C ít nhất có khả năng chứa 256 giá trị khác nhau. Việc triển khai C và C ++ khác nhau xác định một byte là 8, 9, 16, 32 hoặc 36 bit

Trích dẫn từ http://en.wikipedia.org/wiki/Byte#History

Không chắc chắn về các ngôn ngữ khác mặc dù.

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

Xác định một byte trên máy đó có độ dài thay đổi


1
"Không chắc chắn về các ngôn ngữ khác" - trong lịch sử, hầu hết các ngôn ngữ cho phép kiến ​​trúc của máy xác định kích thước byte của chính nó. Trên thực tế lịch sử cũng vậy, C cho đến khi tiêu chuẩn đặt giới hạn dưới ở mức 8.
Lập trình viên Windows

4

Họ DEC PDP-8 có từ 12 bit mặc dù bạn thường sử dụng ASCII 8 bit cho đầu ra (chủ yếu trên Teletype). Tuy nhiên, cũng có mã ký tự 6 BIT cho phép bạn mã hóa 2 ký tự trong một từ 12 bit.


3

Đối với một, các ký tự Unicode dài hơn 8 bit. Như ai đó đã đề cập trước đó, thông số C xác định các loại dữ liệu theo kích thước tối thiểu của chúng. Sử dụng sizeofvà các giá trị trong limits.hnếu bạn muốn thẩm vấn các loại dữ liệu của mình và khám phá chính xác kích thước của chúng đối với cấu hình và kiến ​​trúc của bạn.

Vì lý do này, tôi cố gắng bám vào các loại dữ liệu như uint16_tkhi tôi cần một loại dữ liệu có độ dài bit cụ thể.

Chỉnh sửa: Xin lỗi, ban đầu tôi đọc sai câu hỏi của bạn.

Thông số C nói rằng một charđối tượng "đủ lớn để lưu trữ bất kỳ thành viên nào của bộ ký tự thực thi". limits.hliệt kê kích thước tối thiểu 8 bit, nhưng định nghĩa để lại kích thước tối đa của một charmở.

Do đó, a charít nhất là ký tự lớn nhất trong tập thực thi kiến ​​trúc của bạn (thường được làm tròn đến ranh giới 8 bit gần nhất). Nếu kiến ​​trúc của bạn có opcodes dài hơn, charkích thước của bạn có thể dài hơn.

Trong lịch sử, opcode của nền tảng x86 dài một byte, do đó charban đầu là một giá trị 8 bit. Các nền tảng x86 hiện tại hỗ trợ các mã dài hơn một byte, nhưng charđược giữ ở độ dài 8 bit vì đó là điều mà các lập trình viên (và khối lượng lớn mã x86 hiện tại) được điều chỉnh.

Khi suy nghĩ về hỗ trợ đa nền tảng, hãy tận dụng các loại được xác định trong stdint.h. Nếu bạn sử dụng (ví dụ) một uint16_t, sau đó bạn có thể chắc chắn rằng giá trị này là một giá trị 16-bit unsigned trên bất kỳ kiến trúc, cho dù đó tương ứng với giá trị 16-bit sang char, short, int, hay cái gì khác. Hầu hết các công việc khó khăn đã được thực hiện bởi những người đã viết trình biên dịch / thư viện chuẩn của bạn.

Nếu bạn cần biết kích thước chính xác của một charvì bạn đang thực hiện một số thao tác phần cứng cấp thấp yêu cầu nó, tôi thường sử dụng loại dữ liệu đủ lớn để giữ chartrên tất cả các nền tảng được hỗ trợ (thường là 16 bit là đủ) và chạy giá trị thông qua một convert_to_machine_charthói quen khi tôi cần đại diện máy chính xác. Bằng cách đó, mã dành riêng cho nền tảng được giới hạn trong chức năng giao diện và hầu hết thời gian tôi có thể sử dụng bình thường uint16_t.


2
Câu hỏi không hỏi về các ký tự (có phải là Unicode hay không). Nó hỏi về char, đó là một byte.
Lập trình viên Windows

1
Ngoài ra, bộ ký tự thực thi không liên quan gì đến opcodes, đó là bộ ký tự được sử dụng khi thực thi, hãy nghĩ đến các trình biên dịch chéo.
ninjalj

"Trong lịch sử, opcode của nền tảng x86 dài một byte": thật ngọt ngào. Trong lịch sử , C được phát triển trên PDP-11 (1972), rất lâu trước khi x86 được phát minh (1978).
Martin Bonner hỗ trợ Monica

3

loại cân nhắc nào đáng để đưa ra cho các nền tảng với char không 8 bit?

số ma thuật xảy ra, ví dụ như khi thay đổi;

hầu hết trong số này có thể được xử lý khá đơn giản bằng cách sử dụng CHAR_BIT và ví dụ UCHAR_MAX thay vì 8 và 255 (hoặc tương tự).

Hy vọng việc thực hiện của bạn xác định những điều đó :)

đó là những vấn đề "phổ biến" .....

một vấn đề gián tiếp khác là bạn có:

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

điều này có thể "chỉ" lấy (trường hợp tốt nhất) 24 bit trên một nền tảng, nhưng có thể mất ví dụ 72 bit ở nơi khác .....

nếu mỗi uchar giữ "cờ bit" và mỗi uchar chỉ có 2 bit hoặc cờ "đáng kể" mà bạn hiện đang sử dụng và bạn chỉ sắp xếp chúng thành 3 uchar để "rõ ràng", thì có thể tương đối "lãng phí" hơn một nền tảng với uchars 24 bit .....

không có gì bitfield không thể giải quyết, nhưng họ có những thứ khác để đề phòng ....

trong trường hợp này, chỉ một enum có thể là một cách để có được số nguyên có kích thước "nhỏ nhất" mà bạn thực sự cần ....

có lẽ không phải là một ví dụ thực tế, nhưng những thứ như "bit" này khi tôi chuyển / chơi với một số mã .....

thực tế là nếu một con uchar có ba lần lớn như những gì "bình thường" mong đợi, 100 cấu trúc như vậy có thể lãng phí rất nhiều bộ nhớ trên một số nền tảng ..... trong đó "thông thường" không phải là vấn đề lớn .... .

do đó, mọi thứ vẫn có thể bị "hỏng" hoặc trong trường hợp này "lãng phí rất nhiều bộ nhớ rất nhanh" do một giả định rằng một uchar "không lãng phí" trên một nền tảng, liên quan đến RAM có sẵn, so với trên nền tảng khác ... ..

vấn đề có thể nổi bật hơn, ví dụ như đối với int, hoặc các loại khác, ví dụ: bạn có một số cấu trúc cần 15 bit, vì vậy bạn gắn nó vào một int, nhưng trên một số nền tảng khác, int là 48 bit hoặc bất cứ điều gì .... .

"bình thường" bạn có thể chia nó thành 2 uchar, nhưng ví dụ với uchar 24 bit bạn chỉ cần một .....

vì vậy một enum có thể là một giải pháp "chung chung" tốt hơn ....

phụ thuộc vào cách bạn đang truy cập vào các bit đó :)

vì vậy, có thể có "lỗi thiết kế" phía sau đầu của họ .... ngay cả khi mã vẫn có thể hoạt động / chạy tốt bất kể kích thước của uchar hay uint ...

có những thứ như thế này để đề phòng, mặc dù không có "số ma thuật" nào trong mã của bạn ...

hy vọng điều này có ý nghĩa :)


1
...gì? Tại sao bạn nghĩ rằng enumcó khả năng nhỏ hơn các loại bản địa khác? Bạn có biết nó mặc định cho cùng một bộ lưu trữ intkhông? "bạn có một số cấu trúc cần 15 bit, vì vậy bạn gắn nó vào int, nhưng trên một số nền tảng khác, int là 48 bit hoặc bất cứ thứ gì ....." - vì vậy #include <cstdint>, hãy tạo int16_tcơ hội tốt nhất để giảm thiểu việc sử dụng bit . Tôi thực sự không chắc những gì bạn nghĩ bạn đã nói trong số tất cả những dấu chấm lửng đó.
underscore_d

1

ints được sử dụng là 16 bit (pdp11, v.v.). Đi đến kiến ​​trúc 32 bit là khó khăn. Mọi người đang trở nên tốt hơn: Hầu như không ai cho rằng một con trỏ sẽ phù hợp lâu hơn nữa (bạn không đúng chứ?). Hoặc bù đắp tập tin, hoặc dấu thời gian, hoặc ...

Các ký tự 8 bit đã phần nào lỗi thời. Chúng tôi đã cần 32 bit để chứa tất cả các bộ ký tự của thế giới.


2
Thật. Tên charbây giờ hơi lạ trong những ngày Unicode. Tôi quan tâm nhiều hơn về các đơn vị 8 bit (octet) khi xử lý dữ liệu nhị phân, ví dụ như lưu trữ tệp, truyền thông mạng. uint8_thữu ích hơn
Craig McQueen

3
Unicode thực sự không bao giờ cần 32 bit đầy đủ. Ban đầu họ dự định cho 31 (xem tác phẩm UTF-8 ban đầu), nhưng bây giờ chúng chỉ có nội dung với 21 bit . Có lẽ họ nhận ra rằng họ sẽ không thể in sách nữa nếu họ thực sự cần tất cả 31 bit: P
me22

2
@ me22, Unicode ban đầu được lên kế hoạch cho 16 bit. "Các ký tự Unicode luôn rộng 16 bit, bất kể ngôn ngữ ..." Unicode 1.0.0. unicode.org/versions/Unicode1.0.0/ch01.pdf .
Shannon Severance

1
ISO 10646 ban đầu là 31 bit và Unicode được hợp nhất với ISO 10646, do đó có thể rất cẩu thả khi nói rằng Unicode là 31 bit, nhưng nó không thực sự sai. Lưu ý rằng họ không thực sự in các bảng mã đầy đủ nữa.
prosfilaes
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.