Ardından gelen _t (alt çizgi-t) türü neyi temsil eder?


261

Bu basit bir soru gibi görünüyor, ancak Stack Overflow araması veya Google ile bulamıyorum. Bir tipin ardından _tortalama ne demektir? Gibi

int_t anInt;

C kodunda donanım ile yakından ilgilenmek için çok şey görüyorum - yardım edemiyorum ama ilgili olduklarını düşünmüyorum.


3
Nerede int_ttanımlı? Her zaman olarak tanımlanırsa int, yararlı değildir; intdoğrudan kullanmak çok daha net . Her zaman olarak tanımlanan değilse int(olması gerektiği takdirde, demek long intya short int), o zaman kötü seçilmiş ve kafa karıştırıcı bir isim.
Keith Thompson

Yanıtlar:


213

Douglas Mayle'nin belirttiği gibi, temel olarak bir tür adını belirtir. Sonuç olarak, _tbazı karışıklıklara neden olabileceğinden değişken veya işlev adlarını ' ' ile sonlandırmanız tavsiye edilmez . Sıra gibi size_t, C89 standart tanımlayıp wchar_t, off_t, ptrdiff_tve muhtemelen bazıları diğerlerinden ben unuttum. C99 standart gibi ekstra tipleri, bir sürü tanımlar uintptr_t, intmax_t, int8_t, uint_least16_t, uint_fast32_t, vb. Bu yeni türler resmi olarak tanımlanmıştır, <stdint.h>ancak çoğu zaman <inttypes.h>(olağandışı bir şekilde standart C başlıkları için) içerir <stdint.h>. ( <inttypes.h>) Ayrıca printf()ve ile kullanılacak makroları tanımlar scanf().

Matt Curtis'in belirttiği gibi, soneki derleyicinin önemi yoktur; insan odaklı bir sözleşmedir.

Bununla birlikte, POSIX'in ' _t' ile biten çok sayıda ekstra tür adı tanımladığını ve uygulama için son eki sakladığını da unutmamalısınız . Bu, POSIX ile ilgili sistemler üzerinde çalışıyorsanız, kendi tür adlarınızı kuralla tanımlamanızın tavsiye edilmediği anlamına gelir. Üzerinde çalıştığım sistem bunu yaptı (20 yıldan fazla); tanımladığımızla aynı ada sahip türleri tanımlayan sistemler tarafından düzenli olarak devreye giriyoruz.


4
işletim sistemi ve ortak çalışma zamanı kitaplıklarının genel adlara sahip türleri tanımlamaları mantıklıdır; ancak şirketinizin türlerine bir önek veya başka bir şey eklenmemeli mi?
Oyuncak Yapımcısı

17
Bunu önlemek için typedefs üzerinde _t yerine _type kullanın.
CesarB

4
@Jonathan Leffler - Kullanıcı tanımlı türler için hangi adlandırma kuralını kullanırsınız?
J. Andrew Laughlin

15
@Andrew: önek olarak kullanmak için uygun bir kısaltmanız varsa, abbr_xxxxx_ttür adlarını kullanmak güvenli olabilir . Böyle bir önek olmadan, istediğiniz zaman yakalanabilirsiniz. Genel olarak, standartlaştırılmış _ttürlerin tümü küçük harf kullanır ( FILEve DIRiki istisna, iki kez - tüm kapaklar ve hayır _t), bu nedenle CamelCase_tön kapaklı veya başsız orta güvenlikle kullanabilirsiniz . Esas olarak üzerinde çalıştığım sistem tehlikeli bir şekilde yaşama ve _tyine de kullanma eğilimindedir , ancak bazen bizi ısırdı. CamelCaseKendi çalışmalarım için sonek kullanmama eğilimindeyim ; işlevleriim genellikle küçük harflidir.
Jonathan Leffler

5
@JonathanLeffler, bu kuralı kullanmaya başladım, CamelCase türleri için, alt_ işlevler için. Sadece ben olmadığımı umarak bu soruyu araştırdım. Doğrulama için teşekkürler!
Austin Mullins

50

Veri türlerini adlandırmak için kullanılan bir kuraldır, örneğin typedef:


typedef struct {
  char* model;
  int year;
...
} car_t;


43

_tGenellikle, opak bir tip tanımı sarar.

GCC _t, gelecekteki Standart C ve POSIX sürümleriyle (GNU C kitaplık kılavuzu) çakışmalardan kaçınmak için kullanamayacağınız ayrılmış ad alanı ile biten adları ekler . Bazı araştırmalardan sonra, nihayet POSIX Standardı (1003.1, Gerekçe (Bilgilendirici)) içinde doğru referansı buldum:

B.2.12 Veri Türleri

Bu bölümde tanımlanan ek türlerin '' _t '' ile bitmesi şartı, ad alanı kirliliği sorunu tarafından istenmiştir. Bir başlık dosyasında bir tür tanımlamak (bu türün IEEE Std 1003.1-2001 tarafından tanımlanmadığı bir yer) tanımlamak ve programın ad alanına sembol eklemeden başka bir türde kullanmak zordur. Uygulayıcıların kendi türlerini sağlamasına izin vermek için, tüm uygun uygulamaların, '' _t '' ile biten ve uygulayıcının ek türler sağlamasına izin veren sembollerden kaçınması gerekir. Tiplerin büyük bir kullanımı, IEEE Std 1003.1-2001'de tanımlanan yapılara eklenebilen (ve çoğu durumda olması gereken) yapı elemanlarının tanımında olduğundan, ilave tiplere duyulan ihtiyaç zorlayıcıdır.

