Tại sao các ký tự C là ints thay vì ký tự?

Trong C ++ sizeof('a') == sizeof(char) == 1,. Điều này có ý nghĩa trực quan, vì 'a'là một ký tự theo nghĩa đen, và sizeof(char) == 1như được định nghĩa bởi tiêu chuẩn.

Tuy nhiên, trong C sizeof('a') == sizeof(int),. Có nghĩa là, có vẻ như các ký tự C thực sự là số nguyên. Có ai biết tại sao không? Tôi có thể tìm thấy rất nhiều đề cập về câu hỏi C này nhưng không có lời giải thích tại sao nó tồn tại.

thảo luận về cùng một chủ đề

"Cụ thể hơn là các quảng cáo tích hợp. Trong K&R C, hầu như (?) Không thể sử dụng một giá trị ký tự mà nó không được thăng cấp thành int trước, vì vậy việc đặt ký tự không đổi int ngay từ đầu đã loại bỏ bước đó. Đã có và vẫn có nhiều ký tự các hằng số chẳng hạn như 'abcd' hoặc tuy nhiên nhiều hằng số sẽ phù hợp với một số nguyên. "

Câu hỏi ban đầu là "tại sao?"

Lý do là định nghĩa của một ký tự chữ đã phát triển và thay đổi, trong khi cố gắng duy trì tương thích ngược với mã hiện có.

Trong những ngày đen tối của đầu C không có loại nào cả. Vào lần đầu tiên tôi học lập trình bằng C, các kiểu đã được giới thiệu, nhưng các hàm không có nguyên mẫu để cho người gọi biết kiểu đối số là gì. Thay vào đó, nó được tiêu chuẩn hóa rằng mọi thứ được truyền dưới dạng tham số sẽ có kích thước của một int (điều này bao gồm tất cả các con trỏ) hoặc nó sẽ là một đôi.

Điều này có nghĩa là khi bạn viết hàm, tất cả các tham số không phải là đôi được lưu trữ trên ngăn xếp dưới dạng int, bất kể bạn khai báo chúng như thế nào và trình biên dịch đặt mã vào hàm để xử lý điều này cho bạn.

Điều này khiến mọi thứ hơi mâu thuẫn, vì vậy khi K&R viết cuốn sách nổi tiếng của họ, họ đã đưa ra quy tắc rằng một ký tự chữ sẽ luôn được thăng cấp thành một int trong bất kỳ biểu thức nào, không chỉ là một tham số hàm.

Khi ủy ban ANSI lần đầu tiên tiêu chuẩn hóa C, họ đã thay đổi quy tắc này để một ký tự chữ đơn giản chỉ là một số nguyên, vì đây có vẻ là một cách đơn giản hơn để đạt được điều tương tự.

Khi C ++ được thiết kế, tất cả các hàm được yêu cầu phải có nguyên mẫu đầy đủ (điều này vẫn không bắt buộc trong C, mặc dù nó được chấp nhận rộng rãi như một phương pháp tốt). Do đó, người ta quyết định rằng một ký tự có thể được lưu trữ trong một ký tự. Ưu điểm của điều này trong C ++ là một hàm có tham số char và một hàm với tham số int có các chữ ký khác nhau. Ưu điểm này không có trong C.

Đây là lý do tại sao chúng khác nhau. Sự phát triển...

Tôi không biết lý do cụ thể tại sao một ký tự trong C thuộc loại int. Nhưng trong C ++, có một lý do chính đáng để không đi theo cách đó. Xem xét điều này:

void print(int);
void print(char);

print('a');

Bạn sẽ mong đợi rằng lệnh in sẽ chọn phiên bản thứ hai lấy một ký tự. Có một ký tự theo nghĩa đen là một int sẽ làm cho điều đó không thể. Lưu ý rằng trong C ++ các ký tự có nhiều hơn một ký tự vẫn có kiểu int, mặc dù giá trị của chúng được xác định thực thi. Vì vậy, 'ab'có loại int, trong khi 'a'có loại char.

bằng cách sử dụng gcc trên MacBook của mình, tôi thử:

#include <stdio.h>
#define test(A) do{printf(#A":\t%i\n",sizeof(A));}while(0)
int main(void){
  test('a');
  test("a");
  test("");
  test(char);
  test(short);
  test(int);
  test(long);
  test((char)0x0);
  test((short)0x0);
  test((int)0x0);
  test((long)0x0);
  return 0;
};

mà khi chạy cho:

'a':    4
"a":    2
"":     1
char:   1
short:  2
int:    4
long:   4
(char)0x0:      1
(short)0x0:     2
(int)0x0:       4
(long)0x0:      4

