Re: [問題] 請問C介面跟實作分開的作法

作者: alan23273850   2018-04-28 11:58:32
想問問如果只寫了一堆c檔,然後其他c檔就只 include 我這個C檔,
加上ifdef這種防止雙重宣告的prototype,不就也可以很順利的編譯程式了嗎?
那這樣根本就不需要header file阿,為什麼還是需要哩?有解否?
作者: Keiichi (Keiichi)   2018-04-28 12:08:00
ifdef分別在兩個檔案通過編譯->得到兩份實體->link爆炸
作者: ckc1ark (偽物)   2018-04-28 12:27:00
compile time也有差
作者: Bencrie   2018-04-28 12:49:00
圖靈打球 你當球你要這樣玩乾脆就不要 ifdef,全部 static 當 inline
作者: alan23273850   2018-04-28 13:44:00
寫錯,是ifndef,這樣應該還是只有一份實作吧
作者: Bencrie   2018-04-28 14:04:00
大家都知道你的 ifdef 是指 include guard ...
作者: alan23273850   2018-04-28 14:28:00
所以一樓大大應該就講錯了?重點是我曾經用這種方式成功過才發問的喔
作者: DIE755127   2018-04-28 14:57:00
我覺得差異在include c等於是把一堆實作濃縮在一個translation unit include h就是透過linker連結其他的translation unit windows ide會處理比較感覺不出來 linuxmake file寫法應該會有差 另外有header對可讀跟維護性會比較好其實原文發問是想了解c語言是有什麼特別技巧一定要寫成文內提的情況 怕沒想好就誤會別人
作者: Bencrie   2018-04-28 16:47:00
一樓沒講錯另外同樣的 prototype 宣告兩次是 ok 的你會 build 成功是因為你實際上只編譯一個檔案吧
作者: Schottky (順風相送)   2018-04-28 21:37:00
一樓沒講錯。光是compile過跑一兩次沒問題不代表這種做法就永遠是對的。你這自信到底是哪來的
作者: CaptainH (Cannon)   2018-04-29 00:28:00
因為你改了任一檔案 就要全部重新編譯其他不說 光是重編stdlib就要很久了
作者: future314 (未來π)   2018-04-29 00:38:00
因為很多時候對實作不感興趣 與其放很多程式碼 不如給我一個簡單的介面讓我知道怎麼使用就好因此 介面與實作分開減少使用者上手的時間 也增加設計師維護的容易度 這個你寫大一點的C程式才有感覺一些OOP可以這樣搞是因為他有其他方法去包裝可以去聽一下jserv大的講座C的物件導向
作者: cphe (魔鬼藏在垃圾筒裡)   2018-04-29 12:09:00
沒幾個檔的project這樣沒差,如果是幾萬隻檔這樣搞光compile time你就會瘋掉
作者: KanzakiHAria (神崎・H・アリア)   2018-04-29 19:43:00
一樓才是正確的 我前一篇已經說了靜態連結在編譯時期發現重複定義而無法編過動態連結是執行時載入連結時炸掉你根本就沒有做連結的行為當然不會掛
作者: firose (guest也是也是也是也是也)   2018-04-29 20:13:00
如果每個 translation unit 都 include .c 就會造成 obj有重複的內容,整個浪費磁碟空間,至於連結會怎樣要測試但很明顯的如果某個模組用到某個符號卻沒 include .c那它就會產生無法決定要用哪個 obj 中的那份定義的問題反正最好的方式當然是一份 .c 轉 .obj 別人用 .h 引用它
作者: KanzakiHAria (神崎・H・アリア)   2018-04-30 14:48:00
眾人不要誤導 跟compile time一點關係都沒有就是最基本的語法錯誤 連結時會重複定義
作者: Bencrie   2018-04-30 15:10:00
連結時期會有語法錯誤????
作者: sorryla (Mr.東)   2018-04-30 19:50:00
linking才出錯就不叫語法錯誤了吧...
作者: KanzakiHAria (神崎・H・アリア)   2018-04-30 20:59:00
undefined reference to某某某class或function算不算語法錯誤? 如果不算 那我承認不算語法錯誤
作者: AstralBrain   2018-04-30 21:32:00
不算 (完
作者: Bencrie   2018-05-01 02:04:00
你下 gcc -c 看會不會噴 undefined reference
作者: jerryh001   2018-05-01 11:32:00
不是叫鏈結錯誤嗎
作者: sorryla (Mr.東)   2018-05-01 20:24:00
你承不承認無所謂,普遍認知這種情況就是linking error
作者: KanzakiHAria (神崎・H・アリア)   2018-05-01 20:59:00
總之無關編譯時間長短 也無關佔用空間 就是會error
作者: CoNsTaR ((const *))   2018-05-03 06:51:00
某 K 笑死,和編譯時間無關?連語法錯誤都出來了 XDDDD
作者: KanzakiHAria (神崎・H・アリア)   2018-05-03 09:02:00
false imply true 一個一定會error的東西不管說有沒有關影響編譯時間長短和佔用空間都對這兩篇從頭到尾都是在問什麼情況不行 結果一堆人都在回覆編譯時間和佔用空間還有人回可以這樣做唷^.<誰在搞笑?
作者: CoNsTaR ((const *))   2018-05-03 23:40:00
首先,compile errer 代表 source 不能被 compile 成 binary,不代表這份 source 是邏輯上的 false第二,不一定會 compile error第三,兩篇都是問為什麼要這麼做最後,你在別人的分享下面討論其他篇文章,不知道是誰在搞笑?
作者: KanzakiHAria (神崎・H・アリア)   2018-05-04 06:57:00
就說是連結時期一定會炸 沒有炸就是因為沒連結還在compile....跟compile time一點關係都沒有 不知道要說幾次大家才會知道linker的存在linker根本邊緣人 幫qq
作者: CoNsTaR ((const *))   2018-05-04 07:01:00
隨便都有一堆不會炸的例子,請說明如何一定會炸?沒炸的話手動把他炸了嗎 XDDDD
作者: KanzakiHAria (神崎・H・アリア)   2018-05-04 07:01:00
"有甚麼情況下是必須要這樣做?" 這行看不到?
作者: CoNsTaR ((const *))   2018-05-04 07:03:00
所以是再問為什麼要這麼做啊 有問題嗎
作者: KanzakiHAria (神崎・H・アリア)   2018-05-04 07:05:00
所以答案就是1F的linking時期error
作者: CoNsTaR ((const *))   2018-05-04 07:06:00
又要開始講和 compile time 沒關係了嗎
作者: KanzakiHAria (神崎・H・アリア)   2018-05-04 07:06:00
單一檔案語法正確可以編譯 當然沒有編譯時期error然後因為這樣正確就跑來說編譯沒錯廢話當然編譯沒錯啊 根本就跟編譯無關
作者: adrianshum (Alien)   2018-05-04 08:16:00
平心而論K君除了有一點(無傷大雅)的錯誤用詞,他說的是正確的。整件事的癥結根本就在linking。
作者: hakman (^____^)   2018-05-04 12:57:00
K 君大致上來講是沒錯啊,但是其他人講的是為什麼一開始要這樣設計,但是K君一直想把問題簡化。大概就是懶人包跟來龍去脈的差別吧...
作者: Bencrie   2018-05-04 14:41:00
都是原 po 不好 XD

Links booklink

Contact Us: admin [ a t ] ucptt.com