※ 本文為 MindOcean 轉寄自 ptt.cc 更新時間: 2021-08-16 15:38:04
看板 Gossiping
作者 標題 [問卦] 資料結構在業界484用不到?
時間 Sun Aug 15 11:56:46 2021
如題
遇到的同事跟前人留下來的程式
全都用array存資料
根本沒人在用Link list 跟stack 跟遞迴
還是其他間公司有沒有人在用?
我不知道,各位鄉民覺得呢?
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 49.217.69.148 (臺灣)
※ 文章代碼(AID): #1X6920qD (Gossiping)
※ 文章網址: https://www.ptt.cc/bbs/Gossiping/M.1628999808.A.D0D.html
推 : 我都用excel存資料1F 180.217.23.186 台灣 08/15 11:57
推 : kernel表示2F 114.136.159.193 台灣 08/15 11:57
→ : 一般資料不都存word跟excel?3F 123.193.94.158 台灣 08/15 11:57
→ : 怎麼不用到?4F 114.137.86.69 台灣 08/15 11:58
推 : txt夠用了5F 58.114.21.251 台灣 08/15 11:58
推 : 我存資料都用USB6F 223.139.177.149 台灣 08/15 11:58
推 : 快逃7F 223.136.244.46 台灣 08/15 11:58
推 : 廢話ㄇ8F 223.137.141.170 台灣 08/15 11:58
→ : 你乾脆說指標也沒人用好了9F 114.137.86.69 台灣 08/15 11:58
→ : 真的 寫死開大array的很多 XDDDDDDD10F 114.37.227.18 台灣 08/15 11:59
噓 : 還不逃?11F 123.204.13.75 台灣 08/15 11:59
推 : 開大array比link list 好寫多了 XDDDD12F 36.229.102.146 台灣 08/15 12:00
推 : 表示貴司的案子太簡單了13F 203.222.14.206 台灣 08/15 12:00
→ : stack跟recursive怎麼會沒用過
→ : linked list不追求效能用array硬幹就算了
→ : stack跟recursive怎麼會沒用過
→ : linked list不追求效能用array硬幹就算了
推 : 如果資料量不大,效能過得去,也沒人想改16F 111.82.75.97 台灣 08/15 12:02
推 : 反正功能的做得出來 管他用甚麼寫 XDDD17F 36.229.102.146 台灣 08/15 12:02
→ : 這就是業界阿
→ : 這就是業界阿
→ : 老闆給的薪水就只值用Array啦19F 111.240.29.18 台灣 08/15 12:03
→ : 反而是太雞婆去改的人,萬一出問題....20F 111.82.75.97 台灣 08/15 12:03
推 : 如果資料量單純又不大 當然挑簡單粗21F 1.171.88.95 台灣 08/15 12:03
→ : 暴的
→ : 暴的
推 : 唐鳳是不是開超大array做平台阿23F 61.218.40.13 台灣 08/15 12:04
推 : 流量小的軟體先增加使用者卡實在24F 219.91.66.120 台灣 08/15 12:04
推 : 沒有那個需求就不要用25F 114.45.5.131 台灣 08/15 12:06
推 : array 搜尋快啊26F 223.138.123.216 台灣 08/15 12:07
→ : PHP 是不是都用array而已?27F 49.216.133.222 台灣 08/15 12:08
推 : 可能產品少人用沒影響吧28F 150.116.161.211 台灣 08/15 12:09
推 : 除非陣列要一直加,不然你知道極限在哪29F 114.37.224.203 台灣 08/15 12:10
推 : 是你的業界用不到30F 106.73.26.66 日本 08/15 12:10
→ : 當然直接拉大一點最快。31F 114.37.224.203 台灣 08/15 12:10
推 : stack 跟 recursive 沒人用??32F 98.45.135.233 美國 08/15 12:12
推 : 現在還造什麼輪子33F 111.248.115.203 台灣 08/15 12:12
推 : 畢竟現在RAM一直爆衝,又不是在寫算法34F 114.37.224.203 台灣 08/15 12:13
→ : 比賽,省那一點不如早點下班= =
→ : 比賽,省那一點不如早點下班= =
推 : 其實你硬要說,array就是一塊連續的記憶36F 180.217.10.104 台灣 08/15 12:14
→ : 體,所有資料結構把他轉一轉...
→ : 體,所有資料結構把他轉一轉...
→ : 如果是有容量限制的設備相信你不想省也38F 114.37.224.203 台灣 08/15 12:14
→ : 得拚死省出來,能不用省的當然鬆一點好
→ : 得拚死省出來,能不用省的當然鬆一點好
→ : 有需求就用 沒需求就輕鬆一點40F 126.94.97.194 日本 08/15 12:17
推 : link list也可以用array實作啊41F 61.223.72.219 台灣 08/15 12:17
推 : 不是都用 word 嗎?42F 220.136.43.232 台灣 08/15 12:18
→ : 那是他廢 當你資料又多又複雜時 n2 和nlo43F 125.228.52.3 台灣 08/15 12:21
→ : n的差距就出來了
→ : n的差距就出來了
→ : 我以為這些都在 編譯器裡面45F 114.38.138.222 台灣 08/15 12:21
→ : 通訊界 全都有用到 有些os有提供api46F 1.169.97.159 台灣 08/15 12:32
推 : 換個說法 你要幫前輩改嗎? 不改的話47F 101.10.49.162 台灣 08/15 12:42
→ : 就換你後備有這個想法 世代交替
→ : 就換你後備有這個想法 世代交替
推 : 看人 看使用情境 功能沒差但細節有差49F 223.138.235.79 台灣 08/15 12:46
→ : 殺雞不會用牛刀啦 一堆小公司小開發就50F 101.10.93.240 台灣 08/15 12:46
→ : 沒這種需求
→ : 沒這種需求
推 : 遞迴我還真沒看過 很容易有效能問題52F 111.82.24.57 台灣 08/15 13:01
→ : 基本都用loop
→ : 基本都用loop
推 : ram要多少有多少的話,用array沒錯54F 42.72.179.114 台灣 08/15 13:15
推 : linked list 也是用陣列實作阿55F 122.118.114.150 台灣 08/15 13:15
推 : array你告訴我怎麼維護?56F 111.83.34.185 台灣 08/15 13:16
推 : 只用array只能寫出垃圾57F 220.140.3.139 台灣 08/15 13:21
推 : 測腦波有一定程度能58F 114.136.201.202 台灣 08/15 13:25
推 : 代表array太好用59F 219.71.161.211 台灣 08/15 13:27
推 : 呼叫容器底層就是用這些實作阿....60F 180.29.102.240 日本 08/15 13:31
→ : 那就是level不夠61F 111.249.165.151 台灣 08/15 13:34
推 : 說不定根本用不到啊,大砲打小雞?62F 111.71.55.58 台灣 08/15 13:49
推 : 可悲文組63F 101.10.24.185 台灣 08/15 13:54
推 : 遞迴還真沒看過有人用64F 1.164.232.16 台灣 08/15 14:08
推 : 都linq了 array誰在用65F 180.217.45.134 台灣 08/15 14:15
推 : 我有用過遞迴,但被前輩說不要用XD66F 36.229.157.150 台灣 08/15 14:30
推 : 遞迴浪費資源…效率也不好68F 220.134.27.244 台灣 08/15 14:39
→ : 疊太多stack會爆70F 220.134.27.244 台灣 08/15 14:40
推 : 那是你沒遇到吧72F 220.132.76.252 台灣 08/15 14:51
推 : 遞迴的問題是沒寫好很容易吃資源,前輩是擔73F 111.254.210.17 台灣 08/15 16:09
→ : 心這個啊 XD
→ : 心這個啊 XD
推 : Stack沒人用 你認真????75F 114.32.3.21 台灣 08/15 16:43
→ : 所以是寫不好遞迴的人有問題,不是遞76F 61.231.200.120 台灣 08/15 16:47
→ : 迴有問題
→ : 迴有問題
推 : 藏在 API 裡阿,哪有沒用到78F 115.43.122.114 台灣 08/15 18:57
→ : 用遞迴就低能兒,正常寫法都做得到79F 27.242.130.222 台灣 08/16 14:55
--
※ 看板: Gossiping 文章推薦值: 0 目前人氣: 0 累積人氣: 202
回列表(←)
分享