Rust part8

**デフォルトの名無しさん** · 2020/01/24(金) 11:47:52.41

Mozilla発のRust言語のスレ

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

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

前スレ
Rust Part7
http://mevius.5ch.net/test/read.cgi/tech/1563114707/

**デフォルトの名無しさん** · 2020/07/17(金) 00:05:43.64

https://blog.rust-lang.org/2020/07/16/Rust-1.45.0.html

予定通り来た
Rocketがstableの仲間入り

**デフォルトの名無しさん** · 2020/07/17(金) 01:59:14.04

>>863
ありがとう神様

C#ならすぐなのに、
これは理解するのに時間がかかりそうだ。

**デフォルトの名無しさん** · 2020/07/18(土) 18:30:51.49

神がついてるから大丈夫

**デフォルトの名無しさん** · 2020/07/20(月) 13:18:08.21

actix-wevからRocketに移行します

**デフォルトの名無しさん** · 2020/07/21(火) 02:22:25.82

>>867
その理由は？

**デフォルトの名無しさん** · 2020/07/21(火) 18:35:05.91

スライスから差集合を作るの際にスライスをそれぞれhashsetにしてdifference呼ぶ以外で良い書き方ありますか？

**デフォルトの名無しさん** · 2020/07/22(水) 00:13:53.48

それぞれsortして先頭から比較していく

**デフォルトの名無しさん** · 2020/07/22(水) 01:18:16.47

>>869
シンメトリックじゃない単なる差集合なら
片方だけsetにしてもう片方の要素でループしながらチェックするのでもいい気がする
あと状況によってはBroom filterみたいなのを使うと高速化できるかも

**デフォルトの名無しさん** · 2020/07/22(水) 13:33:09.23

fn aaa(s: &str) {
if s == "aaa" {
compile_error!(r"If s is "aaa", compile error!");

}
}
fn main() {
// compile error!
aaa("aaa");
// can compile
aaa("aaaaaaaa");
}

こういう風にコンパイル時にコンパイルエラー出したいんだけど、実際はcompile_error!を書いてる時点でコンパイルになるんだけど回避方法ってないかな

**デフォルトの名無しさん** · 2020/07/22(水) 13:33:41.15

こういう風にコンパイル時にコンパイルエラー出したいんだけど、実際はcompile_error!を書いてる時点でコンパイルになるんだけど回避方法ってないかな
↓
こういう風にコンパイル時にコンパイルエラー出したいんだけど、実際はcompile_error!を書いてる時点でコンパイルエラーになるんだけど回避方法ってないかな

**デフォルトの名無しさん** · 2020/07/22(水) 15:44:52.79

>>870
>>871
㌧

**デフォルトの名無しさん** · 2020/07/22(水) 15:48:48.87

ダブルクォートがaaaの部分で外れてるのが原因とかじゃなくて？

**デフォルトの名無しさん** · 2020/07/22(水) 15:58:57.61

