size_t ve uintptr_t karşılaştırması

C standardı size_t, herhangi bir dizi dizinini tutabilen bir tür olduğunu garanti eder . Bu, mantıksal olarak size_therhangi bir işaretçi türünü tutabilmesi gerektiği anlamına gelir . Google'da bulduğum bazı sitelerde bunun yasal olduğunu ve / veya her zaman çalışması gerektiğini okudum:

void *v = malloc(10);
size_t s = (size_t) v;

Böylece C99'da, standart , işaretçileri tutabilen garanti edilen imzalı ve imzasız tipler intptr_tve uintptr_ttürlerini tanıttı :

uintptr_t p = (size_t) v;

Peki size_tve ile arasındaki fark uintptr_tnedir? Her ikisi de imzasızdır ve her ikisi de herhangi bir işaretçi türünü tutabilmelidir, bu nedenle işlevsel olarak aynı görünürler. Netlik dışında a yerine kullanmak için gerçek bir zorlayıcı neden var mı uintptr_t(ya da daha iyisi, a void *) size_t? Alanın sadece dahili işlevlerle ele alınacağı opak bir yapıda, bunu yapmamak için herhangi bir neden var mı?

Aynı şekilde, ptrdiff_tişaretçi farklılıklarını tutabilen ve bu nedenle herhangi bir işaretçiyi en fazla tutabilen imzalı bir tür olmuştur, peki nasıl farklıdır intptr_t?

Bu türlerin tümü temelde aynı işlevin önemsiz derecede farklı sürümlerini sunmuyor mu? Değilse, neden? Biriyle diğerini yapamayacağım ne yapamam? Öyleyse, C99 neden dile temel olarak iki gereksiz tür ekledi?

Onlar mevcut sorun için geçerli değil, ama onlar "doğru" cevap merkezi olacak gizlice bir şüphe var gibi, onları belirtmekten çekinmeyin, işlev işaretçileri göz ardı etmeye hazırım.

size_therhangi bir dizi dizinini tutabilen bir türdür. Bu, mantıksal olarak size_t öğesinin herhangi bir işaretçi türünü tutabilmesi gerektiği anlamına gelir

Şart değil! Örneğin, bölümlere ayrılmış 16 bit mimarilerin günlerine geri dönün: bir dizi tek bir bölümle sınırlı olabilir (bu nedenle 16 bit size_tolur) AMA birden çok bölümünüz olabilir (bu nedenle 32 bitlik bir intptr_ttür gerekli olacaktır segment ve içindeki ofset). Bu şeylerin tekdüze adreslenmemiş bölümlenmemiş mimarilerin garip geldiğini biliyorum, ancak standart "2009'da normal olandan" daha geniş bir çeşitlilik sağlaması GEREKİR!

İfadenizle ilgili olarak:

"C standardı size_t, herhangi bir dizi dizinini tutabilen bir tür olduğunu garanti eder . Bu, mantıksal olarak size_therhangi bir işaretçi türünü tutabilmesi gerektiği anlamına gelir ."

Bu aslında bir yanlıştır (yanlış akıl yürütmeden kaynaklanan bir yanlış anlama) ^(a) . Sen olabilir düşünmek ikincisi eski izler ama aslında böyle değil.

İşaretçiler ve dizi dizinleri aynı şey değildir . Dizileri 65536 öğeyle sınırlayan, ancak işaretçilerin herhangi bir değeri büyük bir 128 bit adres alanına yönlendirmesine izin veren uygun bir uygulamayı öngörmek oldukça mantıklıdır.

