Neden karakter yerine C karakter değişmez değerleri var?

C ++ 'da sizeof('a') == sizeof(char) == 1. Bu sezgisel anlam ifade eder, çünkü 'a'bir karakter kelimesi kelimesine ve sizeof(char) == 1standart tarafından tanımlandığı gibi.

Ancak C'de sizeof('a') == sizeof(int). Yani, C karakter değişmezlerinin aslında tamsayı olduğu görülmektedir. Nedenini bilen var mı? Bu C tuhaflığından pek çok söz bulabiliyorum ama neden var olduğuna dair bir açıklama yok.

aynı konu üzerine tartışma

"Daha spesifik olarak, integral promosyonlar. K&R C'de, ilk önce int'e yükseltilmeden bir karakter değerini kullanmak neredeyse (?) İmkansızdı, bu nedenle ilk etapta karakteri sabit int yapmak bu adımı ortadan kaldırdı. Çok karakter vardı ve hala var 'abcd' gibi sabitler veya ancak çoğu bir int'e sığar. "

Asıl soru "neden?"

Bunun nedeni, mevcut kodla geriye doğru uyumlu kalmaya çalışırken, gerçek bir karakterin tanımının gelişip değişmesidir.

Erken C'nin karanlık günlerinde hiç tip yoktu. C dilinde programlamayı ilk öğrendiğimde, türler tanıtılmıştı, ancak işlevlerin, arayan kişiye argüman türlerinin ne olduğunu söyleyecek prototipleri yoktu. Bunun yerine, parametre olarak geçirilen her şeyin ya bir int boyutunda (bu tüm işaretçileri içeriyordu) ya da bir double olacağı standartlaştırıldı.

Bu, işlevi yazarken, ikiye katlamayan tüm parametrelerin, onları nasıl bildirmiş olursanız olun, yığında ints olarak saklandığı ve derleyicinin bunu sizin için işlemek için işleve kod koyduğu anlamına geliyordu.

Bu, işleri biraz tutarsız hale getirdi, bu yüzden K&R ünlü kitabını yazdığında, bir karakterin sadece bir fonksiyon parametresi değil, herhangi bir ifadede her zaman bir int'e yükseltileceği kuralını koydular.

ANSI komitesi C'yi ilk kez standartlaştırdığında, bu kuralı değiştirdiler, öyle ki bir karakter değişmezi basitçe bir int olacak, çünkü bu aynı şeyi başarmanın daha basit bir yolu gibi görünüyordu.

C ++ tasarlanırken, tüm işlevlerin tam prototiplere sahip olması gerekiyordu (bu, evrensel olarak iyi uygulama olarak kabul edilmesine rağmen, C'de hala gerekli değildir). Bu nedenle, bir karakterin bir karakterde saklanabileceğine karar verildi. Bunun C ++ 'da avantajı, char parametresi olan bir işlev ile int parametresi olan bir işlevin farklı imzalara sahip olmasıdır. Bu avantaj C'de durum böyle değildir.

Bu yüzden farklılar. Evrim...

C'deki bir karakterin int türünde olmasının belirli nedenlerini bilmiyorum. Ancak C ++ 'da bu şekilde gitmemek için iyi bir neden var. Bunu düşün:

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

print('a');

Yazdırmak için yapılan çağrının bir karakter alarak ikinci versiyonu seçmesini beklersiniz. Tam anlamıyla bir karaktere sahip olmak, bunu imkansız kılar. Birden fazla karaktere sahip olan C ++ değişmez değerlerinde, değerleri uygulama tanımlı olmasına rağmen int türüne sahip olduğuna dikkat edin. Yani, 'ab'türü vardır intederken, 'a'türü vardır char.

MacBook'umda gcc kullanarak şunu deniyorum:

#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;
};

çalıştırıldığında şunu verir:

'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

bu, şüphelendiğiniz gibi bir karakterin 8 bit olduğunu, ancak bir karakterin bir int olduğunu gösterir.

C yazılırken, PDP-11'in MACRO-11 montaj dili şu özelliklere sahipti:

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

