作者查詢 / GNUGCC

總覽項目：發文 | 留言 | 暱稱

作者 GNUGCC 在 PTT 全部看板的留言(推文), 共704則

限定看板：全部

看板排序：

全部C_and_CPP492Python90NY-Mets54MLB30C_Sharp12ManUtd12FAPL6nb-shopping6ASM2<< 收起看板(9)

首頁

尾頁

[問題] include <XXX.h> 與 include <XXX>差別?

[ C_and_CPP ]13 留言, 推噓總分: +3

作者: sleeeve - 發表於 2013/08/16 14:58(12年前)

10^F→GNUGCC:哈~這個問題在於其實 namespace 是可以延伸定義的,iostream08/16 21:23

11^F→GNUGCC:只是延伸定義了部分內容,iostream.h 這個檔案沒有 std 名稱08/16 21:24

12^F→GNUGCC:空間所以編譯器會告訴你找不到 std 名稱空間.08/16 21:25

[問題] 關於書中例外的抑制

[ C_and_CPP ]14 留言, 推噓總分: +3

作者: ruthertw - 發表於 2013/08/15 13:08(12年前)

7^F→GNUGCC:系統呼叫 operator new() 之後如果發生錯誤會立刻丟出異常,08/15 20:38

8^F→GNUGCC:沒有機會把結果回傳給 x,如果真的要確定配置失敗要回傳 008/15 20:39

9^F→GNUGCC:可以在一開始時將 0 指定給 x,如果配置成功就不為 0,08/15 20:41

10^F→GNUGCC:丟出異常的話那結果還是 0 做為判斷依據.08/15 20:43

11^F→GNUGCC:可以改成這樣 :08/15 20:44

12^F→GNUGCC:int *x = 0;08/15 20:44

13^F→GNUGCC:x = new int[abc];08/15 20:45

14^F→GNUGCC:一旦配置動作出現錯誤,x 的值不受影響.08/15 20:47

[問題] 如何讓計算速度發揮到極限

[ C_and_CPP ]53 留言, 推噓總分: +8

作者: Lepton - 發表於 2013/08/14 23:05(12年前)

1^F→GNUGCC:如果可以的話,以 Debug 啟動反組譯並且修改相對的組合語言08/14 23:27

2^F→GNUGCC:碼,必竟編譯器產生的組合語言碼有部份是可以做最佳化使效率08/14 23:29

3^F→GNUGCC:提升.08/14 23:29

9^F→GNUGCC:如果只處理小型資料的話可以儘量不用 vector<> 而改以內建08/14 23:39

12^F→GNUGCC:陣列方式,因為每呼叫一次 operator[] 與 operator +() CPU08/14 23:40

14^F推GNUGCC:就必需花時間計算使用與返回的堆疊空間,可以從組合語言程式08/14 23:43

15^F→GNUGCC:看出.08/14 23:44

24^F→GNUGCC:這裡的例子使用 vector<> 但沒使用到如 insert() 或是08/15 00:42

25^F→GNUGCC:push_back() 類似的演算法函式,只單純做四則運算,這裡看到08/15 00:43

26^F→GNUGCC:用了 operator+(), operator[](), operator*(),那為什麼不08/15 00:46

27^F→GNUGCC:用內建的四則運算功能呢?CPU 在呼叫這些函式都需要成本考量08/15 00:47

31^F→GNUGCC:哈~對不起這裡只會呼叫 operator[]()08/15 01:13

32^F→GNUGCC:以 azureblaze 提供的組合語言碼,可以看到呼叫建構子時 CPU08/15 01:14

33^F→GNUGCC:初使化的暫存器,然後又呼叫建構物件的函式,又是一個負擔,08/15 01:17

34^F→GNUGCC:這些都是 CPU 在呼叫這些函式所花費的成本,如果這裡用了內08/15 01:20

35^F→GNUGCC:建陣列的話完全不需要這些動作,而且執行檔會相對的較小.08/15 01:21

42^F→GNUGCC:我覺得如果真的要最佳化,為什麼不自已來做呢?08/15 08:43

43^F→GNUGCC:用了內建陣列就是最佳化的方法,而且也省下了配置記憶體花費08/15 08:46

44^F→GNUGCC:的時間.08/15 08:46

47^F→GNUGCC:如果真的要用 vector<>, 或許 vector<int> 的 operator[]()08/15 11:06

48^F→GNUGCC:比 vector<vector<int>> 的還要有效率,必竟 inline 只是請08/15 11:07

49^F→GNUGCC:求,編譯器會視情況使用.08/15 11:09

Re: [問題] C++寫檔案速度很慢要怎麼樣加速

[ C_and_CPP ]17 留言, 推噓總分: +2