aaa(r#"aaa"iiii"uuuuu"#)

**デフォルトの名無しさん** · 2020/07/22(水) 16:04:28.78

>>875
ごめん。ここに貼る用のデバッグコメ。
そこ直したら本題の条件分岐のコンパイルエラーにならないのがでてくる
compile_error!(r#"If s is "aaa", compile error!"#);

**デフォルトの名無しさん** · 2020/07/22(水) 18:44:16.24

compile_error!は条件付きコンパイルかマクロでしか使えないんじゃ？
compile_error!と記述してる行がコンパイルするコードに含まれることになったらコンパイルエラー

マクロを展開する段階では変数の値を評価できないから
文字列を受け取る関数に対して特定の文字列を渡すコードがあったらコンパイルエラーってのは無理な気がする

**デフォルトの名無しさん** · 2020/07/22(水) 22:19:16.93

aaaを手続きマクロにすればできるとは思うけど。

**デフォルトの名無しさん** · 2020/07/23(木) 01:38:31.65

最近RustのSlackでも出てきた福野泰介ってやつ声でかいよな
こいつどのコミュニティでも何かしら主張して目障りだわ

**デフォルトの名無しさん** · 2020/07/23(木) 01:41:56.15

Ubuntu Japanese Team に言いつけて潰してもらおうぜ

**デフォルトの名無しさん** · 2020/07/23(木) 18:56:28.53

環境はMacOS Catalina, Rustは1.45.0です
今弄ってる物(https://github.com/Nercury/rust-and-opengl-lessons)で
/lib/gl/src/lib.rs内に
include!(concat!(env!("OUT_DIR"), "/binding.rs"));
というのがあるのですがですがcargo buildすると
this error originates in a macro
error: couldn't read /Users/Path/target/debug/build/gl-71effbf83f5b03a9/out/binding.rs: No such file or directory (os error 2)
と表示されます
https://github.com/rust-analyzer/rust-analyzer/issues/1964
https://github.com/rust-skia/rust-skia/issues/10
などを見たのですが具体的な修正がわかりませんでした。
Rustは最近始めたばかりでincludeマクロやcargoの仕組みなどまだあまり詳しくありません
このinclude!を成功させる方法を教えてください
迷惑をかけてしまうかもしれませんがご教授お願いします

**デフォルトの名無しさん** · 2020/07/23(木) 19:05:44.31

福野泰介はたしかにどこでも目立つ。
自己顕示欲もあそこまでいったら面白い、反面教師として役立つ

**デフォルトの名無しさん** · 2020/07/23(木) 21:20:06.43

>>882
lib/gl/build.rsでOUT_DIRにbinding.rsを作成してる

ビルドスクリプトが意図した通りに動いているのか確認するために
build.rsを変更してbinding.rsのフルパスをprintlnでもするようにして
cargo build -vvしてみるといいと思う

ビルドスクリプトについて詳細知りたければこの辺読んで
https://doc.rust-lang.org/cargo/reference/build-script-examples.html

**デフォルトの名無しさん** · 2020/07/24(金) 00:48:59.83

>>884
ありがとうございます動きました！
非常に長文だった自覚はあるんですが分かりやすくすっきりした回答ありがとうございますm(_ _)m

**デフォルトの名無しさん** · 2020/07/24(金) 10:22:52.41

同じサーバー内でポート別にクライアント用サーバー(Nuxt)とAPI用サーバー(Rust)立ち上げるのってどう思う？
クライアント用サーバーは初回しか性能響かないからあれだけど、Rustの方が断然速いし、SPAだからルートの設定も全然しなくていいし、Rustの方でフロントページも返した方がいいんじゃないかと思ってるんだけども
要はRustを実行すればポート別に２つサーバーが立ち上がるようにするってこと

**デフォルトの名無しさん** · 2020/07/25(土) 18:01:19.70

RocketってRust公式サイトにも使われてるのか
迷ったらRocketで良さそうだな

**デフォルトの名無しさん** · 2020/07/26(日) 03:19:09.22

diesel使いづらくない？

**デフォルトの名無しさん** · 2020/07/26(日) 18:57:03.68

rustcの-C llvm-args=が取り得るオプションの説明ってどこかに書いてある？
clangのttps://clang.llvm.org/docs/ClangCommandLineReference.html#x86
あたりがそれっぽいけど説明が全くないのでデフォルト値も効果もよく判らない

**デフォルトの名無しさん** · 2020/07/26(日) 22:31:29.89

>>889
ここに書いてあるけど'--help'を渡せば一覧表示されるみたいよ
https://doc.rust-lang.org/rustc/codegen-options/index.html#llvm-args

$ rustc -C llvm-args='--help'

**デフォルトの名無しさん** · 2020/07/26(日) 23:02:23.88

あるモジュールクラスを別のモジュールで使いたい場合ってどう宣言するのが正しいの？

正直ドキュメント読んでも分からん

**デフォルトの名無しさん** · 2020/07/26(日) 23:58:47.45

>>890
サンキュ。そう使うのかよｗ　うちの環境では
>rustc -C llvm-args=--help　←'を付けると怒られる
でそれっぽいのが得られました。amd64で使用命令を選択するようなオプションは無いのか・・・

**デフォルトの名無しさん** · 2020/07/27(月) 00:46:16.95

--helpの最後に出てたけど
利用可能なオプションを全部表示するには
llvm-args=--help-hiddenってするみたい

**デフォルトの名無しさん** · 2020/07/27(月) 09:47:21.61

chronoのnext_monthないのってどう実現すればできる？

**デフォルトの名無しさん** · 2020/07/27(月) 10:10:01.73

>>894
そもそもnext_monthに何を期待するかによると思うが。30日後？31日後？翌月の同じ日？それが存在しない場合は？とか。その辺がはっきりすれば、その通りに実装すればいい。

**デフォルトの名無しさん** · 2020/07/27(月) 10:18:30.24

翌月の同じ日ならこれかな。
https://docs.rs/chrono/0.4.13/chrono/trait.Datelike.html#tymethod.with_month

**デフォルトの名無しさん** · 2020/07/27(月) 16:16:44.20

>>896
ありがとう、結局next_month自分で実装したけど、かなり頻繁に使われる類のメソッドだから正直きついな
with_monthもoptionで返すから31 -> 30の次月遷移したとしても安全だから実装しない理由が分かんないな
chronoは変なとこには手回ってるしよくわからん

**デフォルトの名無しさん** · 2020/07/27(月) 18:03:20.70

>>897
issueはあるけど別に誰かが反対しているわけでもなく、
単に誰も実装してないだけじゃない？
PR出してみればいいと思うけど。

https://github.com/chronotope/chrono/issues/290

**デフォルトの名無しさん** · 2020/07/28(火) 16:26:39.82

>>891
じけつ

main.rsでそれぞれのモジュールをmod宣言

**デフォルトの名無しさん** · 2020/07/29(水) 11:56:30.09

ed25519の公開鍵のssh-ed25519 ******の部分が欲しくて、ed25519_dalekっていうクレートで鍵作ってるんだけどPublicKey構造体のas_bytesでとってくるバイト列をstr::from_utf8でしてもエラーが出て秘密鍵の***部分にならないんだけど、どうすればいいか分かる？
https://docs.rs/ed25519-dalek/1.0.0-pre.4/ed25519_dalek/struct.PublicKey.html

**デフォルトの名無しさん** · 2020/07/29(水) 20:03:32.01

1byteずつ print!("{:02x}", b) するとかではなく？

**デフォルトの名無しさん** · 2020/07/29(水) 21:31:44.28

>>900
str::from_utf8でエラーになるのは
0~127までのUTF-8互換のASCII以外の文字が含まれてるからでは？

pemで見れる公開鍵のssh-ed25519 ******の部分は
keyの種別とDERエンコードしたkeyの値をBase64にしたものらしい

**デフォルトの名無しさん** · 2020/07/30(木) 13:54:57.65

>>901
やってみたらエラーはでないし、ハッシュっぽいものできたけど、大文字ないから >>902の方法っぽいかも
4ef6dcfda191770b64939c5657fc26e631c2caffa18e423c397d761d507ae82a%

>>902
ありがとう、やってみるわ

**デフォルトの名無しさん** · 2020/07/31(金) 22:54:06.06

bindgenにwindowsはllvmのプリビルドバイナリをインストールしなさいと書いてあるけど、
LIBCLANG_PATH設定し忘れるとwinのプリビルドバイナリには含まれてないllvm-configを使って<LLVM_ROOT>/binまでのパスを探すんで
llvm-configがないって怒られる罠がある。

LIBCLANG_PATHタイポして時間潰してしまった。

**デフォルトの名無しさん** · 2020/08/01(土) 14:02:57.08

やっぱactixよりrocketだな

**デフォルトの名無しさん** · 2020/08/01(土) 14:09:11.29

>>905
その理由は？

**デフォルトの名無しさん** · 2020/08/01(土) 15:02:20.03

なんか速そうじゃん

**デフォルトの名無しさん** · 2020/08/01(土) 15:19:22.53

>>906
ドキュメントがしっかりしてそう

**デフォルトの名無しさん** · 2020/08/01(土) 16:43:51.04

unsafeの個数が少ない方が勝ちって事でいいんじゃない？

**デフォルトの名無しさん** · 2020/08/01(土) 22:13:51.53

rocketってmultipartサポートしてないのか

**小石茶輝** · 2020/08/01(土) 23:31:58.80

unsafe という機能があるのは unsafe が必要だからです。
設計方針に対して必要以上に unsafe があるのはダメですが、
少なければ少ないほど良いというわけでもありません。

たとえば C++ を使っているときだって、
グラフィックドライバを書くときとかは
どうしたって (C++ 的には) 行儀の悪い書き方になってしまうでしょう。

行儀の悪い部分はなるべく低レイヤに押し込めて、
ロジック層が綺麗になるようにするのが望ましいなどといった習慣はありますが、
どの程度にするかの程度問題は設計方針によります。

actix は rocket よりも unsafe を多用してはいますが、
意図のはっきりした unsafe です。

あまりにも unsafe が多すぎるならもう Rust 使うのやめろよと思うかもしれませんが、
行儀の悪い書き方 (unsafe) がより明示的であるというだけでも
C++ よりは少しマシでしょう。

**デフォルトの名無しさん** · 2020/08/06(木) 21:31:08.70

rust案件が出てこないのは何で？

**小石茶輝** · 2020/08/06(木) 23:35:19.16

出てますよ。
あなたがそれをキャッチする立場にないだけです。

**デフォルトの名無しさん** · 2020/08/08(土) 01:19:04.76

stdの中でこれは外部ライブラリにした方がいいんじゃないかなって思うやつある？
逆に外部ライブラリからstdにした方がいいんじゃないかってやつとかもある？

**デフォルトの名無しさん** · 2020/08/08(土) 06:00:59.71

>>914
乱数ライブラリが標準ライブラリに入ってない言語とか他にあんの？

**デフォルトの名無しさん** · 2020/08/09(日) 00:20:40.65

乱数は用途によって必要な性質が色々だからなぁ。
どの分野を優遇すべきかってのは自明ではないでしょ。
全部盛りにするのも Rust 的ではないし。

でも、どの乱数ライブラリを使うにしても同じようなインターフェイスだとありがたいので、
乱数ライブラリが満たすべき標準的なトレイトが提供されて欲しいし、
そのサンプル的な位置づけでひとつくらいは乱数ライブラリが入っていてもいいかなとは思う。

◆QZaw55cn4c · 2020/08/09(日) 00:37:01.23

>>916
MT だけでいいと思うのですが

**はちみつ餃子** ◆8X2XSCHEME · 2020/08/09(日) 00:43:58.48

>>917
メルセンヌツイスタは統計的な性質は良いけど暗号的には使い物にならんしデカい。
常にベストと言えるほど良い選択ではないよ。

◆QZaw55cn4c · 2020/08/09(日) 01:29:16.04

>>918
確かに暗号にMTを使うのはダメですね、暗号用には crypt-MT がありますね

**デフォルトの名無しさん** · 2020/08/09(日) 20:40:18.77

今はもうMTもそこまで・・・って話じゃないっけ
randクレート見るとそんなこと書いてあったような

**デフォルトの名無しさん** · 2020/08/09(日) 20:55:04.69

他の言語だって完璧な乱数だと思ってなくても
利用者の利便性を考えて標準ライブラリに含めてるんだろ
それが無いRustは変

**デフォルトの名無しさん** · 2020/08/10(月) 00:22:38.94

今どきMT法なんか使わん。

>乱数ライブラリが満たすべき標準的なトレイトが提供されて欲しいし、
rand_coreがそれに当たるけどcoreだけだとバイト配列しか取得できんので分布器に生成器渡せん。
未知の生成器の実装すべて含めるのは無理、既知のものに絞っても要求する特性が人によって違うから標準にするのは無理。
結局はこうなるが、俺も標準ライブラリに乱数ほしい。

**デフォルトの名無しさん** · 2020/08/10(月) 01:32:59.38

cargo使ってるから別ライブラリでもあまり困らない
こと乱数に関してはデファクトスタンダードのcraete決まってるし迷うことないしね
標準ライブラリに入ってて欲しいのは初学者がcrate知らないとか探すのが手間だとか、コンパイルタイムが延びるのが嫌だとか、そういう理由？

**デフォルトの名無しさん** · 2020/08/10(月) 02:16:28.69

stdに入れて欲しいのはrandよりregexだな
標準ライブラリとして責任もってメンテされていくものなのかどうかが重要

**デフォルトの名無しさん** · 2020/08/10(月) 03:21:04.11

>>924
あちこちのcrateでregex使ってるから
コンパイル遅くする原因になってるわ

**デフォルトの名無しさん** · 2020/08/10(月) 04:22:44.62

Authors のところが The Rust Project Developers ってなってるやつは
事実上の標準みたいなもんと思ってええんけ？
将来の互換性が保証されるかどうかはともかくとして Rust と足並みがそろっているとは
思っていいよね？

**デフォルトの名無しさん** · 2020/08/10(月) 05:17:58.40

jsonrpc使ってみた。不可解な実装でワロタ

**デフォルトの名無しさん** · 2020/08/10(月) 23:12:44.03

外に出されたunicode系ライブラリが更新止まってていつかstdがサポートするunicodeのバージョンと互換性失うんじゃないかと思う。

>>926
事実上の標準っていうかc++のboostみたいなもんだけど足並み揃ってるかは別。

**デフォルトの名無しさん** · 2020/08/11(火) 13:18:54.05

use std::ops::{Rem, AddAssign};
pub fn get_days_of_month<T: Rem>(year: T, month: u32) -> u32 {
match month {
2 => if is_leap_year(year) { 29 } else { 28 },
4 | 6 | 9 | 11 => 30,
_ => 31,
}
}
pub fn is_leap_year<T: Rem>(year: T) -> bool {
match ((year % 100 as T) as i32, (year % 400 as T) as i32) {
(_, 0) => true,
(0, _) => false,
_ => year % 4 == 0,
}
}
pub fn next_day<N, T: AddAssign + Rem>(mut year: T, mut month: u32, mut day: u32) -> (T, u32, u32) {
let days_of_month = get_days_of_month(year, month);
day += 1;
if day > days_of_month {
month += 1;
day = 1;
}
if month > 12 {
year += 1;
month = 1;
}
(year, month, day)
}
non-primitive castエラーが出るんだけどどうすれば解決できる？
1 as Tでもできないし、1.parse()はstrじゃないから出来ない

**デフォルトの名無しさん** · 2020/08/11(火) 13:40:48.45

>>929
num-traitsのOneで制約すればT::one()でT型の1が得られる。

**デフォルトの名無しさん** · 2020/08/11(火) 17:18:59.34

>>930
i32 か u32を受け取るトレイト境界ってつくれない？
あとAdd<u32> for u64とかの実装していない理由とかって何？

**デフォルトの名無しさん** · 2020/08/11(火) 18:03:39.15

>>931
自分で作ればいい。
型変換は明示的にしろ、ってことだろう。

**デフォルトの名無しさん** · 2020/08/13(木) 18:54:36.47

ゲーム開発言語はrustに移行されるかな？

**デフォルトの名無しさん** · 2020/08/13(木) 23:00:02.19

プログラミング言語「Rust」、Linuxカーネルでの採用の道を模索
https://japan.zdnet.com/article/35157012/

**デフォルトの名無しさん** · 2020/08/14(金) 22:24:07.75

>>933
個人の開発に使ってるけどバインディングだらけになる。
ミドルウェア1から作る新規開発くらいじゃないとrustの恩恵がフルに受けられないと思う。
あと、コンパイル遅いのが辛い。

**デフォルトの名無しさん** · 2020/08/15(土) 03:05:14.85

ラズパイとかでコンパイルすると糞遅いのなんとかならんかな

**デフォルトの名無しさん** · 2020/08/15(土) 06:26:45.05

禁断のCPU換装とかないの？
DOS/Vパワーリポートとか買ってみたら。

**デフォルトの名無しさん** · 2020/08/15(土) 06:47:50.15

>>936
クロスコンパイルすれば？

**デフォルトの名無しさん** · 2020/08/15(土) 21:53:54.93

というよりなんでセルフコンパイルするんや？

**デフォルトの名無しさん** · 2020/08/15(土) 23:19:51.01

rustじゃないけど適当な設定で大きいライブラリビルドしたら過熱でラズパイ落ちた事あるわ

**デフォルトの名無しさん** · 2020/08/17(月) 18:33:01.49

Rより低いRust...
https://japan.zdnet.com/article/35158190/

**デフォルトの名無しさん** · 2020/08/18(火) 04:18:41.28

rustって日本で人気という勝手なイメージがあるけど世界的にはどうなんだろ

**デフォルトの名無しさん** · 2020/08/18(火) 04:32:12.17

ルスト？なにそれ？てかそんなの聞いた事ないんだけど

**デフォルトの名無しさん** · 2020/08/18(火) 15:54:29.74

>>941
Goの方がマスコットがかわいいからしゃーない。

**デフォルトの名無しさん** · 2020/08/18(火) 16:39:58.87

マスコットが気持ち悪い言語と言えばLISP

**デフォルトの名無しさん** · 2020/08/18(火) 18:04:09.30

>>944
いやいやいやいy・・かわいいかアレ？？
どぉおおおおおみてもキモい

**デフォルトの名無しさん** · 2020/08/18(火) 18:17:07.57

>>941
調査によって、まちまちだな。
StackOverflowでは、Rustは好きな言語ランキングでは、五年連続Topらしいが、
「人気」は低い。
今のところ「好き」だが「人気」は無いのがRust。
恐らくこの場合、「人気」= 「Popular」のことで、英語の Poluarは、
「人気」と言う意味のほかに、「普及している」とか「一般的」、というような
意味もあるのでややこしい:
https://news.mynavi.jp/article/20190412-807191/

**デフォルトの名無しさん** · 2020/08/18(火) 18:30:54.90

「好き」ならば「学びたい」のだろう、と思いきや、そうでもないということか。
「最も好きな言語は何ですか？」
という問に対して、相手に馬鹿にされないためには、Rustが丁度よい言語
である気はする。
でも、結構、実際に使用したいと思っているどうかは別。
俺もそんな質問されたら、答えに窮して Rust と答えてしまうかも知れんが、
使う気はほぼ無い。

**デフォルトの名無しさん** · 2020/08/18(火) 21:58:33.67

Rustはターゲットになる開発領域が狭くてどう足掻いても大人気誰も彼もRust!なんてことにはならないよ

C++が広範な領域で使われてたのは選択肢のなさとWinのAPI基準の1つなのとCとの運用のしやすさ

選択肢が増えてWinもよっぽどなことしなけりゃC#があるしCをコールする分にはどの言語も十分改善されてきた

0から作るある程度のパフォーマンスを求めるプロダクトならGoがあって、アセンブリと連携するけどcgoのオーバーヘッドやGCのオーバーヘッドが気になるみたいな際際じゃなけりゃRustにならない

計算高速化のcalleeとしては安全性があまり旨味のない要素だからC++の選択がまだ強い

以上に加えてエラー周りとかアセンブリ連携もnightlyがあってまだ熟してない部分があり厳しい立ち位置にいるという認識だ

◆QZaw55cn4c · 2020/08/18(火) 22:03:32.42

>>949
＞計算高速化のcalleeとしては安全性があまり旨味のない要素だからC++の選択
C++ が呼ばれ側になるのですか？

**デフォルトの名無しさん** · 2020/08/18(火) 22:21:20.07

>>949
その中だとパフォーマンス的にはGoでいいけど言語仕様が簡素すぎて辛い、みたいな層の受け皿としてRustが使われてるケースはありそうかな。
ScalaがいいけどJVMは厳しい、みたいなのとかも。
まぁニッチなのは間違いない。

**デフォルトの名無しさん** · 2020/08/18(火) 22:56:18.34

Microsoftが興味持ってるからC# + Rustが未来の姿だ
UIはC#

**デフォルトの名無しさん** · 2020/08/18(火) 23:14:15.49

>>950
TensorflowとかPytorchのバックはC++だよね
これらは当然CUDAとの兼ね合いであるのは間違いないけど、CUDA側がRustではなくC++を選択してる意図として安全性の旨味のなさは間違ってないと思う
C++の仕様が先立つ言語であることや人口の多さ、既存資産との兼ね合いの比重のが大きいだろうけどね

**デフォルトの名無しさん** · 2020/08/18(火) 23:33:09.98

>>953
そりゃCUDA1.0の頃（もう10年以上前だぞ）にRustなんて影も形もなかったんだから選択されないのは当然だろう。
その視点で見るならここ1-2年で開発開始されるプロジェクトでどの程度採用されるか、では？
今だとブロックチェーン界隈とかかね。

**デフォルトの名無しさん** · 2020/08/19(水) 01:11:27.31

>>949
rustは元からサーバーは視野に入れてないだろ

**デフォルトの名無しさん** · 2020/08/19(水) 03:59:31.08

"abc".split("").collect::<Vec<_>>()は["", "a", "b", "c", ""]になるんだけど、うまく空白なしでスプリットでできない？

**デフォルトの名無しさん** · 2020/08/19(水) 04:27:22.19

.charsじゃなくてどうしても.split使ってvecにしたいってことなのか？

**デフォルトの名無しさん** · 2020/08/19(水) 04:32:39.30

"abc".split_terminator("").skip(1).collect::<Vec<_>>();でできるけど
普通はchars使うやろ

**デフォルトの名無しさん** · 2020/08/19(水) 10:35:25.48

>>957
charだとparse()がなくて変換めんどくさい
あと容量無駄

**デフォルトの名無しさん** · 2020/08/19(水) 10:42:04.16

charと&strって&strのがでかくね？？？？

**デフォルトの名無しさん** · 2020/08/19(水) 10:54:53.71

>>960
Splitは
type Item = &'a str
だから無駄に生成しないって意味ね

**デフォルトの名無しさん** · 2020/08/19(水) 11:03:27.99

>>961
でも最後にVecに格納するポインタは一文字ごとに8バイト取られるんだから、charの方が小さくない？

**デフォルトの名無しさん** · 2020/08/19(水) 12:52:58.21

&strはfat pointerだから16byte じゃね