作者查詢 / littleshan

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

作者 littleshan 在 PTT [ C_and_CPP ] 看板的留言(推文), 共2181則

限定看板：C_and_CPP

首頁

尾頁

Re: [問題] shared_ptr如何避免cyclic reference?

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

作者: KanzakiHAria - 發表於 2019/06/17 21:37(6年前)

1^F→littleshan: 呃，GC 是可以解決 cyclic reference 的，實務上因為06/18 08:42

2^F→littleshan: cyclic 太常見，所以大部分語言都是用 GC 而不是 smar06/18 08:42

3^F→littleshan: t pointer。06/18 08:42

Re: [問題] 為什麼作業系統都用C寫？　而不用C++呢?

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

作者: jobsdone - 發表於 2019/06/12 22:20(6年前)

16^F推littleshan: Rust 當然可以實作 OS，Redox OS 就是了06/15 08:55

17^F→littleshan: C++ 實作的 OS 可以看看 haiku06/15 08:57

18^F→littleshan: 過十年還能吵這個，C 真的是被過度神話的語言06/15 08:59

[問題] thread safe 觀念請教

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

作者: lovejomi - 發表於 2018/06/03 00:07(7年前)

16^F推littleshan: C++ container 提供了 ref 就無法做到 thread safe06/03 16:27

17^F→littleshan: 如果你想要兩者兼得就不能用 C++，改用 Rust 吧06/03 16:28

18^F→littleshan: 另一個解法是把 ref 改成 proxy object06/03 16:29

19^F→littleshan: 只是效能會變得超級慢06/03 16:29

[問題] 配置大量記憶體

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

作者: rbufghj9713 - 發表於 2018/05/11 22:11(7年前)

4^F推littleshan: 其實很多 memory allocator 的實作都是先向作業系統要05/12 00:46

5^F→littleshan: 一大塊再慢慢分，所以如果你的總用量是確定的，05/12 00:47

6^F→littleshan: 一開始就直接配置好一大塊，效能會比較好05/12 00:48

10^F推littleshan: 我猜你的疑問是「系統剩餘的記憶體沒有連續怎麼辦」05/14 01:01

11^F→littleshan: 實際上現代的 OS 都會用 paging 來解決這種問題05/14 01:01

12^F→littleshan: 所以一次直接要整塊就好，OS 會試圖把片段組起來給你05/14 01:02

[問題] C規格書的閱讀方式

[ C_and_CPP ]49 留言, 推噓總分: +5

作者: CsCdanNix - 發表於 2018/03/11 19:56(7年前)

18^F→littleshan: C 是為了開發 Unix 系統而設計的03/12 21:12

19^F→littleshan: 那個年代 (197x) 還沒有 Linux03/12 21:12

[問題] volatile和multi-thread 的觀念問題

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

作者: dreamboat66 - 發表於 2017/09/19 00:43(8年前)

8^F推littleshan: 因為標準語焉不詳，volatile並不保證thread safety09/19 10:47

9^F→littleshan: 請見 https://goo.gl/GGRAqd09/19 10:47

[問題] int array 轉 double point

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

作者: usanhuang - 發表於 2017/08/29 01:59(8年前)

3^F→littleshan: undefined behavior08/29 02:12

[閒聊] 關於D語言

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

作者: wudidog - 發表於 2017/07/11 20:03(8年前)

22^F推littleshan: 板友提的都是原因，但有幾個因素導致go搶了更多user07/12 00:22

23^F→littleshan: 1. go在設計上就非常適合開發後端07/12 00:24

24^F→littleshan: D雖然也OK，但go一開始就給了goroutine與channel07/12 00:25

25^F→littleshan: 儘管go會有比較多的gc，但偏偏這對後端來說可接受07/12 00:25

26^F→littleshan: 2. go直接拋棄了generics與exception這幾項困難的功能07/12 00:27

27^F→littleshan: 拿掉這些功能讓語言變得容易實作07/12 00:29

28^F→littleshan: 同時使用者的學習曲線也大幅降低07/12 00:30

29^F→littleshan: D 相較與 C++ 來說當然是簡單很多07/12 00:39

30^F→littleshan: 但go的學習曲線是script等級的，團隊更容易導入07/12 00:40

31^F→littleshan: 3. 最後是go有google大神在背後支援07/12 00:42

32^F→littleshan: 一開始toolset就滿完整的，改版速度也快07/12 00:43

33^F→littleshan: 相較之下，儘管D已經出現了很久07/12 00:45

34^F→littleshan: 卻一直擺脫不了「這工具是否已經穩定」的疑慮07/12 00:46

35^F→littleshan: 這對開發團隊導入是非常大的阻礙07/12 00:46

69^F推littleshan: 樓上完美示範go為何搶走D user XD07/12 16:20

70^F→littleshan: 另外，你想要兼顧效能記憶體底層操作和跨平台07/12 16:21

71^F→littleshan: 那C++以外的答案其實就是rust07/12 16:21

72^F→littleshan: 說它不符合你的理念其實很矛盾07/12 16:35

81^F推littleshan: 或是刻 dropbox 的底層07/12 20:29

87^F推littleshan: 我從來沒說rust很簡單，只說了它有C++的效能而已07/12 22:29

88^F→littleshan: 要兼顧效能記憶體底層操作本來就是高成本07/12 22:29

89^F→littleshan: 不管哪個語言都一樣的，即使是C++07/12 22:29

90^F→littleshan: dropbox大部份後端用go，少部份用rust07/12 22:40

91^F→littleshan: 這點可以說明「接近C++的效能」通常不是主要考量07/12 22:42

117^F→littleshan: 你可以用 -C prefer-dynamic 切換到動態連接07/15 10:37

118^F→littleshan: 但部署時就要自己把符合版本的runtime一起發出去07/15 10:39

119^F→littleshan: 然後D沒有比較好，gdc預設選項編出的hello world是6M07/15 10:39

120^F→littleshan: 這類新語言預設用static link很正常07/15 10:40

121^F→littleshan: 因為不是每個環境都有裝他們的runtime07/15 10:40

Re: [問題] 關於函數指標的參數型別轉型

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

作者: littleshan - 發表於 2017/06/26 22:33(8年前)

16^F→littleshan: 對，我的看法是標準對於轉型後呼叫不做任何保證06/28 23:11

[問題] 關於函數指標的參數型別轉型

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

作者: a27417332 - 發表於 2017/06/25 22:33(8年前)

1^F推littleshan: compatible type有嚴格的定義，基本上就是相同的type06/25 23:13

2^F→littleshan: 「可以互轉」並不表示它們是compatible type06/25 23:13

首頁

尾頁