[ 首頁 / 搜尋 / 管理Discord ] [ Komica首頁 ] [ 跨版面 ] [ 雜談 / / 攝影 / 運動 ] [ 人工智慧 / 程設交流 ] [ 蔚藍檔案 / 英雄聯盟 / 米哈遊 / Minecraft / 魔物獵人 / 勝利女神:妮姬 / Pokémon / 刀劍亂舞 / Unlight ]

/cs/ - 程設交流

Computer science
[]
名稱
Email
主題
回覆
檔案
嵌入
Options
密碼 (用來刪除檔案。)
  • Allowed file types:jpg, jpeg, png, gif, mp4, webm
  • Max filesize is 10 MB.
  • Max image dimensions are 10000 x 10000.
  • You may upload 1 per post.

  [Go to bottom]  [Catalog]  [Reload]  [Archive]  [Featured]

File: 1739557312909.png (196 KB, 1562x1000, 截圖 2025-02-15 02.06.09.png)

b12968fe No.279[回覆]

我是上串開IDE的,想了很有要不要另外開一串。
想說主題不一樣還是開了。
這陣子對我來說的另一個好消息大大概就是有位網友接手了
Notepad++的C#外掛模板維護吧。
之前就一直想寫Notepad++外掛來輔助一些日常操作。

但之前的C#模板太過久遠,編譯出來的外掛換到比較乾淨的環境上就跑不動。
找了半天發現是一個dll依賴.Net Framework 3.5的東西…
想試著班但是沒C++技能搬不動…
直到這幾天無聊去看才發現有人接手。
萬歲。

至於說VSCode,雖然是主流,但除了最初見到VSCode的那個專案很不愉快以外,
VSCode也沒有強大到能夠壓制住那個專案的回憶讓我喜歡上他,
他太過鬆散、隨意、缺乏整合性。
貼文太長了。點這裡查看全文。
8 則貼文 與 1 則含圖回覆 已省略。點擊回覆以查看

b12968fe No.341

TOML的部分,最後投降了,
Tomlyn雖然有把TomlTable開出來給我用,但是相關API很不完整。
只是有把東西開出來的程度,GetXXX 直接拿Object要自己轉型整個超出我能力範圍還要加上我跟TOML不熟。
現在只能乖乖把要儲存的部分分開一個類別單獨處理,然後Serialize/Deserialize了。
當初就是想避免這種狀況才想要手動寫文件的。

現在想想NewtonSoftJSON那個從頭包到尾完整又可靠的API真的是奇蹟。

3605a1c3 No.342

>>341
nuget上面好像還有其他的library,可以試試看?

