Rust part21

**デフォルトの名無しさん** · 2023/08/15(火) 22:24:39.45

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part20
https://mevius.2ch.net/test/read.cgi/tech/1677771928/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.2ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2023/08/16(水) 10:47:04.56

>>5
同意はするが
Rustの資料って体系化されずにとっ散らかってるイメージがあるから
手っ取り早くアクセスできるようにまとめてくれてるのは有難い

**デフォルトの名無しさん** · 2023/08/16(水) 14:44:41.59

>>17
rustupがリンクが使えるファイルシステム？じゃないと動かないっぽい
ノートPCでNTFSパーティションがカツカツなのでSDカード(FAT32)上にインストールしたいがリンクできないとか怒られる
rustcやcargoはリンクできないから動かないようには見えないしよくわからない制限
この現象は公式フォーラムにも書かれていたがパーティションを変更するみたいな回答しかなかった
現状はネイティブビルド環境は公式からプレビルドのバイナリを落としてきて解凍すれば構築できるが
そのような代替手段がない？クロスビルド環境は構築できない状態

**デフォルトの名無しさん** · 2023/08/16(水) 15:31:51.82

ここは素人相手のサポートセンターじゃないんだから「動かない」とか「動かないっぽい」とかじゃよっぽどの暇人以外には相手にされないぞ

**デフォルトの名無しさん** · 2023/08/16(水) 15:45:31.11

現象は
ttps://users.rust-lang.org/t/can-t-install-rust/56019/15　←exFATパーティションにインストールしようとして失敗している
これと同じだと思う

**デフォルトの名無しさん** · 2023/08/16(水) 18:15:04.82

ﾜｯﾁｮｲスレに書いといたんでよろしゃっす

**デフォルトの名無しさん** · 2023/08/16(水) 18:52:12.16

>>20
rustupをターゲット先で動かす必要ある？
例えばターゲット先がWasmだとそこにrustupもcargoもないけど
それらがある手元でWasmバイナリを生成できるよね
リンクが使えるファイルシステムでコンパイルできない状況がわからないので教えて

**デフォルトの名無しさん** · 2023/08/16(水) 22:31:03.77

>>24
exFat ではシンボリックリンクを作れないって話が明瞭に書いてあるだろ。
ファイルシステムの機能として無いものは無い。

**デフォルトの名無しさん** · 2023/08/16(水) 23:07:47.05

>>25
クロスビルドは任意の環境で行なえるのに
なぜFATしか使えない環境でビルドするのか不思議に思ったのです
すみません

**デフォルトの名無しさん** · 2023/08/17(木) 00:30:25.16

ポータブルメディアだとFATをつかうのはそれなりにあることだからなあ。
買った時点でフォーマット済みなのも普通だし。
さすがにSDカードに開発環境を構築するのは想定外と言えるにしても外付けハードディスクくらいなら事情によっては無いこともないんじゃないか。

**デフォルトの名無しさん** · 2023/08/23(水) 15:46:36.91

let hoge = "もとの文字列";
let hoge = hoge.replace("なんか1を", "別のなんか1に変換");
let hoge = hoge.replace("なんか2を", "別のなんか2に変換");
let hoge = hoge.replace("なんか3を", "別のなんか3に変換");
...
みたいなのが連続して実行したいとき
まとめてやってくれるような関数とかありますか？
また変換表がVecとかMapとかDBみたいなのに対応してるものもありますか？

**デフォルトの名無しさん** · 2023/08/23(水) 17:55:57.94

>>28
単に連続して実行したいだけなら自分でループさせる関数作れば十分だと思う
効率的なアルゴリズム実装を探してるならとりあえずaho-corasick
regexを使ってるようなプロジェクトならregexでもいいと思う

**デフォルトの名無しさん** · 2023/08/23(水) 18:02:34.00

もとの文字列が大きくなればなるほどstr::replaceを繰り返し実行する方法は効率が悪くなる
もとの文字列が小さいならあんまり気にする必要無い
少なくともベンチマークとってから考えるべき

**デフォルトの名無しさん** · 2023/08/23(水) 23:32:44.32

その前に変換された部分を後続の変換の対象にするのかしないのかを決めないと
「まとめてやる」だから対象にしないっぽいけど
文字列リテラルのエスケープを本来の文字に置換するイメージでいいのかな