điều này gợi ý rằng một ký tự là 8 bit, giống như bạn nghi ngờ, nhưng một ký tự theo nghĩa đen là một số nguyên.

Trở lại khi C đang được viết, hợp ngữ MACRO-11 của PDP-11 có:

MOV #'A, R0      // 8-bit character encoding for 'A' into 16 bit register

Loại điều này khá phổ biến trong hợp ngữ - 8 bit thấp sẽ giữ mã ký tự, các bit khác bị xóa thành 0. PDP-11 thậm chí còn có:

MOV #"AB, R0     // 16-bit character encoding for 'A' (low byte) and 'B'

Điều này cung cấp một cách thuận tiện để tải hai ký tự vào byte thấp và byte cao của thanh ghi 16 bit. Sau đó, bạn có thể viết chúng ở nơi khác, cập nhật một số dữ liệu văn bản hoặc bộ nhớ màn hình.

Vậy nên, việc các nhân vật được thăng cấp đăng ký size là điều khá bình thường và đáng mong đợi. Tuy nhiên, giả sử bạn cần đưa 'A' vào thanh ghi không phải là một phần của opcode được mã hóa cứng, mà từ một nơi nào đó trong bộ nhớ chính có chứa:

address: value
20: 'X'
21: 'A'
22: 'A'
23: 'X'
24: 0
25: 'A'
26: 'A'
27: 0
28: 'A'

Nếu bạn chỉ muốn đọc một chữ 'A' từ bộ nhớ chính này vào một thanh ghi, bạn sẽ đọc cái nào?

• Một số CPU có thể chỉ hỗ trợ trực tiếp đọc giá trị 16 bit vào thanh ghi 16 bit, có nghĩa là việc đọc ở 20 hoặc 22 sau đó sẽ yêu cầu các bit từ 'X' được xóa và tùy thuộc vào khả năng sử dụng của CPU này hay khác sẽ cần chuyển sang byte thứ tự thấp.

• Một số CPU có thể yêu cầu đọc căn chỉnh bộ nhớ, có nghĩa là địa chỉ thấp nhất liên quan phải là bội số của kích thước dữ liệu: bạn có thể đọc từ địa chỉ 24 và 25, nhưng không đọc được từ địa chỉ 27 và 28.

Vì vậy, một trình biên dịch tạo mã để lấy một chữ 'A' vào thanh ghi có thể thích lãng phí thêm một chút bộ nhớ và mã hóa giá trị thành 0 'A' hoặc 'A' 0 - tùy thuộc vào endianness và cũng đảm bảo nó được căn chỉnh đúng cách ( tức là không ở một địa chỉ bộ nhớ lẻ).

Tôi đoán là C chỉ đơn giản là thực hiện hành vi tập trung vào CPU ở mức độ này, nghĩ đến các hằng số ký tự chiếm các kích thước thanh ghi của bộ nhớ, dẫn đến đánh giá chung về C là "trình hợp dịch cấp cao".