不過主要原因應該是toml本來就比較小眾吧
這種時候你就該自幹一個開源(ry

然後往前看了一下,你本來是用ini
那直接找ini的library會比較輕鬆吧
畢竟是微軟來的東西,應該比較有支援

b12968fe No.343

File: 1743862976456.jpg (137.38 KB, 849x1031, Screenshot 2025-04-05 2156….jpg)

今天用物件寫出寫入搞了快半天,Tomlyn跟Tomlet這兩家都撞了一些奇怪的Bug。
Tomlyn雖然可以順利寫檔案,但是讀進來的時候跟我說無法設定某某Property。
Tomlet則是結構上搞不出想要的結構,然後讀取的時候疑似踩到編碼問題(丟繁體中文進去)。
結論是:已經在這邊卡太久了,先躲回微軟邪惡領土用XML去了。

>>342
>>nuget上面好像還有其他的library,可以試試看?

https://www.nuget.org/packages?q=TOML&includeComputedFrameworks=true&prerel=true&sortby=created-desc
我看看。
nuget上面頭幾個結果看起來像是給新的Extension框架增加TOML支援,
後面有Config的應該都差不多是這樣。
不過個別Package可能可以拆出來用。

剩下大概就 r-toml
貼文太長了。點這裡查看全文。

9f41d703 No.345

>>343
有找到這個看起來像是官方的ini api
https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.configuration.ini

XML可以接受的話,直接用json比較好改吧?

92b5570f No.346

>>345

主要是工作上已經很多JSON了,下班想要嘗試點不一樣的。
本來想說Configuration相關的東西是跟設定檔高度綁定的,
不過仔細想想專案檔好像跟設定檔沒有差太多…
再找時間試試看。



YouTube embed. Click thumbnail to play.

1f0b6ab3 No.339[回覆]

Interview with Vibe Coder in 2025

出張嘴讓AI寫程式然後把報錯貼給AI自動debug是真的滿爽的 快變廢人了

c46e2d14 No.340

https://www.ettoday.net/news/20130117/153867.htm

想到很多年前的這個案例。
要爽可以,但是要小心不要變廢人啊。



File: 1743257043856.png (188.01 KB, 1086x940, 截圖 2025-03-29 21.42.55.png)

46853fb0 No.328[回覆]

前陣子跟人吵 .Net Framework 4.5到底有多過時的議題。
說真的在很多領域還有一堆更過時的東西,區區一個 Framework 4.5算什麼啦。
更不用說即使你編譯目標是4.5,新型windows上也是用 4.8 / 4.8.1 的Runtime去跑。
還有就是 4.8 以後就接到新型.Net去了,那個改動幅度根本是製造就業機會啊。
真的活該寫.Net…(這好像是另一串)

總之,
為了反嗆,我去查了一下才發現,傳說中的上古語言COBOL居然到2023年還有新規格。

https://zh.wikipedia.org/zh-tw/COBOL

實際上還有一些以為已經死了的東西卻還是在活著,也有一些看起來還活著卻像是死了的東西。

路過一篇文章:

貼文太長了。點這裡查看全文。

f250ea07 No.329

只要有銀行的核心伺服器還在用 COBOL就不會真的死掉吧
PHP也是寧願他已經死了就不用再維護前人留下的大屎坑

46853fb0 No.330

>>329

重點是COBOL意外還有改版跟更新。
雖然很多銀行用的應該是那張表上的 COBOL-86前後規格。

PHP要死很難,包括現在的K島跟這個網頁都是PHP。
這東西應該是asp之後第一個大紅的動態網頁架構吧,
開源特性跟超高普及率讓他基本死不了,或者即使死了,
也會常常以各種方式回來…

f10a5653 No.334

Fortran
https://fortran-lang.org/
2023還出了新版

R在資料處理領域活的滿好的



YouTube embed. Click thumbnail to play.

eae1a2c5 No.331[回覆]

Terminal Tips in VS Code

eae1a2c5 No.332

File: 1743305044832.jpg (123.74 KB, 1397x591, 螢幕擷取畫面 2025-03-30 112315.jpg)

vscode terminal的自動完成輔助功能
terminal intergrated suggest



YouTube embed. Click thumbnail to play.

1cfe52d3 No.306[回覆]

Why You Shouldn't Nest Your Code
8 則貼文 與 2 則含圖回覆 已省略。點擊回覆以查看

bf672d5f No.319

>>318
不是餵AI給的回答

switch的快慢取決於語言和資料大小

dictionary[] 儲存計算值在記憶體中的各個位置。當dictionary[]找不存在的計算值時,會新增延遲。

當switch使用類似array()的連續記憶體區域時,switch可能會比dictionary[]使用的hash table更快。否則,switch速度較慢。

array()記錄大量資料時會變慢:array()將所有字串儲存在其整個範圍內的記憶體中,或在 C/C++ 等語言中手動分配內存,直到明確釋放記憶體。對於大型數組,這可能會佔用大量記憶體。

當涉及到讀取資料時:switch 讀取資料以線性時間O(n),而array()讀取資料以更快的恆定時間O(1)。hash table對於小數據是 O(1),對於不確定的大數據是 O(n)。if時間複雜度為O(1)。 nested if時間複雜度有不同意見。 從 O(1) 到 O(m*n)。最基本的nested for-loop的時間複雜度是O(n^2)。

c3096d4c No.321

是說樓上一直有人講Dictionary/HashMap,
不過以我自己的認知,if/else-if 結構最大的優勢不就是
「設計得當的時候可以避免不必要的判斷」?

變成 Dictionay / HashMap 的結構不就表示要把所有條件都檢查一遍?
這樣不是浪費一堆算力? 也難怪 case 裡的東西都會被要求是常數。

然後
>>307

這個波動拳,其實只需要放開心胸去搞清楚if-elseif 的執行方式。
完全可以用if-elseif 拉平。
這類型好像曾經是專科跟半路出家的鑑別器,
基礎不好的就很容易寫出這種東西,
有人帶的可能是很多組if或者是一片平的if-elsif。

04d068e7 No.322

File: 1742317584966.png (49.41 KB, 438x478, Screenshot_2025-03-18_09-5….png)

>變成 Dictionay / HashMap 的結構不就表示要把所有條件都檢查一遍?

都檢查一遍 ===> if key in dict: ====> O(n)

if dict.get(key): =====> O(1)

dbecdd7c No.326

>>322

老兄你這個範例會把加減乘除都算一次耶。
今天你只是加減乘除,
如果換成更複雜的計算不就全部都要跑一次?

dbecdd7c No.327

不覺得Switch/Case會難維護。
現實來說就是會有一個input有N種狀態的狀況。
會有問題的其實是遇到可以拆出去變另一個方法卻還是硬寫在一起把層數拉高,
或者判斷先後順序明確,可以用if/elsif+return卻硬要弄成狀態機用
switch/case,基本上就是這篇開頭影片在講的nesting。
雖然對電腦來說做的事情差不多,
但不可否認把原始碼的層數控制住還是會對可讀性有幫助。



YouTube embed. Click thumbnail to play.

d66fb5d5 No.308[回覆]

https://github.com/ClockworkLabs/SpacetimeDB

針對遊戲設計的系統 不知道實用度如何
2 則貼文 與 1 則含圖回覆 已省略。點擊回覆以查看

ecadfafb No.314

>>312

我也是這樣想,看到依賴RAM就有點縮了。
不過這東西的主要目標應該是RAM很充足的伺服器端。
畢竟現在RAM沒以前那麼貴。
現在還真的有人用幾T的RAM來打電動的。

其實看到這東西的第一個想法是不知道有沒有可能取代SQLite作為Portable的移動式資料庫使用。但是現在看來應該不容易。

62c24673 No.320

去官方的D扣問到了。

>>這段老實說有看沒有懂。似乎是高度依賴RAM的意思。


以下是官方回復

>>1. Base memory usage is extremely low
>>2. Eventually we'd like you to be able to use it as a library (like SQLite)
>> but right now it's more of a server

RAM的基礎消耗很低,不過這個可能還是得看使用者的實際運用方式而定。
我比較在意的能不能當SQLite替代品這件事情,雖然目前不行但是是官方表示這是最終目標之一。
以我個人來說是可以去投入研究的訊號。
覺得未來這東西搞不好會取代SQLite的地位。

53183eec No.323

看到要用rust我就縮了
我對rust的lifetime語法真的很感冒
它如果不寫lifetime的話的一切看起來都很美好
尤其是pattern match真的很棒
可一旦用到lifetime的話就會把你所有程式碼弄得不堪入目
標準的一顆屎壞了一鍋粥

f102875a No.324

>>323

你可以用C#啊。
再者,人家底層是WebAssembly,
就算你微軟產品一律不用,
你也可以去找其他可以編譯到WebAssembly的語言自己寫模組。

53183eec No.325

>>324
哦哦原來還有c#
我看到開頭只有寫rust就以為只能用rust咧
這樣有空來試看看



YouTube embed. Click thumbnail to play.

25107e28 No.298[回覆]

Never* use git pull

b7503593 No.301

File: 1741615833374.png (111.21 KB, 725x814, ClipboardImage.png)

工作專案現況(暫時只有一個人)。
沒練好就出來就會變成這樣。

15ef9b05 No.303

>>301
我單幹的專案都直接在main上編輯的 超級壞習慣

61589b91 No.304

>>303

私人專案後來直接降級成資料夾版控,
改壞直接跳回上一個可用版重來就好,還不用在那邊爬哪個commit。
反正改了甚麼我很清楚,腦袋不清楚git清清楚楚也沒用。
而且現實上也只會向前走,自己做根本不會有退版跟merge的需求。

ede01141 No.305

File: 1741853246383.png (435.43 KB, 1359x567, Screenshot_2025-03-01_06-1….png)

>>304
我的習慣是每次輸入 git init 然後 git pull



File: 1732351693750.jpg (107.91 KB, 1000x1000, json.jpg)

c790f299 No.231[回覆]

網際網路世界中,JSON是重要的標記語言。
JSON非常有名且重要的一個特性就是「沒有註解」。
https://medium.com/@marycriv/why-json-doesnt-allow-comments-fe93f7106c62
https://www.ietf.org/rfc/rfc4627.txt

有印象設計JSON格式的人也有解釋過原因,不過一時找不到。

但這幾年,隨著JSON被大量運用在config檔中。
尤其是VSCode的設定檔。
似乎出現了某種可以寫註解的JSON變種。
因為微軟一貫的就是要你搞混原則,
所以附檔名也還是.json,就跟 xxx.js裡面其實有可能是TypeScript一樣,
搞到不分資深資淺的低能兒以為JSON真的可以寫註解。

所以說,VSCode或是現在這些可以寫註解的變種,
貼文太長了。點這裡查看全文。
6 則貼文 與 1 則含圖回覆 已省略。點擊回覆以查看

74585d7f No.243

>>238
json我最賭爛的是Date還要我自己轉
媽的

1f1a8b0f No.244

>>243

還有負數沒辦法用數字得用字串處理的問題…
跳脫也是很煩。

85358112 No.299

>>231
因為微軟一貫的就是要你搞混原則(X)
微軟就是唯一規則,微軟做什麼都是對的(O)

微軟門外漢根本就沒搞懂JSON是幹嘛的
這東西設計上就是給程式讀寫的
就不是給人類閱讀的
要註解幹嘛?
只會害你寫出更複雜的parser而已

69944b5e No.300

>>299
>>微軟門外漢根本就沒搞懂JSON是幹嘛的

微軟門外漢(X)
整個社群(O)

一直都有這種不肯學新東西,只想到一招打天下的生物在。
jsonc/json5差不多就是這種狀況的產物。

>>這東西設計上就是給程式讀寫的


字串跳脫真的是痛苦。很清楚可以感受到這沒有要給人用的意圖。

>>只會害你寫出更複雜的parser而已


貼文太長了。點這裡查看全文。

69944b5e No.302

>>299

https://github.com/json5/json5/commits/main/?
35e6182551b63809e61243b0+419
JSON5 2012就開始了。

https://github.com/onury/jsonc/commits/master/

JSONC就晚一點,在時間點上來看,應該跟VSCode是差不多同期的東西。
大概是微軟這陣子的從善(被)如(奪)流(舍)政策吧。



File: 1741177635559.jpg (269.32 KB, 1236x682, 新點陣圖影像 (2).jpg)

b1367b92 No.293[回覆]

不太確定到底是不是
真的是由俄羅斯自既完全獨立開發完成的?
現在俄國人好像終於搞出
屬於自己的國產3A遊戲引擎的樣子???…

https://www.youtube.com/watch?v=Iw7sb4t0ohY

0e4007cc No.294


0e4007cc No.295


5b17aa1f No.296

2005就有了 意外的老
可惜已經閉源不知道內部結構發展成怎樣了

3fdf9cfb No.297

不看好,俄羅斯價值滿滿。
加上從幾年前有消息到現在都沒聽說有什麼作品要用他做。
商業競爭力堪憂。
而且現在早不是遊戲引擎百家爭鳴的年代(那個時代是198X~2000年左右),
也不是獨立遊戲大爆發的時代(2008~2014)。

現在的遊戲引擎基本上分三種,
一種是超大型上到3A下到小黃油都能做的,代表Unity / Unreal,
其中Unity在Unreal想通開始搞訂閱跟抽成制之後就節節敗退,
前陣子還搞不清楚狀況在那邊自爆。
很噁心的一點是,
學校裡的學生一聽Unreal是3A大作用的引擎還有教育授權可以免費用之後
都無腦衝過去學,搞到最後真正構成壁壘的,只有$$…

另一種就是主打編輯方便、簡易操作,針對特殊遊戲類型特化的引擎。
貼文太長了。點這裡查看全文。



YouTube embed. Click thumbnail to play.

95590f3a No.291[回覆]

Slack Tries to Handle More Traffic, Self-Destructs Instead


  [Go to top]   [Catalog]
刪除貼文 [ ]
[1] [2] [3] [4] [5] [6] [7]
[ 首頁 / 搜尋 / 管理Discord ] [ Komica首頁 ] [ 跨版面 ] [ 雜談 / / 攝影 / 運動 ] [ 人工智慧 / 程設交流 ] [ 蔚藍檔案 / 英雄聯盟 / 米哈遊 / Minecraft / 魔物獵人 / 勝利女神:妮姬 / Pokémon / 刀劍亂舞 / Unlight ]