変換前の文字列を簡単なパターンで表現できるなら正規表現のライブラリがいいと思う
余分にひっかけた場合は変換せずにそのまま通す感じで
マッチした文字列→変換する文字列の処理を自前の関数で書くとよさそう

**デフォルトの名無しさん** · 2023/08/23(水) 23:46:47.50

aho使うのが楽
入力がimpl std::io::Readで出力がimpl std::io::Writeを指定できるからファイルでもなんでも楽

**デフォルトの名無しさん** · 2023/08/24(木) 07:02:22.08

thx

**デフォルトの名無しさん** · 2023/08/26(土) 21:30:29.95

constな再帰関数で以下のエラーが出てその対処方法を知りたいのですが

error[E0080]: evaluation of constant value failed
| foo(n)
| ^^^^^^ exceeded interpreter step limit (see `#[const_eval_limit]`)

const_eval_limitで検索しても削除された(？)らしい情報しかわかりませんでした
どう指定するとリミットを増やせますか？

**デフォルトの名無しさん** · 2023/08/26(土) 22:02:13.69

>>34
古いバージョン使ってない？

**デフォルトの名無しさん** · 2023/08/26(土) 22:23:39.67

1.72での変更みたいだね

**デフォルトの名無しさん** · 2023/08/27(日) 08:31:30.86

一昨日リリースの1.72にこう書いてあるな
https://blog.rust-lang.org/2023/08/24/Rust-1.72.0.html
you can allow(const_eval_long_running) to permit especially long const evaluation.

ところがこう指定してもエラーになる
#[allow(const_eval_long_running)]

正解はこれ
#[allow(long_running_const_eval)]

**デフォルトの名無しさん** · 2023/08/27(日) 19:53:52.23

>>37
リリースを読む奴はほとんどいないだろってことでいい加減でも良いやといことだろうな
Rust野郎にしてみれば手を抜を抜けるところは手を抜くって良いこと

**デフォルトの名無しさん** · 2023/08/27(日) 21:39:30.30

コンパイルエラーで正しいほうが表示されるから問題ないわな

const_eval_limitのほうは↓
#![feature(const_eval_limit)]
#![const_eval_limit = “10000000”]

**デフォルトの名無しさん** · 2023/08/27(日) 23:07:34.85

レビューすり抜けちゃったんだな
PRでも出してあげたら

**デフォルトの名無しさん** · 2023/08/28(月) 03:13:40.15

英単語のスペルチェックはしなくて良いから
関数や変数のスペルチェックに力を入れてくれ > Codeエディタさん

**デフォルトの名無しさん** · 2023/08/29(火) 03:19:51.47

VSCodeの余計なお世話機能外しのサイトないかな？とにかく邪魔

**デフォルトの名無しさん** · 2023/08/29(火) 09:29:50.39

let hoge = "hoge".to_string();
let v = hoge.as_bytes().to_vec(); // ← ここでデータのコピーは発生しますか？

**デフォルトの名無しさん** · 2023/08/29(火) 09:40:59.22

あー
let v = hoge.into_bytes(); // これか

**デフォルトの名無しさん** · 2023/08/29(火) 10:07:33.54

let v = hoge.as_bytes().into(); // これも等価なんか？

**デフォルトの名無しさん** · 2023/08/29(火) 10:08:22.27

>>43 と >>45 が等価で
>>44 だけ違うんか？

**デフォルトの名無しさん** · 2023/08/29(火) 10:28:52.72

>>43
コピーを発生せずに別の型へ変換するには「消費してxxxへ変換」(into_xxx)するしかないため元が所有権を持たなければならない
つまり単なるスライス参照&[T]をto_vec()するのはコピーが発生する
一方で所有権を持つスライスBox<[T]>ならばinto_vec()でコピーを発生させずにVecにできる
このto_xxxとinto_xxxに注意

>>44
互いに消費してコピーを発生せずに行き来できる
let vec = string.into_bytes();
let string = String::from_utf8(vec).unwrap();
前者は特にVec<u8>になるためinto_vecではなくinto_bytesと名付けられている
後者はutf8保証チェックが入るためResultが返る
その保証を人が与えるならチェックを省略できる
let string = unsafe { String::from_utf8_unchecked(vec) };