Bu tür şeyler, assembly dilinde oldukça yaygındır - düşük 8 bit karakter kodunu tutacaktır, diğer bitler 0'a temizlenir. PDP-11 bile şunlara sahipti:

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

Bu, 16 bitlik yazmacın düşük ve yüksek baytlarına iki karakter yüklemek için uygun bir yol sağladı. Daha sonra bunları başka bir yere yazabilir, bazı metin verilerini veya ekran hafızasını güncelleyebilirsiniz.

Bu nedenle, karakterlerin kayıt boyutuna yükseltilmesi fikri oldukça normal ve arzu edilir bir durumdur. Ancak, sabit kodlu işlem kodunun bir parçası olarak değil, ana bellekte aşağıdakileri içeren bir yerden 'A'yı kaydetmeniz gerektiğini varsayalım:

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

Bu ana bellekten bir kütüğe sadece bir 'A' okumak isterseniz, hangisini okurdunuz?

• Bazı CPU'lar yalnızca 16 bitlik bir değeri 16 bitlik bir sicile okumayı doğrudan destekleyebilir; bu, 20 veya 22'de bir okuma, daha sonra 'X' bitlerinin silinmesini gerektirecek ve CPU'nun sonluluğuna bağlı olarak bir veya diğerine bağlı olacaktır. düşük sıralı bayta geçilmesi gerekir.

• Bazı CPU'lar belleğe göre ayarlanmış bir okuma gerektirebilir, bu da ilgili en düşük adresin veri boyutunun katı olması gerektiği anlamına gelir: 24 ve 25 adreslerinden okuyabilirsiniz, ancak 27 ve 28'den okuyamazsınız.

Bu nedenle, kayda bir 'A' almak için kod üreten bir derleyici, biraz fazladan bellek harcamayı ve değeri sonlanmaya bağlı olarak 0 'A' veya 'A' 0 olarak kodlamayı ve aynı zamanda doğru şekilde hizalandığından emin olmayı tercih edebilir ( yani tek bir hafıza adresinde değil).

Tahminimce, C'nin bu CPU-merkezli davranışı basitçe, bellek kayıt boyutlarını işgal eden karakter sabitlerini düşünerek, C'nin ortak değerlendirmesini "yüksek seviyeli birleştirici" olarak öne sürerek taşıdıklarıdır.

