C/C++中指針類型聲明: `*`的位置

引入

我們用兩個簡單(?)的問題作為引入,當(dāng)然我們整篇文章都會圍繞這兩個問題:

  1. 下面四種類型聲明等價嗎?
    • int* i;
    • int *i;
    • int * i;
    • int*i;
  2. 下面四種類型聲明中够掠,j擁有哪一個數(shù)據(jù)類型过咬?是int或者int的指針?
    • int* i, j;
    • int *i, j;
    • int * i, j;
    • int*i, j;

當(dāng)然看到這里壳猜,如果你已經(jīng)有非常自信的答案虹曙,你當(dāng)然可以無視這一篇文章后面的部分。

第一個問題

第一個問題的答案是: 四種指針的類型聲明的等價的绒障。

很好吨凑,既然我們知道它們等價,或許已經(jīng)足夠了户辱。但是我們數(shù)據(jù)庫教授總是在課上提醒大家鸵钝,知道區(qū)別并不足夠,還需要問自己其中的哪一個更好庐镐,什么情況下用哪一種方式恩商。

哪一種寫法更好呢?

C++之父在他的一篇文章:Bjarne Stroustrup's C++ Style and Technique FAQ中提到:

  • The choice between int* p; and int *p; is not about right and wrong, but about style and emphasis. C emphasized expressions; declarations were often considered little more than a necessary evil. C++, on the other hand, has a heavy emphasis on types.

  • A typical C programmer writes int *p; and explains it *p is what is the int emphasizing syntax, and may point to the C (and C++) declaration grammar to argue for the correctness of the style. Indeed, the * binds to the name p in the grammar.

  • A typical C++ programmer writes int* p; and explains it p is a pointer to an int emphasizing type. Indeed the type of p is int*. I clearly prefer that emphasis and see it as important for using the more advanced parts of C++ well.

</br>

Linux kernel coding style中的習(xí)慣規(guī)則是:

When declaring pointer data or a function that returns a pointer type, the
preferred use of * is adjacent to the data name or function name and not
adjacent to the type name. Examples:

char *linux_banner;
unsigned long long memparse(char *ptr, char **retptr);
char *match_strdup(substring_t *s);

某種程度上它也擬合了C++之父Bjarne Stroustrup的想法必逆。

第二個問題

第二個問題的答案是: j的類型是int怠堪。

當(dāng)然這問題是編譯器的行為,或者語言自身的規(guī)定名眉,很難去闡述行為或規(guī)定背后的為什么粟矿。

我們繼續(xù)看Bjarne Stroustrup's C++ Style and Technique FAQ,這部分緊接問題一中對應(yīng)的引用:

The critical confusion comes (only) when people try to declare several pointers with a single declaration:
int* p, p1; // probable error: p1 is not an int*
Placing the * closer to the name does not make this kind of error significantly less likely.
int *p, p1; // probable error?
Declaring one name per declaration minimizes the problem - in particular when we initialize the variables. People are far less likely to write:
int* p = &i;
int p1 = p; // error: int initialized by int*
And if they do, the compiler will complain.

從他的這一部分文字中损拢,很容易可以看出我們這文章中的第一個問題第二個問題完全是緊密結(jié)合陌粹。第二個問題中的四種寫法的確是等價的,但是無一能讓人輕松理解福压。從他的這一個觀點(diǎn)中:Declaring one name per declaration minimizes the problem掏秩,我們可以對這篇文章下一個主觀的結(jié)論。

結(jié)論

針對第二個問題荆姆,對我來說最好的方式是:

int* i;
int j;

這種寫法更清晰蒙幻,也是多個Stackoverflow提問中所提倡的。

最后一點(diǎn)聲明是胞枕,無論怎么寫對編譯器來說其實(shí)都無所謂,它只是客觀地去檢查能否通過編譯然后生成對應(yīng)的代碼魏宽。這些等價寫法對應(yīng)的匯編語言甚至一樣腐泻,對應(yīng)的程序的效能自然也是一樣决乎。這些寫法迷惑的只是人類(編程的人和瀏覽代碼的人),我們需要有一個清晰的方式派桩,保證自己不出錯同時也讓代碼瀏覽者能快速理解构诚。

</br>
</br>

引用和推薦閱讀:

http://www.stroustrup.com/bs_faq2.html#whitespace

https://www.kernel.org/doc/Documentation/process/coding-style.rst

https://softwareengineering.stackexchange.com/questions/7305/int-i-or-int-i-or-int-i

https://stackoverflow.com/questions/6990726/correct-way-of-declaring-pointer-variables-in-c-c

https://stackoverflow.com/questions/13894228/where-to-put-the-star-in-c-and-c-pointer-notation

https://stackoverflow.com/questions/2704167/type-declaration-pointer-asterisk-position

