0001デフォルトの名無しさん2024/02/23(金) 17:37:52.13ID:CheDQupm
>>772
自動変換が本当に意味不明ならここまでの話が見えてないとしか言いようがない 自動変換とかそんなアホなこと言ってるのはあんただけやで
そんなものは無いし必要ない
こいつOsStringの概念が分かってないのか
本当に知能レベルが低すぎる
OsStringはOSから渡されたバイト列をそのまま格納するだけで
EUC-JP環境ならEUC-JPバイト列がそのまま入るし何も変換されたりしないが…
想像力が欠如しているか頭がおかしいか指示待ち人間だからそういう幼稚なレスになる
結局内部で使う場合は簡単にutf8に変換してる
なにからutf8に変化するか指示も必要がない
ただのボイラープレート
>>777
自動変換なんてものはない
むしろ自動変換を避けるために用意されているのがOsString
もちろん自動変換は行われない 人間じゃなくて壊れたロボットに話しているようだな
いくつになろうとこんなダメな人間になってはいけないな
ぼきのかんがえたさいきょうのげんごにはstring<encoding>とchar<encoding>があって
どんなエンコーディングの文字列でも統一的に扱うことができましゅ
Rustもまだまだでしゅね
ほとんどの環境がWebも含めてUTF8に統一となったからRustのstr/String内部表現がUTF8であるのは合理的といえる
もちろんWebでもローカルファイルでも古いものは様々な文字コードが使われているため必要なら各々で対処する必要がある
文字コードをUTF-8とか特定のものに決め打ちにしないという点ではRubyが一番先進的だったが、あれはやりすぎで以降の言語には採用されなかったな。
めちゃくちゃ間違ってるのになぜ上から目線で自信満々にレスするんだろう？
複オジは昔の自分を諭してる気分じゃないか？
0787デフォルトの名無しさん2024/04/25(木) 01:24:12.71ID:fpMjozoS
>>0774
お前の着眼点は凄えよ！感動した。
その通り、Rustは初心者/素人 御用達言語だよ。
おじいちゃん誰にも相手にされず寂しくなったんだねw
0789デフォルトの名無しさん2024/04/27(土) 03:20:12.65ID:nhA0znD3
0790デフォルトの名無しさん2024/04/27(土) 21:28:13.67ID:+PotGQRe
crates.io が死んだときはどうすれば良い？
0793デフォルトの名無しさん2024/04/29(月) 14:17:37.62ID:wZNa4EA4
5chが荒らされてる時はどうすれば良い？
0794デフォルトの名無しさん2024/04/29(月) 16:10:30.59ID:E9KMHG2x
取り敢えずアゲとけばいいんじゃね？
0796デフォルトの名無しさん2024/04/30(火) 03:09:09.37ID:LM/x1iE2
落ち着いてpanicしよう
python みたいに何でも格納できる辞書型ってC++には無いよね？
anyとmap組み合わせればいいんじゃね？
ここRustスレだけど
Rustで辞書型はHashMap
複数の型を格納したかったらenumかdyn Trait
TraitをAnyにするならdowncastして使う
実際には共通に処理したい目的があるはずなのでそのTraitを用意すればdowncastしなくて済む
pythonみたいにだからclassがわりなのかも
p["name"]="yamada taro";
p["age"]=25;
みたいなのかな
いずれにしてもC++じゃないので
静的型付けの有用性が大きく上回るから
そのケースならstructにするだろうし
色んな型を横断的に扱いたいケースならtraitかな
GUI付きのポータブルなデスクトップアプリを作るとなるとどのライブラリがいいんだろ？
UIはもうネイティブにこだわらなくてもいいんじゃないかな
昔からwebでしかUI提供してないソフトはゴロゴロある
用途次第
WebベースのUIでは反応速度が遅すぎる場合もあるしサイズが許容できない場合もある
Tauri は各環境の WebView を使うからアプリケーションの側では管理しなくてよくなり楽……
みたいな言説もあるが、 WebView の種類・バージョンを固定できないから変化に追従する必要が生じる。
そもそもウェブの世界は変遷が激しい。
Living Standard ってなんやねん。 普通の産業の感覚では信じられんようなことをしやがる。
元からウェブ系のスキルセットを持っている人が開発してメンテナンスもするってのなら
Tauri は良い選択肢だと思うが、それなりにデメリットもあるよ。
ただ、多言語 (というか Unicode) に隅々まで対応しているようなフレームワークってことになると
ウェブ系の基盤がめちゃくちゃ整備されているのでそこらへんは唯一無二だわ。
即応性が必要な人は特殊な学習を手間暇というか単純に時間をかけてやって
そうでない場合は普通にhtmlで
実行時のメモリ使用量の違いもかなり大きいから最初に考慮しといた方がいい
常駐の軽いアプリを作りたい場合なんかは特に
UI を記述するためのものとしては html は「普通」じゃないってことをウェブ系の人は思い出して欲しい。
元はドキュメント記述用だったのに html5 から大幅に路線変更してアプリケーション基盤として再編したけどどう見たって無茶苦茶だ。
ウェブの人が使う分にはこれでいいことは否定しないけど、 UI 記述の「普通」ではない。
UI記述は宣言的なものが主流になりつつあってhtml的なものが「普通」になってきてるんだよ
MFCやCocoaやGTK的なものが今では逆に「普通」ではない
>>813
宣言的がどうこうとかいう問題ではなく html が「普通」ではないと述べてる。
これが良いとか悪いとか言ってるわけではないよ。
まず第一に選ぶべき「普通」だとする論を否定してる。 何気にslintと書いてみたが紹介動画見る限りvs codeにアドオン入れてライブプレビューしながらuiの構築がサクサク行えるのは割といいな…
tauriは環境構築する段階でnodeのバージョンやら依存ライブラリの不備でエラーがでてしまい結構時間が掛かってしまった
デスクトップアプリのここにグラフ出してくださいって言われて
対応できる環境は少ない
0819デフォルトの名無しさん2024/05/04(土) 19:49:33.93ID:kEH6RwVz
他にいい表現方法があるなら自分で作って使ってりゃいいじゃん
0822デフォルトの名無しさん2024/05/05(日) 10:17:39.98ID:k5d9I+SK
>>821
Elm Architectureの設計パターンを覚える必要があるけどなかなかいいですね 試してみたけど導入のカウンタの例がいきなりビルド出来ない…
バージョンの変更にドキュメントが追いついていないのは残念ですね…