作者: EdisonX - 發表於 2013/08/13 23:12(12年前)

1^F→GNUGCC:其實作者有提到已用過 RamDisk 的方式速度無明顯提升,這個08/13 23:35

2^F→GNUGCC:例子當中的 writefile() 函式只是把記憶體中的資料寫入磁碟08/13 23:36

3^F→GNUGCC:內,假如 data 指向的資料已排列好只要用 fputs() 整筆寫入08/13 23:43

4^F→GNUGCC:即可,可以另外增加一個排列記憶體中資料的函式,再呼叫08/13 23:46

5^F→GNUGCC:writefile() 函式做磁碟寫入.08/13 23:47

[問題] 想問有關C++Primer,p642..

[ C_and_CPP ]2 留言, 推噓總分: 0

作者: easterday - 發表於 2013/08/12 16:58(12年前)

1^F→GNUGCC:跟編譯器也許有關係,typename 只是告知編譯器使用的是型態08/12 21:16

2^F→GNUGCC:定義,若不加的話會讓編譯器誤以為是類別的資料成員.08/12 21:17

[問題] 請問一行typedef

[ C_and_CPP ]16 留言, 推噓總分: +4

作者: p52189 - 發表於 2013/08/12 02:21(12年前)

10^F→GNUGCC:這個敘述的意思是 compfn 的型態是08/12 21:20

11^F→GNUGCC:int (*)(const void*, const void*);08/12 21:22

[問題] 請問一個.cpp檔與.h中define的作用

[ C_and_CPP ]20 留言, 推噓總分: +4

作者: Zoxge - 發表於 2013/08/12 00:30(12年前)

7^F→GNUGCC:這個用法比較有可能是 xxx.cpp 有 void FUNCTION(void){}08/12 22:07

8^F→GNUGCC:的實體,所以 include "xxx.h" 遇到函式原型就不需加上08/12 22:09

9^F→GNUGCC:extern,編譯器能判斷屬內部連結,那其他 .cpp 檔如果08/12 22:10

10^F→GNUGCC:include "xxx.h" 而沒有 void FUNCTION(void){} 實體的話,08/12 22:10

11^F→GNUGCC:就會遇到 extern void FUNCTION(void); 的定義了,編譯器會08/12 22:12

12^F→GNUGCC:把呼叫 FUNCTION() 函式的敘述交給 Linker 來處理,而不用等08/12 22:13

13^F→GNUGCC:到全部 .cpp 檔編譯完後發現沒有 FUNCTION 實體才交給08/12 22:14

14^F→GNUGCC:Linker 處理外部連結,純粹是編譯效率的考量.08/12 22:15

[問題] dll檔遺失有人知道解決方法嗎？

[ C_and_CPP ]9 留言, 推噓總分: +2

作者: victor770409 - 發表於 2013/08/11 03:20(12年前)

7^F→GNUGCC:可以試著使用 LoadLibrary() 與 GetProcAddress() 函式.08/11 20:31

Re: [問題] 擷取到的字串轉換成變數

[ C_and_CPP ]9 留言, 推噓總分: +2

作者: GNUGCC - 發表於 2013/08/10 00:54(12年前)

4^F→GNUGCC:利用 template class map<> 的方式也是可以的,但產生出來的08/10 23:00

5^F→GNUGCC:執行檔會變大,因為它包含很多程式碼在裡面,但好處是很方便08/10 23:02

6^F→GNUGCC:提供部份可操作的演算法,但如果各位有看過 map<> 的原始碼08/10 23:04

7^F→GNUGCC:就能看出 map<> 是以紅黑樹當做它儲存資料容器,對只儲存小08/10 23:07

8^F→GNUGCC:型的資料來說等於是殺雞用牛刀.08/10 23:09

Re: [問題] 傳遞多個引數是否會自動建構成類別物件

[ C_and_CPP ]98 留言, 推噓總分: +21

作者: GNUGCC - 發表於 2013/08/10 00:03(12年前)

4^F→GNUGCC:void main(void) 的寫法是可行的唷^^08/10 00:59

6^F→GNUGCC:雖然這個寫法較傳統,但是語法與文法都正確哦^^08/10 02:16

13^F→GNUGCC:大部份範例程式都是使用 int main(void) 然後回傳一個 0 給08/10 20:14

14^F→GNUGCC:作業系統,但如果這真的是標準,那編譯器顯然會出現錯誤了.08/10 20:17

15^F→GNUGCC:目前我使用的 Visual C++ 都接受 void main(void) 與08/10 20:18

17^F→GNUGCC:int main(void),各位可以把 C++ 專案改成原生 C++ 類型來08/10 20:19

19^F→GNUGCC:用 void main(void) 來寫發現也可通過編譯.08/10 20:21

