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/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 じゃね

**デフォルトの名無しさん** · 2020/08/19(水) 13:05:48.82

確かに16バイトだね。parseにしてもto_digitでいいし、Vec<&str>のメリットはなさそう。

**デフォルトの名無しさん** · 2020/08/19(水) 14:18:38.67

Rustのコア開発者達がMozillaのリストラで大量解雇されたようだが大丈夫なのか？

**デフォルトの名無しさん** · 2020/08/19(水) 14:44:59.88

MozillaとRust Core Team、Rustの非営利団体を立ち上げへ
https://mag.osdn.jp/20/08/20/104100

Mozillaのプログラミング言語「Rust」を開発するRust Core TeamとMozillaは8月18日、独自の非営利団体を立ち上げることを発表した。Mozillaの大規模なリストラ計画を受け、Rustプロジェクトの安定を図る。

Mozillaは約250人規模の人員解雇計画を明らかにしているが、この中にはRustプロジェクトやコミュニティにアクティブに参加しているメンバーも含まれるという。
この再編計画がプロジェクトとしてのRustに対する不確実性を生んでいることから、非営利団体立ち上げを急ピッチで進めることにしたようだ。

なおRustにはMozilla外部からの貢献も多く、Mozilla内部の開発者の多くも余暇を使って参加しているため、Mozillaの再編計画によりプロジェクトが大きな影響を受けることはないとしている。

**デフォルトの名無しさん** · 2020/08/19(水) 15:18:50.67

解雇された人のtwitterとか見てると
「弊社でRust書きませんか？」なオファーが殺到って感じだし
個人の生活としてはそんなに問題ないんじゃないかな。
Rustの開発に割ける時間が増えるのか減るのかは知らんが。

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

Rust財団作って開発と管理を移管するのかね

その後プラチナスポンサーにMicrosoftがいても驚きはないな

**デフォルトの名無しさん** · 2020/08/19(水) 18:13:15.60

非営利団体を立ち上げるらしいですね、安心安心

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

>>966の記事でも触れてるけどrustはコントリビュータが多いからmozillaの再編は影響すくない。
mozillaの中のままでmozillaの計画の影響受けたら面倒くさいからこの際独立しようって考えだろうね。

といかMozillaのはアフターコロナを見据えた再計画なんでアメリカにしてはコロナに関してはまともな部類なんだけど国内でどう見られるかだね。

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

Servo開発者が解雇されるみたいだね

**デフォルトの名無しさん** · 2020/08/20(木) 01:56:33.75

僕も解雇されてニートになったんで暇つぶしにRust始めようかと思うんですがRustって個人の趣味として使うならナンセンスなんですか？
WinのGUI開発しようと思ってるんですがあんまり情報ないですよね

**デフォルトの名無しさん** · 2020/08/20(木) 07:40:13.19

その用途なら素直にC#使えば？

**デフォルトの名無しさん** · 2020/08/20(木) 11:28:50.60

Xamarinより糞なものが完成するだろう

**デフォルトの名無しさん** · 2020/08/20(木) 13:10:46.32

趣味なら好きなもの興味のあるものつかえばええ

**デフォルトの名無しさん** · 2020/08/20(木) 14:37:00.37

PythonとJSをちょっと書けるくらいなんですが
Rustを勉強する前にCをやったほうがいいですか？

**デフォルトの名無しさん** · 2020/08/20(木) 16:14:06.53

時間の無駄だからやらないでいいよ

**デフォルトの名無しさん** · 2020/08/20(木) 16:38:36.44

人生なんて生きてる間の暇潰しだろ

**デフォルトの名無しさん** · 2020/08/20(木) 17:19:36.86

川上さんが同じこと言ってた

**デフォルトの名無しさん** · 2020/08/20(木) 18:34:28.31

>>976
一度Cを書かないとRustのありがたみの半分が理解できないよ

**デフォルトの名無しさん** · 2020/08/20(木) 21:01:28.94

そんなことはない
やらなくていい

**デフォルトの名無しさん** · 2020/08/20(木) 22:00:49.47

世の中にはドキュメントを読んで納得できるタイプの人と
実際に自分で罠にはまってみないと納得できないタイプの人がいる。
自分が後者だと思うなら一度Cで苦しむのがいいんじゃないかな。そうじゃないなら不要。

**デフォルトの名無しさん** · 2020/08/21(金) 00:12:22.78

だいたいドキュメントを鵜呑みにして罠にはまる

**デフォルトの名無しさん** · 2020/08/21(金) 03:22:09.47

RustってC/C++の代替って言うけどそもそも今時Cって使う？
趣味で使ってる言語の1位がRustだって記事もあったけどCで何作るの？
なんでRustがこんなに人気なのか理解できない

**デフォルトの名無しさん** · 2020/08/21(金) 10:06:09.07

Linuxの基本的なコマンド(ls,grep等)を高機能にした代替コマンドがよくRustで作られてる

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

>>984
よく勘違いされることであるが、Cが昔から使いこなせている人は、Rustでなくても、
特に問題を感じていなかったりする。

**デフォルトの名無しさん** · 2020/08/21(金) 18:48:37.51

よく勘違いされることであるが、Cが昔から使いこなせてると思ってる人は、
単にバグに気付いてないだけだったりする。

真面目な話、組み込み系のシニアエンジニアにありがち。
オフラインの家電やってる頃は良かったんだろうけど、
ネットに接続とかやるとたいていやらかす。

**デフォルトの名無しさん** · 2020/08/21(金) 20:12:18.80

Cでマルチスレッド書けって言われてもバグる自信しか無いわ
C製ツールをRustで書き直したものはマルチスレッド化して高速化してるわけだしな

**デフォルトの名無しさん** · 2020/08/21(金) 20:57:32.34

LinuxカーネルハッカーというCの超ベテランからも
LinuxにRustも使いたいという話が出るくらい

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

C使えるけど気苦労多いしRustの方が良い
Cを積極的に使う理由は少ない

**デフォルトの名無しさん** · 2020/08/21(金) 21:20:19.48

単に文字列扱うだけでめんどくさくなって
「仕様削ってintにしていい？」と言いたくなるのがC

**デフォルトの名無しさん** · 2020/08/21(金) 22:15:47.76

>>984
rustを評価する際にC/C++の代替なんて誰も言ってないよな。mozillaも評価いいMSとかも。
C++より安全って言ってるのを外野がC/C++の代替と言い出したのが
ろくにrust書いてない連中が呪文のように唱えだしただけだと思う。
C++の代替になってもCの代替にはならないと思う。

>>991
早くuchar.hを自分で用意する作業に戻るんだ！

**デフォルトの名無しさん** · 2020/08/21(金) 22:26:40.07

逆にCの代替になる必要はないと思う
CとのFFIは不自由なくできるわけで
むしろFFIが不自由なC++の代替にはなりづらいと思う