https://stackoverflow.com/questions/398395/why-is-the-asterisk-before-the-variable-name-rather-than-after-the-type

https://stackoverflow.com/questions/180401/placement-of-the-asterisk-in-pointer-declarations

(Stackoverflow統(tǒng)統(tǒng)是在問同一件問題)

該文章遵循創(chuàng)作共用版權(quán)協(xié)議 CC BY-NC 4.0,要求署名铆惑、非商業(yè) 范嘱、保持一致。在滿足創(chuàng)作共用版權(quán)協(xié)議 CC BY-NC 4.0 的基礎(chǔ)上可以轉(zhuǎn)載员魏,但請以超鏈接形式注明出處丑蛤。文章僅代表作者的知識和看法,如有不同觀點(diǎn)撕阎,可以回復(fù)并討論受裹。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市虏束,隨后出現(xiàn)的幾起案子棉饶,更是在濱河造成了極大的恐慌,老刑警劉巖镇匀,帶你破解...
    沈念sama閱讀 216,744評論 6 502
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件照藻,死亡現(xiàn)場離奇詭異,居然都是意外死亡汗侵,警方通過查閱死者的電腦和手機(jī)幸缕,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,505評論 3 392
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來晃择,“玉大人冀值,你說我怎么就攤上這事」溃” “怎么了列疗?”我有些...
    開封第一講書人閱讀 163,105評論 0 353
  • 文/不壞的土叔 我叫張陵,是天一觀的道長浪蹂。 經(jīng)常有香客問我抵栈,道長,這世上最難降的妖魔是什么坤次? 我笑而不...
    開封第一講書人閱讀 58,242評論 1 292
  • 正文 為了忘掉前任古劲,我火速辦了婚禮,結(jié)果婚禮上缰猴,老公的妹妹穿的比我還像新娘产艾。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 67,269評論 6 389
  • 文/花漫 我一把揭開白布闷堡。 她就那樣靜靜地躺著隘膘,像睡著了一般。 火紅的嫁衣襯著肌膚如雪杠览。 梳的紋絲不亂的頭發(fā)上弯菊,一...
    開封第一講書人閱讀 51,215評論 1 299
  • 那天,我揣著相機(jī)與錄音踱阿,去河邊找鬼管钳。 笑死,一個胖子當(dāng)著我的面吹牛软舌,可吹牛的內(nèi)容都是我干的才漆。 我是一名探鬼主播,決...
    沈念sama閱讀 40,096評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼葫隙,長吁一口氣:“原來是場噩夢啊……” “哼栽烂!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起恋脚,我...
    開封第一講書人閱讀 38,939評論 0 274
  • 序言:老撾萬榮一對情侶失蹤腺办,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后糟描,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體怀喉,經(jīng)...
    沈念sama閱讀 45,354評論 1 311
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,573評論 2 333
  • 正文 我和宋清朗相戀三年船响,在試婚紗的時候發(fā)現(xiàn)自己被綠了躬拢。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 39,745評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡见间,死狀恐怖聊闯,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情米诉,我是刑警寧澤菱蔬,帶...
    沈念sama閱讀 35,448評論 5 344
  • 正文 年R本政府宣布,位于F島的核電站史侣,受9級特大地震影響拴泌,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜惊橱,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,048評論 3 327
  • 文/蒙蒙 一蚪腐、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧税朴,春花似錦回季、人聲如沸家制。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,683評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽慰丛。三九已至,卻和暖如春瘾杭,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背哪亿。 一陣腳步聲響...
    開封第一講書人閱讀 32,838評論 1 269
  • 我被黑心中介騙來泰國打工粥烁, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人蝇棉。 一個月前我還...
    沈念sama閱讀 47,776評論 2 369
  • 正文 我出身青樓讨阻,卻偏偏與公主長得像,于是被迫代替她去往敵國和親钝吮。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,652評論 2 354

推薦閱讀更多精彩內(nèi)容

  • mean to add the formatted="false" attribute?.[ 46% 47325/...
    ProZoom閱讀 2,696評論 0 3
  • pyspark.sql模塊 模塊上下文 Spark SQL和DataFrames的重要類: pyspark.sql...
    mpro閱讀 9,451評論 0 13
  • 期許線上分享 好不容易盼來了五一假本以為可以看周五直播的生命教育課了和可以和老師線上互動了劲弦,但是卻由于最后...
    孫微sw閱讀 501評論 0 10
  • 沉寂的黃昏 肅殺的冷氣 天昏又地暗 我抬頭望向天 大片的雪花紛至沓來 酷得令人顫抖 撲面而來的那一瞬 感動到流淚 ...
    南之南落小雪閱讀 201評論 0 2
  • 【朋朋日歷】 2019年 9月23日 星期一 八月廿五 秋分 **************************...
    劉書朋閱讀 157評論 0 1