(Xem 6.3.3 trên trang 6-25 của http://www.dmv.net/dec/pdf/macro.pdf )

Tôi nhớ đã đọc K&R và thấy một đoạn mã sẽ đọc một ký tự tại một thời điểm cho đến khi nó chạm EOF. Vì tất cả các ký tự đều là các ký tự hợp lệ trong một tệp / luồng đầu vào, điều này có nghĩa là EOF không thể là bất kỳ giá trị char nào. Những gì mã đã làm là đặt ký tự đã đọc vào một int, sau đó kiểm tra EOF, sau đó chuyển đổi thành ký tự nếu không.

Tôi nhận ra rằng điều này không trả lời chính xác câu hỏi của bạn, nhưng nó sẽ có ý nghĩa đối với phần còn lại của các ký tự là sizeof (int) nếu ký tự EOF là.

int r;
char buffer[1024], *p; // don't use in production - buffer overflow likely
p = buffer;

while ((r = getc(file)) != EOF)
{
  *(p++) = (char) r;
}

Tôi chưa thấy lý do hợp lý cho nó (các chữ C char là kiểu int), nhưng đây là điều mà Stroustrup phải nói về nó (từ Design and Evolution 11.2.1 - Fine-Grain Resolution):

Trong C, loại ký tự theo nghĩa đen 'a'là int. Đáng ngạc nhiên là việc 'a'nhập charvào C ++ không gây ra bất kỳ vấn đề tương thích nào. Ngoại trừ ví dụ bệnh lý sizeof('a'), mọi cấu trúc có thể được thể hiện bằng cả C và C ++ đều cho kết quả giống nhau.

Vì vậy, phần lớn, nó sẽ không gây ra vấn đề gì.

Lý do lịch sử cho điều này là C và người tiền nhiệm của nó là B, ban đầu được phát triển trên nhiều mẫu máy tính mini DEC PDP khác nhau với nhiều kích cỡ chữ khác nhau, hỗ trợ ASCII 8-bit nhưng chỉ có thể thực hiện số học trên thanh ghi. (Tuy nhiên, không phải PDP-11; nó ra đời sau.) Các phiên bản đầu tiên của C được xác định intlà kích thước từ gốc của máy và bất kỳ giá trị nào nhỏ hơn giá trị intcần được mở rộng intđể được chuyển đến hoặc từ một hàm , hoặc được sử dụng trong một biểu thức bit, logic hoặc số học, vì đó là cách phần cứng bên dưới hoạt động.

Đó cũng là lý do tại sao các quy tắc thăng hạng số nguyên vẫn nói rằng bất kỳ kiểu dữ liệu nào nhỏ hơn an intđều được thăng cấp int. Việc triển khai C cũng được phép sử dụng phép toán phần bù của một người thay vì phần bù của hai phần vì các lý do lịch sử tương tự. Lý do mà ký tự bát phân thoát ra và hằng số bát phân là công dân hạng nhất so với hệ lục phân cũng tương tự như vậy là vì những máy tính mini DEC đầu tiên đó có kích thước từ có thể chia thành các khối ba byte nhưng không phải là bốn byte.

Đây là hành vi chính xác, được gọi là "khuyến mãi tích phân". Nó cũng có thể xảy ra trong các trường hợp khác (chủ yếu là toán tử nhị phân, nếu tôi nhớ không nhầm).

CHỈNH SỬA: Để chắc chắn, tôi đã kiểm tra bản sao Lập trình Expert C: Bí mật sâu sắc của mình và tôi xác nhận rằng một ký tự char không bắt đầu bằng kiểu int . Ban đầu nó có kiểu char nhưng khi nó được sử dụng trong một biểu thức , nó được thăng cấp thành int . Phần sau được trích từ cuốn sách:

Các chữ ký tự có kiểu int và chúng đến đó bằng cách tuân theo các quy tắc để thăng hạng từ kiểu char. Điều này được đề cập quá ngắn gọn trong K&R 1, trên trang 39, nơi có nội dung:

Mọi ký tự trong một biểu thức được chuyển đổi thành int .... Lưu ý rằng tất cả các số float trong một biểu thức đều được chuyển đổi thành double .... Vì đối số của hàm là một biểu thức, nên việc chuyển đổi kiểu cũng diễn ra khi các đối số được truyền cho các hàm: in đặc biệt, char và short trở thành int, float trở thành double.

Tôi không biết, nhưng tôi đoán sẽ dễ dàng hơn để thực hiện nó theo cách đó và nó không thực sự quan trọng. Cho đến khi C ++ khi kiểu có thể xác định hàm nào sẽ được gọi thì nó mới cần được sửa.

Tôi không biết điều này thực sự. Trước khi các nguyên mẫu tồn tại, bất kỳ thứ gì hẹp hơn int đều được chuyển đổi thành int khi sử dụng nó làm đối số hàm. Đó có thể là một phần của lời giải thích.

Điều này chỉ liên quan đến thông số ngôn ngữ, nhưng trong phần cứng, CPU thường chỉ có một kích thước thanh ghi - giả sử là 32 bit - và vì vậy bất cứ khi nào nó thực sự hoạt động trên một ký tự (bằng cách thêm, bớt hoặc so sánh nó) thì có một chuyển đổi ngầm định thành int khi nó được tải vào thanh ghi. Trình biên dịch sẽ xử lý đúng cách che dấu và chuyển số sau mỗi thao tác để nếu bạn thêm, chẳng hạn như 2 vào (unsigned char) 254, nó sẽ quấn quanh 0 thay vì 256, nhưng bên trong silicon nó thực sự là một int cho đến khi bạn lưu lại vào bộ nhớ.

Đó là một quan điểm học thuật bởi vì ngôn ngữ có thể đã chỉ định kiểu chữ 8-bit, nhưng trong trường hợp này, thông số ngôn ngữ sẽ phản ánh gần hơn những gì CPU đang thực sự làm.

(x86 wonks có thể lưu ý rằng có ví dụ: một addh op gốc bổ sung các thanh ghi rộng ngắn trong một bước, nhưng bên trong lõi RISC, điều này chuyển thành hai bước: thêm số, sau đó mở rộng dấu, giống như một cặp add / extsh trên PowerPC)