• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            C小加

            厚德 博學(xué) 求真 至善 The bright moon and breeze
            posts - 145, comments - 195, trackbacks - 0, articles - 0
              C++博客 :: 首頁(yè) :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理
            轉(zhuǎn)自:http://blog.csdn.net/slimfox/article/details/1565950
             

            為了避免同一個(gè)文件被include多次,C/C++中有兩種方式,一種是#ifndef方式,一種是#pragma once方式。在能夠支持這兩種方式的編譯器上,二者并沒(méi)有太大的區(qū)別,但是兩者仍然還是有一些細(xì)微的區(qū)別。

                方式一:
                #ifndef __SOMEFILE_H__
                #define __SOMEFILE_H__
                ... ... // 一些聲明語(yǔ)句
                #endif

                方式二:
                #pragma once
                ... ... // 一些聲明語(yǔ)句

                #ifndef的方式依賴于宏名字不能沖突,這不光可以保證同一個(gè)文件不會(huì)被包含多次,也能保證內(nèi)容完全相同的兩個(gè)文件不會(huì)被不小心同時(shí)包含。當(dāng)然,缺點(diǎn)就是如果不同頭文件的宏名不小心“撞車”,可能就會(huì)導(dǎo)致頭文件明明存在,編譯器卻硬說(shuō)找不到聲明的狀況——這種情況有時(shí)非常讓人抓狂。
                #pragma once則由編譯器提供保證:同一個(gè)文件不會(huì)被包含多次。注意這里所說(shuō)的“同一個(gè)文件”是指物理上的一個(gè)文件,而不是指內(nèi)容相同的兩個(gè)文件。帶來(lái)的好處是,你不必再費(fèi)勁想個(gè)宏名了,當(dāng)然也就不會(huì)出現(xiàn)宏名碰撞引發(fā)的奇怪問(wèn)題。對(duì)應(yīng)的缺點(diǎn)就是如果某個(gè)頭文件有多份拷貝,本方法不能保證他們不被重復(fù)包含。當(dāng)然,相比宏名碰撞引發(fā)的“找不到聲明”的問(wèn)題,重復(fù)包含更容易被發(fā)現(xiàn)并修正。
                #pragma once方式產(chǎn)生于#ifndef之后,因此很多人可能甚至沒(méi)有聽(tīng)說(shuō)過(guò)。目前看來(lái)#ifndef更受到推崇。因?yàn)?ifndef受語(yǔ)言天生的支持,不受編譯器的任何限制;而#pragma once方式卻不受一些較老版本的編譯器支持,換言之,它的兼容性不夠好。也許,再過(guò)幾年等舊的編譯器死絕了,這就不是什么問(wèn)題了。
                我還看到一種用法是把兩者放在一起的:
                #pragma once
                #ifndef __SOMEFILE_H__
                #define __SOMEFILE_H__
                ... ... // 一些聲明語(yǔ)句
                #endif

                看起來(lái)似乎是想兼有兩者的優(yōu)點(diǎn)。不過(guò)只要使用了#ifndef就會(huì)有宏名沖突的危險(xiǎn),所以混用兩種方法似乎不能帶來(lái)更多的好處,倒是會(huì)讓一些不熟悉的人感到困惑。
                選擇哪種方式,應(yīng)該在了解兩種方式的情況下,視具體情況而定。事實(shí)上,只要有一個(gè)合理的約定來(lái)避開(kāi)缺點(diǎn),我認(rèn)為哪種方式都是可以接受的。而這個(gè)已經(jīng)不是標(biāo)準(zhǔn)或者編譯器的責(zé)任了,應(yīng)當(dāng)由程序員來(lái)搞定。
                btw:我看到GNU的一些討論似乎是打算在GCC 3.4(及其以后?)的版本取消對(duì)#pragma once的支持。不過(guò)我手上GCC 3.4.2和GCC 4.1.1仍然支持#pragma once,甚至沒(méi)有deprecation warning。VC6及其以后版本亦提供對(duì)#pragma once方式的支持。看來(lái)這一特性已經(jīng)穩(wěn)定下來(lái)了。 

            Feedback

            # re: #pragma once 與 #ifndef 解析(轉(zhuǎn))  回復(fù)  更多評(píng)論   

            2013-03-18 11:30 by augustheart
            gcc已經(jīng)會(huì)報(bào)告pragma once的警告了。說(shuō)什么記不清了,因?yàn)樽詮目吹剿鼒?bào)后就改用單純的ifndef方式了,如今都過(guò)去一年多了。最開(kāi)始我也是pragma和ifndef一起用,但是已經(jīng)記不清為什么一起用了……
            這轉(zhuǎn)的文章已經(jīng)很老了,現(xiàn)在gcc都4.72了。

            # re: #pragma once 與 #ifndef 解析(轉(zhuǎn))  回復(fù)  更多評(píng)論   

            2013-03-20 18:03 by P
            我想知道取消對(duì)#pragma once支持原因
            久久人人爽人人人人片av| 亚洲国产精品久久电影欧美| 久久99国产精一区二区三区| 亚洲精品无码久久久影院相关影片| 亚洲?V乱码久久精品蜜桃| 狠狠色丁香久久综合婷婷| 久久夜色精品国产网站| 久久久亚洲欧洲日产国码二区| 亚洲国产另类久久久精品| 91精品国产9l久久久久| 日本精品久久久中文字幕 | 久久乐国产综合亚洲精品| 久久精品国产欧美日韩| 久久久久久青草大香综合精品| 久久这里的只有是精品23| 国内精品九九久久精品| 久久不见久久见免费视频7| 久久综合久久综合久久综合| 久久AⅤ人妻少妇嫩草影院| 久久影视综合亚洲| 久久综合噜噜激激的五月天| 99久久免费国产精精品| 精品久久久久国产免费| 一级女性全黄久久生活片免费| 一本一本久久aa综合精品| 亚洲日韩中文无码久久| 国产成人精品三上悠亚久久| 青青草原1769久久免费播放| 国产精品久久久天天影视香蕉| 午夜福利91久久福利| 麻豆AV一区二区三区久久| 日本精品久久久久中文字幕| 日韩人妻无码一区二区三区久久99| 国产成人精品三上悠亚久久| 一本大道加勒比久久综合| 国产精品久久久久久五月尺| 久久99精品国产麻豆宅宅| 久久国产亚洲精品| 国产福利电影一区二区三区,免费久久久久久久精 | 亚洲狠狠婷婷综合久久蜜芽 | 久久九九久精品国产免费直播|