C99, bir size_tdeğişkenin üst sınırının tarafından tanımlandığını SIZE_MAXve bunun 65535 kadar düşük olabileceğini belirtir (bakınız C99 TR3, 7.18.3, C11'de değişmedi). Modern sistemlerde bu aralıkla sınırlı olsaydı, işaretçiler oldukça sınırlı olurdu.

Uygulamada, muhtemelen varsayımınızın geçerli olduğunu göreceksiniz, ancak bunun nedeni standardın bunu garanti etmesi değildir. Çünkü aslında bunu garanti etmez .

^(A) Bu arada bir tür kişisel saldırı değildir , sadece ifadelerinizin eleştirel düşünme bağlamında neden hatalı olduğunu belirtir. Örneğin, aşağıdaki mantık da geçersizdir:

Tüm yavrular sevimli. Bu şey çok tatlı. Bu nedenle bu şey bir köpek yavrusu olmalı.

Burada zekâ ya da başka bir şekilde köpek yavrusu, hiçbir şey ifade etmiyorum, iki gerçek sonuca yol açmaz, çünkü ilk iki cümle yavru olmayan sevimli şeylerin varlığına izin verir .

Bu, ilk ifadenize benzer, ikinciyi zorunlu kılmak zorunda değildir.

Segment kısıtlamaları, egzotik mimariler vb. İle akıl yürütme ile ilgili diğer tüm cevapların kendileri için bırakmasına izin vereceğim.

İsimlerdeki basit fark değil , uygun olanı doğru şey için kullanmak için yeterli değil mi?

Bir boyut saklıyorsanız, kullanın size_t. Bir işaretçi saklıyorsanız,intptr_t . Kodunuzu okuyan bir kişi anında "aha, bunun muhtemelen bayt cinsinden bir boyutudur" ve "oh, işte bir nedenle tamsayı olarak saklanan bir işaretçi değerinin" olduğunu bilir.

Aksi takdirde, her şey için kullanabilirsiniz unsigned long(veya bu modern zamanlarda unsigned long long). Boyut her şey değildir, tür adları programı tanımlamaya yardımcı olduğu için faydalı olan anlam taşır.

En büyük dizinin boyutunun bir işaretçiden daha küçük olması mümkündür. Bölümlenmiş mimarileri düşünün - işaretçiler 32 bit olabilir, ancak tek bir bölüm yalnızca 64KB'ye (örneğin eski gerçek mod 8086 mimarisi) hitap edebilir.

Bunlar artık masaüstü makinelerde yaygın olarak kullanılmasa da, C standardı küçük, özel mimarileri bile desteklemeyi amaçlamaktadır. Örneğin 8 veya 16 bit CPU'larla geliştirilmekte olan gömülü sistemler var.

Daha iyi kod niyetlerini iletir hayal ediyorum (ve bu tüm tip isimleri için geçerli).

Örneğin, olsa bile unsigned shortve wchar_tkullanarak Windows (Bence) aynı boyutta wchar_tyerine unsigned shortgösteriler Bunun yerine sadece bazı keyfi sayısından daha geniş bir karakter saklamak için kullanacağı niyeti.

Hem geriye hem de ileriye bakarak ve çeşitli oddball mimarilerinin manzaraya dağıldığını hatırlatarak, mevcut tüm sistemleri sarmaya ve gelecekteki tüm sistemleri sağlamaya çalıştıklarından eminim.

Öyleyse, işlerin ortaya çıkış şekli, şu ana kadar pek fazla türe ihtiyacımız olmadı.

Ancak, oldukça yaygın bir paradigma olan LP64'te bile, sistem çağrısı arabirimi için size_t ve ssize_t'e ihtiyacımız vardı. Tam 64-bit tip kullanmanın pahalı olduğu ve 4GB'den büyük ancak hala 64-bit işaretçileri olan I / O op'larında punt yapmak isteyebilecekleri daha kısıtlı bir miras veya gelecek sistemi düşünülebilir.

Bence merak etmelisiniz: neyin geliştirilebileceğini, gelecekte nelerin gelebileceğini. (Belki 128 bit dağıtılmış sistem internet çapında işaretçiler, ancak bir sistem çağrısında 64 bit veya belki de bir "eski" 32 bit sınırı. :-) Eski sistemlerin yeni C derleyicileri alabileceği görüntü. .

Ayrıca, etrafta neler olduğuna bakın. Milyonlarca 286 gerçek mod bellek modelinin yanı sıra, CDC 60 bit kelime / 18 bit işaretçi ana karelerine ne dersiniz? Cray serisine ne dersin? Normal ILP64, LP64, LLP64'ü boş verin. (Microsoft'un her zaman LLP64 ile iddialı olduğunu düşündüm, P64 olmalıydı.) Kesinlikle tüm üsleri örtmeye çalışan bir komite hayal edebiliyorum ...

int main(){
  int a[4]={0,1,5,3};
  int a0 = a[0];
  int a1 = *(a+1);
  int a2 = *(2+a);
  int a3 = 3[a];
  return a2;
}

İntptr_t ifadesinin her zaman size_t yerine koyması gerektiğini ve bunun tersini yapmak anlamına gelir.