Özetle, Standart, Standart türler listesini genişletme şansının yüksek olduğunu söylüyor, bu nedenle Standart, _tad alanını kendi kullanımı için kısıtlıyor .

Örneğin, programınız POSIX 1003.1 Sorunları 6 ile eşleşiyor ve bir tür tanımladınız foo_t. POSIX 1003.1 Sorunlar 7 sonunda yeni tanımlanmış bir türle yayımlanır foo_t. Programınız yeni sürümle eşleşmiyor, bu sorun olabilir. _tKullanımın kısıtlanması, kodun yeniden düzenlenmesini önler. Bu nedenle, bir POSIX uyumluluğunu hedeflerseniz _t, Standard'ın belirttiği gibi kesinlikle kaçınmalısınız .

Yan not: kişisel olarak, POSIX'e bağlı kalmaya çalışıyorum çünkü temiz programlama için iyi temeller verdiğini düşünüyorum. Ayrıca, Linux Kodlama Stili (bölüm 5) yönergelerine oldukça düşkünüm . Typedef kullanmamanın bazı iyi nedenleri vardır. Umarım bu yardım!


18

Genellikle typedefs tarafından tanımlanan veri türleri için standart bir adlandırma kuralıdır. Donanım kayıtlarıyla ilgilenen birçok C kodu, imzalı ve imzasız sabit boyutlu veri türleri için C99 tanımlı standart adları kullanır. Kural olarak, bu adlar standart bir başlık dosyasında (stdint.h) bulunur ve _t ile biter.


11

Bu sadece "tip" anlamına gelen bir kongre. Derleyiciye özel bir şey ifade etmez.


11

_tDoğal olarak herhangi bir özel anlama sahip değildir. Ancak _ttypedef'in son ekini eklemek ortak kullanıma düştü .

Değişken adlandırma için ortak C uygulamalarına daha aşina olabilirsiniz ... Bu, bir işaretçi için ön tarafa ap yapıştırmanın ve global değişkenlerin önünde bir alt çizgi kullanmanın yaygınlığına benzer (bu biraz daha az yaygındır) ve değişken adlarını kullanmak için i, jve kgeçici döngü değişkenleri için.

Kelime boyutu ve sıralamanın önemli olduğu kodda, BYTE WORD(normalde 16 bit) DWORD(32 bit) gibi açık olan özel tanımlı türlerin kullanılması çok yaygındır .

int_to kadar iyi değil, çünkü tanımı intplatformlar arasında değişiyor - o intzaman kime uyuyorsunuz? (Bu günlerde, çoğu PC merkezli geliştirme 32 bit gibi görünse de, PC dışı geliştirme için pek çok şey hala 16 bit olarak kabul edilmektedir).



8

Konu hakkında birkaç iyi açıklama vardı. Sadece türleri yeniden tanımlamak için başka bir neden eklemek için:

Birçok gömülü projede, tüm boyutlar, verilen boyutlandırmayı türlere göre doğru şekilde belirtmek ve farklı platformlarda (yani donanım türleri derleyicileri) taşınabilirliği geliştirmek için yeniden tanımlanır.

Başka bir neden, kodunuzu farklı işletim sistemlerinde taşınabilir hale getirmek ve işletim sisteminizde kodunuza entegre ettiğiniz mevcut türlerle çarpışmaları önlemek olacaktır. Bunun için genellikle benzersiz (mümkün olduğunca) bir önek eklenir.

Misal:

typedef unsigned long dc_uint32_t;

7

Donanım arabirim kodu ile uğraşıyorsanız, baktığınız kodun yazarı int_tbelirli bir boyut tamsayısı olarak tanımlamış olabilir . C standardı, inttüre belirli bir boyut atamaz (potansiyel olarak derleyicinize ve hedef platformunuza bağlıdır) ve belirli bir int_ttür kullanıldığında bu taşınabilirlik sorunu önlenir.

Bu, donanım arabirim kodu için özellikle önemli bir husustur, bu yüzden orada sözleşmeyi ilk olarak fark etmiş olabilirsiniz.


1
Bu çok iyi bir uygulama olmayacak, tanımladığınız boyutun ne olduğunu netleştirmek için bir tanesinin [u] int_ [32 16 8] _t tanımlamasını beklerim.
Ilya

1
Oldukça haklısın, "int_t" kendi başına programcıya kullanıcı tanımlı bir tip olduğunu söyler ama gerçekte ne olduğunu söyler!
Greg Hewgill

0

Örneğin, C99'da /usr/include/stdint.h:

typedef unsigned char           uint8_t;
typedef unsigned short int      uint16_t;
#ifndef __uint32_t_defined
typedef unsigned int            uint32_t;
# define __uint32_t_defined
#endif
#if __WORDSIZE == 64
typedef unsigned long int       uint64_t;
#else
__extension__
typedef unsigned long long int  uint64_t;
#endif

_t her zaman typedef ile tanımlanır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.