21^F→GNUGCC:呵呵~我沒用過 Apple 的,我使用的 Turbo C++ 與08/10 20:25

22^F→GNUGCC:Borland C++, Windows 的 Visual C++ 任何版本的原生 C++08/10 20:25

24^F→GNUGCC:專案都可用 void main(void) 方式,C++ .Net 專案似乎也是跟08/10 20:27

25^F→GNUGCC:著標準走.08/10 20:29

28^F→GNUGCC:其實這是完全看個人編碼風格,但如果編譯器不接受 void 的08/10 20:46

29^F→GNUGCC:方式那就需改用 int 了,g++ 的標準是對的,因為它符合文件規08/10 20:48

30^F→GNUGCC:範,Visual C++ 的方式也不能說是錯的,只是它保留了傳統與彈08/10 20:49

31^F→GNUGCC:性,至於怎麼使用就看個人怎麼選擇了^^08/10 20:50

33^F→GNUGCC:語法是對的,但是否符合規範完全取決於編譯器了.08/10 20:55

36^F→GNUGCC:void main(void) 與 int main(void) 都是屬於 C 與 C++ 的08/10 22:36

37^F→GNUGCC:主程式,這個在 16 bit 時代是可用的,就好像是 Windows API08/10 22:39

38^F→GNUGCC:有支援 16 bit 與 32 bit,那為什麼 Windows 還持續保留了08/10 22:41

39^F→GNUGCC:16 bit 的版本,要使用那一個版本見人見智了^^08/10 22:44

40^F→GNUGCC:更簡單的說是「不符合規範不代表不可以用」.08/10 22:56

43^F→GNUGCC:這個就是屬於相容性的議題了,因為必竟 C++ 程式在經過編譯08/10 23:17

44^F→GNUGCC:後會產生組合語言程式,然後再透過組譯與連結產生出機器碼,08/10 23:18

45^F→GNUGCC:只要能產生出 x86 指令碼為何不用?08/10 23:20

47^F→GNUGCC:哈~好像違背原始議題了...^^08/10 23:29

53^F→GNUGCC:Feis : int Q_Q() 這個語法正確但是欠缺可讀性.08/11 00:43

54^F→GNUGCC:uranusjr : 並非不尊重 GCC,純屬個人編碼風格,況且這個寫法08/11 00:46

55^F→GNUGCC:對於一些從 16 bit 時代開始就在寫程式的人就知道代表的意08/11 00:47

56^F→GNUGCC:義.08/11 00:49

63^F→GNUGCC:沒錯,只是相容性的問題,如果編譯器不支援舊式寫法就必需改08/11 06:57

64^F→GNUGCC:成新式了,重點是舊式跟新式的寫法都必需了解然後從中擇一.08/11 06:59

74^F→GNUGCC:Visual C++ 有支援舊式的寫法並且編譯不會有任何錯誤跟警告08/11 20:21

75^F→GNUGCC:有它的功能所在,它可以相容於舊式寫法而不必重新修改,08/11 20:22

76^F→GNUGCC:這個就是 Visual C++ 的彈性.08/11 20:23

77^F→GNUGCC:我剛把 void main(void) 與 int main(void) 轉換成組合語言08/11 20:24

78^F→GNUGCC:的結果就是,這 2 種寫法導致組合語言碼相同,也就是這樣:08/11 20:24

79^F→GNUGCC:xor ax,ax08/11 20:25

80^F→GNUGCC:ret08/11 20:25

81^F→GNUGCC:顯示作業系統會從 ax 取得為 0 的數值.08/11 20:26

82^F→GNUGCC:所謂的編碼風格不代表一定要這樣做,只是個人寫碼習慣不同,08/11 20:27

83^F→GNUGCC:要怎麼使用完全取決於屬於自已的習慣.08/11 20:28

86^F→GNUGCC:呵呵~ Visual C++ 好像不會修改客戶端的程式碼唷^^08/11 20:49

87^F→GNUGCC:各人編碼風格與 ID 無關...請各位不要做過多的連想^^08/11 20:51

91^F→GNUGCC:我用 Visual C++ 2008 以 Debug 啟動反組譯看到原始碼沒變08/12 20:06

92^F→GNUGCC:唷^^但組合語言卻是相同的.08/12 20:07

93^F→GNUGCC:Visual C++ 6.0 更簡潔,只有這段組合語言程式 :08/12 20:08

94^F→GNUGCC:ret 208/12 20:08

95^F→GNUGCC:顯然 Visual C++ 2008 會再次確認 eax 暫存器為 0,只是少用08/12 20:10

96^F→GNUGCC:了 2 個位元組的堆疊空間,各位可以試看看.08/12 20:11

首頁

尾頁