2016-03-08 11 views
16

considerareprefissi in nomi dei membri di una struct

struct iovec { 
    ptr_t iov_base; /* Starting address */ 
    size_t iov_len; /* Length in bytes */ 
}; 

o

struct stat { 
dev_t  st_dev;  /* ID of device containing file */ 
ino_t  st_ino;  /* inode number */ 
mode_t st_mode; /* protection */ 
nlink_t st_nlink; /* number of hard links */ 
uid_t  st_uid;  /* user ID of owner */ 
gid_t  st_gid;  /* group ID of owner */ 
dev_t  st_rdev; /* device ID (if special file) */ 
off_t  st_size; /* total size, in bytes */ 
blksize_t st_blksize; /* blocksize for file system I/O */ 
blkcnt_t st_blocks; /* number of 512B blocks allocated */ 
time_t st_atime; /* time of last access */ 
time_t st_mtime; /* time of last modification */ 
time_t st_ctime; /* time of last status change */ 
}; 

Qual è il punto di prefisso quei nomi dei membri (iov_, st_)?

risposta

28

Una volta molto tempo fa (molto prima che iniziassi a programmare in C, che è più di 30 anni fa), i nomi dei membri degli elementi della struttura dovevano essere univoci in tutte le strutture di un programma, invece di struttura di tag' come il requisito è ora, ed è stato sin dai tempi di K & R - The C Programming Language 1st Edition, da Kernighan & Ritchie, 1978.

di conseguenza, in quei giorni, il prefisso aiutato segregare i membri del un tipo di struttura da ogni altro tipo di struttura. Di conseguenza, l'abitudine è cresciuta usando tali prefissi e continua con tipi di struttura più recenti. Il struct stat risale ai giorni del vecchio sistema; struct iovec è un'invenzione più recente (forse negli anni '80) che ha seguito la vecchia tradizione.

L'utilizzo di prefissi non fa male. Potrebbe essere marginalmente utile. Se vedi gadzooks.st_mtime, non è necessario cercare la definizione di gadzooks per indovinare con la certezza che è di tipo struct stat.

Per inciso, è possibile trovare una prima versione di 'The Manual C di riferimento' come parte dei manuali di Unix 7 ° edizione (Unix Programmer's Manual Volume 2A) che dice (§8.5 sul P244, enfasi aggiunta):

I nomi dei membri della struttura e dei tag di struttura possono essere uguali alle variabili ordinarie, poiché una distinzione può essere effettuata dal contesto con . Tuttavia, i nomi dei tag e dei membri devono essere distinti. Lo stesso nome membro può apparire in strutture diverse solo se i due membri sono dello stesso tipo e se la loro origine rispetto alla loro struttura è uguale; quindi le strutture separate possono condividere un segmento iniziale comune.

Gli stessi documenti manuali lungo obsoleto =+ famiglia di operatori di assegnazione (in contrasto con il moderno, il che significa da circa 1976 += famiglia di operatori di assegnazione).

+4

Tuttavia, non dovrebbe essere usato nel codice moderno. Tali prefissi rendono i tipi di cambiamento o il refactoring molto più difficili e non servono a nulla. Invece di codificare il tipo in un nome di variabile, si dovrebbe usare un nome che descrive a cosa serve l'oggetto, resp. cosa contende semanticamente. – Olaf

+1

@Olaf Non vedo come si possa dire che "non servono a nulla". Nella risposta è già stato dato un uso: vedere il tipo di una struttura dai nomi dei suoi membri. Un altro uso è che sono facilmente 'grep'pable e' man -K'-able. –

+0

@MilesRout: usa gli strumenti appropriati e quei piccoli professionisti svaniscono. Ma gli svantaggi rimangono. Con la tua argomentazione, non dovremmo usare gli spazi dei nomi e gli ambiti. Perché pensi che li abbiamo da decenni? Se hai bisogno di codificare il tipo, fallo nel nome della variabile (notazione ungherese, anche cattiva pratica, vedi Wikipedia), non i membri; presto diventano ambigui in un progetto più ampio. – Olaf

Problemi correlati