**デフォルトの名無しさん** · 2023/08/29(火) 11:53:16.22

>>46
リファレンス見ればすぐわかるよ
もし見方や調べ方がわからないならそれを質問するといい

**デフォルトの名無しさん** · 2023/08/29(火) 14:58:40.58

>>42
VSCodeの邪魔な機能で最初に思い浮かぶのはinlay hintsだな

［File > Preferences > Settings］の［Editor › Inlay Hints: Enabled］を
offかoffUnlessPressedに変えると消える

offUnlessPressedだとCtrl + Altを押してる間だけ表示される

**デフォルトの名無しさん** · 2023/08/30(水) 11:49:10.17

unsafeを使ったコードで
有効な参照ではないことを確認する方法はありますか？

**デフォルトの名無しさん** · 2023/08/30(水) 15:30:33.41

miriやaddress sanitizerやloomのようなツールとテストの組み合わせで検知するくらいじゃないかな
もちろん100%の検知は不可能

**デフォルトの名無しさん** · 2023/08/30(水) 15:37:47.00

日本人は100%とか完璧とか絶対とか求めるの好きだよね。
やる側が志すのはいいんだけど、たいていはやらない側が求めてくる。

**デフォルトの名無しさん** · 2023/08/30(水) 17:42:42.30

そういう理にかなわないことをしているから原発がぶっ飛ぶんやで

**デフォルトの名無しさん** · 2023/08/30(水) 17:57:48.34

address sanitizerじゃなくてmemory sanitizerだった

**デフォルトの名無しさん** · 2023/08/30(水) 20:21:44.39

無効な参照は即UBじゃなかったけ
なので正しく書かれたRustプログラムの参照はすべて有効

**デフォルトの名無しさん** · 2023/08/30(水) 21:05:03.06

正しく書かれてるかどうかを確かめる方法を聞いてるんだろ

**デフォルトの名無しさん** · 2023/08/30(水) 22:02:55.54

rustでdll造ってCから使うとき
rust側で勝手に捨てられるのは困るな

**デフォルトの名無しさん** · 2023/08/30(水) 22:17:03.68

そのためにforgetとかleakみたいな謎関数がある
存在は知ってるけどまだ使う機会に恵まれない

**デフォルトの名無しさん** · 2023/08/31(木) 00:43:59.43

Cに所有権ごと渡すなら使うのはinto_rawかfrom_rawじゃね

**デフォルトの名無しさん** · 2023/08/31(木) 11:31:08.47

Rustしばらく使ってるとC/C++描けなくなってくる

**デフォルトの名無しさん** · 2023/09/01(金) 16:56:03.45

sqlite3 用の crate って sqlite3 という名前のがあるけど
rusqlite 使うのとどっちが良い？

**デフォルトの名無しさん** · 2023/09/02(土) 07:37:58.97

失礼します

Rustは制約の厳しい言語だから（環境さえ整えば）他言語にトランスパイルしやすい言語
という認識は合ってるでしょうか？

**デフォルトの名無しさん** · 2023/09/02(土) 08:12:23.91

Rustは制約がほとんどなく自由な裁量の大きな言語の一つ
楽に書ける方法の一方で色んな観点を極めることにより書き手によってメモリ利用法や実行速度もピンキリになりうる
色んな環境で動かせることもできてOSの無い環境やstdライブラリを使わない方法など自由が大きい
プログラミングパラダイムやスタイル指向の見地からも書き手によって様々な方針をとることができる

**デフォルトの名無しさん** · 2023/09/02(土) 08:29:19.99

ランタイムが必須かどうかも制約として重要になってくる
C/C++やRustはそのような制約がないため他の言語のライブラリ作成にも用いることができる
WebAssemblyでの実行についても同様でそのような制約のないRustが有利なため最も使われている

**デフォルトの名無しさん** · 2023/09/02(土) 11:00:44.98

>>62
トランスパイル先言語との機能的互換性の高さやや元言語のコンパイラが単純なほうがトランスパイルしやすいと思う
例えばOwnership/Borrow/Lifetimeあたりのトランスパイルが楽かどうか

**デフォルトの名無しさん** · 2023/09/02(土) 11:44:04.91