( Http://www.dmv.net/dec/pdf/macro.pdf sayfa 6-25'teki 6.3.3'e bakın )

K&R okuduğumu ve EOF'ye ulaşana kadar her seferinde bir karakteri okuyacak bir kod parçası gördüğümü hatırlıyorum. Tüm karakterler bir dosya / girdi akışında olmak için geçerli karakterler olduğundan, bu EOF'nin herhangi bir karakter değeri olamayacağı anlamına gelir. Kodun yaptığı şey, okuma karakterini bir int'e koymak, ardından EOF için test etmek, sonra değilse bir karaktere dönüştürmekti.

Bunun sorunuzu tam olarak yanıtlamadığını anlıyorum, ancak karakter değişmezlerinin geri kalanının sizeof (int) EOF literali olsaydı bir anlam ifade ederdi.

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

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

Bunun için bir mantık görmedim (C harfleri int tipleridir), ancak işte Stroustrup'un bu konuda söylemesi gereken bir şey var (Design and Evolution 11.2.1 - Fine-Grain Resolution):

C'de 'a'olduğu gibi değişmez bir karakterin türü int. Şaşırtıcı bir şekilde, verme 'a'tipi charC ++ herhangi bir uyumluluk sorun teşkil etmez. Patolojik örnek dışında sizeof('a'), hem C hem de C ++ 'da ifade edilebilen her yapı aynı sonucu verir.

Yani çoğu zaman hiçbir soruna yol açmamalı.

Bunun tarihsel nedeni, C ve onun selefi B'nin başlangıçta 8-bit ASCII'yi destekleyen, ancak kayıtlarda yalnızca aritmetik gerçekleştirebilen çeşitli kelime büyüklüklerine sahip çeşitli DEC PDP mini bilgisayar modelleri üzerinde geliştirilmiş olmasıdır. (PDP-11 değil, ancak daha sonra geldi.) C'nin erken sürümleri int, makinenin yerel kelime boyutu ve bir işleve veya bir işleve aktarılmak üzere intgenişletilmesi gerekenden daha küçük herhangi bir değer olarak tanımlandı . intveya bitsel, mantıksal veya aritmetik bir ifadede kullanılır, çünkü temeldeki donanım bu şekilde çalışıyordu.

Tamsayı terfi kurallarının hala an'dan daha küçük herhangi bir veri türünün intyükseltildiğini söylemesinin nedeni de budur int. C uygulamalarının da benzer tarihsel nedenlerden dolayı ikinin tümleyicisi yerine bir tamamlayıcı matematiği kullanmasına izin verilir. Sekizlik karakter kaçışlarının ve sekizlik sabitlerin onaltılık ile karşılaştırıldığında birinci sınıf vatandaşlar olmalarının nedeni, aynı şekilde, bu erken DEC mini bilgisayarlarının üç baytlık parçalara bölünebilen, ancak dört baytlık atlamalara bölünemeyen sözcük boyutlarına sahip olmasıdır.

Bu, "entegre terfi" adı verilen doğru davranıştır. Diğer durumlarda da olabilir (doğru hatırlıyorsam çoğunlukla ikili operatörler).

DÜZENLEME: Emin olmak için, Expert C Programming: Deep Secrets kopyamı kontrol ettim ve bir char literalinin int tipiyle başlamadığını doğruladım . Bu tip başlangıçta olduğu kömürün ancak bir kullanıldığında ifadesi , bu olduğu terfi bir etmek int . Aşağıdakiler kitaptan alıntılanmıştır:

Karakter değişmezleri int türüne sahiptir ve oraya char türünden yükseltme kurallarını izleyerek ulaşırlar. Bu, sayfa 39'daki K&R 1'de çok kısaca ele alınmıştır:

İfadedeki her karakter int'e dönüştürülür .... Bir ifadedeki tüm float değerlerinin double'a dönüştürüldüğüne dikkat edin .... Bir işlev bağımsız değişkeni bir ifade olduğundan, tür dönüştürmeleri, işlevlere bağımsız değişkenler iletildiğinde de gerçekleşir: özellikle, char ve kısa int olur, float çift olur.

Bilmiyorum, ama bunu bu şekilde uygulamanın daha kolay olduğunu tahmin edeceğim ve gerçekten önemli değildi. Türün hangi işlevin çağrılıp düzeltilmesi gerektiğini belirleyebilmesi C ++ 'ya kadar değildi.

Bunu gerçekten bilmiyordum. Prototipler var olmadan önce, int'ten daha dar olan her şey, işlev argümanı olarak kullanıldığında int'e dönüştürülürdü. Bu açıklamanın bir parçası olabilir.

Bu sadece dil spesifikasyonuna teğetseldir, ancak donanımda CPU genellikle sadece bir yazmaç boyutuna sahiptir - diyelim ki 32 bit - ve bu yüzden gerçekten bir karakter üzerinde çalıştığında (ekleyerek, çıkararak veya karşılaştırarak) kayda yüklendiğinde int'e örtük bir dönüşüm. Derleyici, her işlemden sonra sayıyı düzgün bir şekilde maskelemek ve kaydırmakla ilgilenir, böylece 2'ye (işaretsiz karakter) 254 eklerseniz, 256 yerine 0'a sarılır, ancak silikonun içinde gerçekten bir int olur. hafızaya geri kaydedene kadar.

Bu biraz akademik bir nokta çünkü dil zaten 8 bitlik bir edebi tür belirtmiş olabilir, ancak bu durumda dil spesifikasyonu CPU'nun gerçekte ne yaptığını daha yakından yansıtıyor.

(x86 wonks, örneğin kısa geniş yazmaçları bir adımda ekleyen yerel bir eklenti işleminin olduğunu not edebilir , ancak RISC çekirdeğinin içinde bu iki adıma dönüşür: sayıları ekleyin, ardından işaretini genişletme, ekleme / çıkarma çifti gibi PowerPC)