>>65
壮大な勘違いしてるな
実行時に所有権やライフタイムは一切出て来ないぞ

**デフォルトの名無しさん** · 2023/09/02(土) 11:48:36.47

>>66
壮大な勘違いしてるな
トランスパイル時は実行時ではないぞ

**デフォルトの名無しさん** · 2023/09/02(土) 11:50:40.77

一口にトランスパイルといっても、元言語にあった属性をどこまで先言語に引き継ぐかは目的に応じた取捨選択がなされるものです
前例がないので>>62に対する答えは「未知数」としか言えないですね

あるいは言語自体に「トランスパイルのしやすさ」という属性があるとすれば、それは「言語自体がトランスパイルされることを前提として設計されているか」と同義でしょう
その側面から言えば答えは「いいえ」です

**デフォルトの名無しさん** · 2023/09/02(土) 12:05:15.52

ライフタイムは妥当かどうかの静的なチェックに使われるもの
トランスパイル先に持ち込まれることはない

**デフォルトの名無しさん** · 2023/09/02(土) 13:06:33.37

短絡思考 + 自己弁護 = 複オジ

**デフォルトの名無しさん** · 2023/09/02(土) 13:21:18.64

トランスパイルというとTypeScript→JavaScriptみたいにシンタックスをほぼ保ったまま変換することを意図してる？
それともRustで書いたコードをトランスパイル先のランタイムなり処理系なりで動かせれば良い？
後者ならトランスパイル先言語でWASMランタイム用意すればRustで書いたコードは動かせるよね

**デフォルトの名無しさん** · 2023/09/02(土) 14:30:38.26

NimはCにトランスパイルされる

**デフォルトの名無しさん** · 2023/09/02(土) 14:59:18.30

コンパイルする話じゃなくトランスパイルする話をしてるのにその区別すらできないオジ

**デフォルトの名無しさん** · 2023/09/02(土) 15:01:52.18

一般にトランスパイルは同程度に高級な言語の間で
(なるべく)変換後の言語として自然な形で変換するものを言う。

コードジェネレータ、または実行エンジンとして他言語を
経由するものは含んだり含まなかったりするけど
表面上は同じことをやってるので境界が曖昧なんだよ。

**デフォルトの名無しさん** · 2023/09/02(土) 16:08:00.76

境界があいまいだからRustコードからWASMバイナリを生成することをトランスパイルと呼んでもおかしくないと？

**デフォルトの名無しさん** · 2023/09/02(土) 16:25:56.23

>>75
そう呼んで欲しくはないが呼んでるかもしれないという想定で
すり合わせるプロセスは必要かもしれない。

**デフォルトの名無しさん** · 2023/09/02(土) 16:37:50.73

>>65 がトランスパイル先にまでOwnership/Borrow/Lifetimeあたりの機能あったほうが良さそうなこと匂わすトンチンカンなこと書いてるからだろ

**デフォルトの名無しさん** · 2023/09/02(土) 17:46:31.63

>>77
そんな頓珍漢な勘違いをするのはおまえだけだろw

**デフォルトの名無しさん** · 2023/09/02(土) 18:52:34.01

どうせ>>62も複おじなんだろうね

なぜRustからトランスパイルしようなどと思ったのか？
その動機が出ないならこの話は終わりです

**デフォルトの名無しさん** · 2023/09/02(土) 19:16:20.22

>>62です。ぼんやりとした質問ですみませんでした

例えばRustが読めない人向けにPython等に変換してPython読める人ならなんとか読めるものに変換できないかなという想定でした。
あとはLLVM以外の環境で動かしたいとか。それなら確かにWASMで良かったみたいですね。
Rustは型が厳格とかデフォでimmutableだったりムーブだったり制約が強いイメージでしたが前提からして間違ってたみたいですね

皆さま事細かにありがとうございました

**デフォルトの名無しさん** · 2023/09/02(土) 19:32:06.11

だから言っただろうがよ

**デフォルトの名無しさん** · 2023/09/02(土) 19:33:02.08

これは違うな
疑って失礼しました

**デフォルトの名無しさん** · 2023/09/02(土) 19:34:44.69

>>67
お前が勘違いしてんだろガイジ
実行時に所有権やライフタイムは出てこないからこそトランスパイル先の言語にもこれらの機能が言語機能として備える必要がないわけでこのスレでお前だけが1人だけ勘違いしている
頭悪そう

**デフォルトの名無しさん** · 2023/09/02(土) 19:51:23.24

おじ、キレた！！

**デフォルトの名無しさん** · 2023/09/02(土) 20:07:34.22

複数ID全員おじとか糖質患者やろ
お前のたった1人だけの発言の方がすべておじに似つかわしいんやけど自覚できない？

**デフォルトの名無しさん** · 2023/09/02(土) 20:45:16.67

おじ使いはいつも病気

**デフォルトの名無しさん** · 2023/09/02(土) 23:40:40.30

的外れなレス(>>63-64)からの
恥ずかしい壮大な勘違い(>>66)
そしてなぜかドヤる(>>81)

控えめに言って頭オカシイ
さすが複オジ

**デフォルトの名無しさん** · 2023/09/02(土) 23:56:54.98

オジオジ言ってる人は書き込みに中身がなくて全方位叩きだからスレ荒しが目的なのかな
反応せず無視するのがいいんだろうけど反応しちゃった失礼

**デフォルトの名無しさん** · 2023/09/03(日) 00:03:56.01

どうでもいいし面倒だしもうここ潰してﾜｯﾁｮｲありスレに一本化してほしいんだけど

**デフォルトの名無しさん** · 2023/09/03(日) 00:09:50.96

「自演認定は頭おかしい」論法
「おじ連呼厨」の強調

いつものやつですね
自演認定糖質論法は久しぶりに聞いた気がする

**デフォルトの名無しさん** · 2023/09/03(日) 00:16:07.67

ID:bvTG+KAn
ID:g76m2OPt
ID:f2x52juV
ID:GzMi3EqG
ID:x+ZOYO9b
ID:v0MnUUsV

**デフォルトの名無しさん** · 2023/09/03(日) 00:20:28.54

議論でバトルが盛り上がるのは歓迎
オジおじ連投がいる時は議論がなく荒れるだけでつまらん

**デフォルトの名無しさん** · 2023/09/03(日) 00:35:38.11

歓迎するわけねーだろアホか

**デフォルトの名無しさん** · 2023/09/03(日) 00:38:35.94

まともな議論が成り立たない原因は複オジだからね
まともな議論ができそうなのはどう見ても>>65や>>68のほう
>>91にまとめられてるレスを書いてるようなやつが議論は歓迎とか笑わせるな

**デフォルトの名無しさん** · 2023/09/03(日) 00:45:48.36

既視感の正体

https://mevius.5ch.net/test/read.cgi/tech/1673926892/745
https://mevius.5ch.net/test/read.cgi/tech/1652347700/468

**デフォルトの名無しさん** · 2023/09/03(日) 00:53:25.84

>>61
亀レスだが特に理由がないならrusqliteで
今のところはこれがデファクト

**デフォルトの名無しさん** · 2023/09/03(日) 01:20:25.77

気に食わない意見があるけど反論できないで次々とおじさん認定して叩くだけのゲスがいるな

libsqlite3の上に構築したRusqliteでもいいが
Rustで構築したSQLxがSQLiteもサポートするようになり出来が良いので急上昇で逆転する見込み

**デフォルトの名無しさん** · 2023/09/03(日) 01:41:47.18

sqlxのsqliteドライバもlibsqlite3の上に構築されてるぞ
SQLiteはCのAPIしか提供してないんだから他のものを使う理由がない

**デフォルトの名無しさん** · 2023/09/03(日) 07:28:12.23

また知ったかぶりして恥かいてるww

**デフォルトの名無しさん** · 2023/09/03(日) 08:37:05.08

sqlx以外はasync/await使えない？

**デフォルトの名無しさん** · 2023/09/03(日) 13:35:31.95

自分でspawn_blockingすればいい

**デフォルトの名無しさん** · 2023/09/03(日) 13:45:08.16

安定感や性能に差があるのでsqlite限定ならFirefoxでも使ってるrusqliteがベター

**デフォルトの名無しさん** · 2023/09/03(日) 13:48:17.25

■購入目的（達成されました）
・Rustで動くプログラムの写経
・映像表現的な出力結果はモチベーションを維持できる気がした
・RustについてはWeb上に素晴らしいテキストがたくさんあるので簡単な実践的なプログラムを読みたい

■自分のレベル
私は数カ月前にRustを勉強し始めました。
これまで高校でc、Javaの基礎、大学でc++基礎、ObjectiveC、社会人になってPythonやc#と触れてきました。たくさん触れてきていますが結局自分が作りたい少し大きい物をプログラミングで何かを作りきるということをしてきませんでした。いつもチュートリアルで終わりです。永遠に世界に挨拶でもしてろと言われそうなタイプです。

ここ数年で映像制作から転職してインフラエンジニア関係に勤めています。
ネットワークやサーバ周りの知識に加えて一つ言語を修めたいと思いRustをはじめました。

**デフォルトの名無しさん** · 2023/09/03(日) 23:37:22.86

>>101
spawn_blockingは別OSスレッドを立ててそこで実行するだけだから根本的な解決にならない

**デフォルトの名無しさん** · 2023/09/04(月) 01:10:37.74

>>104
別OSスレッドを立ててそこで実行する以外の解決方法はないよ

**デフォルトの名無しさん** · 2023/09/04(月) 02:53:02.64

君たちは何を問題と定義しているのか

**デフォルトの名無しさん** · 2023/09/04(月) 06:58:20.37

昔と違って今はFutureを返すcrateを選べるのだからそこで困ることはないな
糖衣のasync関数を含めてFutureさえ返してくれればいい
自分側はawaitもしくはspawnしてもいいしFutureUnorderedなどで早い者勝ち処理など自由な方針を取れるのだから

**デフォルトの名無しさん** · 2023/09/04(月) 09:56:10.80

>>107
そこで困るとは？

**デフォルトの名無しさん** · 2023/09/04(月) 10:17:13.25

困ってない人は一生気付かない
これが理想郷

**デフォルトの名無しさん** · 2023/09/04(月) 13:01:49.77

いつものストローマンオジ

**デフォルトの名無しさん** · 2023/09/04(月) 18:54:13.07

困ったことが無い香具師には何で困るかわからんマジ

**デフォルトの名無しさん** · 2023/09/04(月) 20:11:06.59

Futureもawaitして同期のみで困っていない人もいる
Futureすら使わず別スレッドにしちゃって困っていない人もいる
ただしベターな方法を知らないために困っていないだけかも知れない
理解した上で選んでいるなら問題ない

**デフォルトの名無しさん** · 2023/09/04(月) 20:41:40.87

>>112
同期APIを非同期で使う話だということを理解してね
何に困ってるのか知らんけど

**デフォルトの名無しさん** · 2023/09/04(月) 20:57:24.92

よく分からんが誰も困っていないらしいのでヨシ！

**デフォルトの名無しさん** · 2023/09/04(月) 21:18:46.15

>>114
俺は誰れが何に困っているのか分からん。　で、>>107は知っているみたいだが
>>100は
>sqlx以外はasync/await使えない？
だから、うん、使えない/いや、xxxも使えるのような回答で良いはずなのに
ITドカタ板に多い障碍者は妄想必死して、変なことを言い出すからな。

**デフォルトの名無しさん** · 2023/09/04(月) 21:28:55.91

>>113
最後の手段spawn_blocking()の話？
あれはスレッドを消費しちゃうから例えばクライアント接続が多数来てそれぞれが使うと詰むよ
全部を非同期APIに統一するのがよいね

**デフォルトの名無しさん** · 2023/09/04(月) 21:58:02.43

そういう状況なら非同期とか言う前にsqliteやめよう複くん！

**デフォルトの名無しさん** · 2023/09/04(月) 22:16:10.47

SQL関係ない一般的な話がされてると思ってたらSQLにこだわる人もいてよくわからんな
SQLにしてもサーバーに繋ぎにいくなら同期はありえんな

**デフォルトの名無しさん** · 2023/09/04(月) 22:29:51.49

>>116
スレッド消費せずにSQLiteへの接続を同時にさばくことが出来ないからね
複オジおすすめのsqlxも当然接続ごとに別OSスレッド立ち上げてるからクライアント接続が多数来たら同じように詰むんだよ