結局C++とRustってどっちが良いの？ 6traits

**デフォルトの名無しさん** · 2023/07/29(土) 15:05:46.55

C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

前スレ　
https://itest.5ch.net/mevius/test/read.cgi/tech/1688129795

関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.n...cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/08/20(日) 16:51:39.65

>>738
CPU以外にボトルネックがないならおおよそ並列度の分だけ性能上がる
32bit + 32bitのような計算を1命令で処理してたところを256bit幅がサポートされてるハードウエア&命令を使えば約8倍

**デフォルトの名無しさん** · 2023/08/20(日) 16:54:56.78

>>739
実際には、「お膳立て」のためのオーバーヘッドが有ることと、
SIMD命令が使える部分が少ないことで、8倍のSIMD命令を
使っても、20%位の向上にしかならないと言われている。
数値は大体。
だから、IntelはAVX512をメインストリームからは捨て
ようとした。

**デフォルトの名無しさん** · 2023/08/20(日) 17:01:04.61

スパコンが、ベクトル型が廃れてスカラー型の並列型が
流行していることからしても、SIMDは将来性の無い
ものだと個人的には思ってる。
むしろ、SIMDを捨て、コア数を増やす方が圧倒的に
高速化できる。

**デフォルトの名無しさん** · 2023/08/20(日) 17:20:33.01

スパコンのコーディングは知らんけど
雑にスレッドプールにぶん投げるだけで速くなる並列処理の方が
SIMDより使いやすいなって思う

**デフォルトの名無しさん** · 2023/08/20(日) 18:05:27.72

>>720
整理するとこれでいいみたい

use std::error::Error;
use std::net::TcpStream;
use std::io::{BufReader, BufRead, Read, Write};
use std::fmt::Write as _;

fn http_get(host_port: &str, path: &str) -> Result<Vec<u8>, Box<dyn Error>> {
　let mut server = TcpStream::connect(host_port)?;
　let mut http = String::new();
　write!(http, "GET {path} HTTP/1.1\r\n")?;
　write!(http, "Host: {host_port}\r\n")?;
　write!(http, "Connection: close\r\n")?;
　write!(http, "\r\n")?;
　server.write_all(http.as_bytes())?;

　let mut server = BufReader::new(server);
　let mut line = String::new();
　server.read_line(&mut line)?;
　if line != "HTTP/1.1 200 OK\r\n" {
　　return Err("HTTP: not 200 OK".into());
　}
　while server.read_line(&mut line)? > 2 {}

　let mut data = Vec::<u8>::new();
　server.read_to_end(&mut data)?;
　Ok(data)
}

**デフォルトの名無しさん** · 2023/08/20(日) 18:11:30.48

よかったね

**デフォルトの名無しさん** · 2023/08/20(日) 18:25:00.43

>>743
え？Rustって標準ライブラリでhttpリクエストすらできないの？

**デフォルトの名無しさん** · 2023/08/20(日) 18:38:37.77

Rsutはwebやるための言語とか言ってたような

**デフォルトの名無しさん** · 2023/08/20(日) 19:01:10.42

とりあえず1000×1000の行列の行列積dotが0.015秒弱でできるようなところまで行列ライブラリーが実装できたので、何とか0.00秒台で計算が終わる様にしたい。
今の所手を出してない最適化
1) Simd命令
2) インラインアセンブリ
3)ループアンローリング(これはRustだと自動的にやってくれてる様で自分の実験した範囲ではあまり効果がなかった。)

この中で一番効果的な最適化は何？
ちなみに今の所は以下の最適下は既に実装済み
1) ループ交換
2) キャッシュブロッキング
3) rayonによる並列処理

**デフォルトの名無しさん** · 2023/08/20(日) 19:10:25.82

>>745
Rustの標準ライブラリは言語サポートを必要とするものを中心に極めて絞っている
既出のhttpやbase64だけでなく正規表現や乱数など多くの機能がデファクトスタンダードライブラリ

>>746
標準ライブラリにないだけで各種ライブラリは下位から上位フレームワークまで揃っている
CPUとメモリのリソースコスパ重視でWebやるならRust一択でまちがいない
Webインフラ各トップ企業たちも>>496のようにRustを採用している

**デフォルトの名無しさん** · 2023/08/20(日) 19:16:55.65

デファクトスタンダードという選りすぐりに聞こえるが
単にそれしかないだけのような...
ユーザ数少ないので

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

>>747
simdに手を出すとarmのsimdまでやる羽目になる
インラインアセンブリも同じ

つまり今のところおすすめはない
外部のライブラリなどに依存するなら別だけど

**デフォルトの名無しさん** · 2023/08/20(日) 19:25:32.14

>>750
じゃあ基本的にはdot演算に関してはこれ以上の最適化の余地はないって感じ？

**デフォルトの名無しさん** · 2023/08/20(日) 19:26:47.41

グーグルとアップルが流行らせようとしてるらしいが

**デフォルトの名無しさん** · 2023/08/20(日) 19:44:59.22

paiza.io の Rust は crates 使えないから
ホント使いもんにならんわ

**デフォルトの名無しさん** · 2023/08/20(日) 19:47:42.13

じゃあGitHubのCodespacesでも使ってれば

**デフォルトの名無しさん** · 2023/08/20(日) 19:54:55.65

>>751
おすすめはしないけどやればやったになるはず
デバッグ環境があるかは知らないが

**デフォルトの名無しさん** · 2023/08/20(日) 19:58:02.59

>>753
それはpaizaが悪い
例えば>>712で意味のない比較をしているが
Python版はimport requestsと標準ライブラリではないものを使っている
つまりpaizaはPythonだと標準ライブラリ以外のライブラリも使える
同じようにRustでも標準ライブラリ以外を使えるようにpaizaが対応すれば解決

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

>>747
これに即して測ってみては(1500x1500(f64)の生成、行列積、破棄の計測)
https://github.com/kostya/benchmarks#matmul

とりあえずnumpyとの比較とか
https://github.com/kostya/benchmarks/blob/master/matmul/matmul-numpy.py

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

シミュレータなどは行列演算だけ高速化しても、全体の
高速化にはなら無い事が多い。

**デフォルトの名無しさん** · 2023/08/20(日) 20:04:56.81

>>757
手元のnumpyよりは少なくとも1000×1000の行列積は2倍から3倍速、10000×10000の行列積だと約5倍から10倍速い。手元よnumpyのバックエンドはIntelMKL。

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

まだ、行列の対角化とか逆行列の計算は実装できてない。

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

なんかnumpyが遅くない？

1000x1000でnumpy.dot(a, b)部分だけ測ったらこんな感じだったけど

0.006215572357177734
0.005822658538818359
0.005129098892211914
0.007399797439575195
0.011432886123657227
0.008414506912231445
0.009572029113769531
0.009091615676879883
0.008922100067138672
0.007265329360961914

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

def calc(n):
n = n // 2 * 2
a = build_matrix_np(n, 1.0)
b = build_matrix_np(n, 2.0)

start = time.time()
d = matmul(a, b)
end = time.time()
time_diff = end - start
print(time_diff)

return d[n // 2][n // 2]

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

pipで入れたのでopenblasだと思うけど、こんな感じ

OMP_NUM_THREADS=1 python mutmul-numpy.py 1000
0.030291080474853516
0.029540538787841797
0.029771089553833008
0.02943873405456543
0.02980208396911621
0.03012990951538086
0.0300595760345459
0.030525922775268555
0.03243899345397949
0.02984023094177246

OMP_NUM_THREADS=8 python mutmul-numpy.py 1000
0.0073316097259521484
0.007174968719482422
0.007193326950073242
0.006682157516479492
0.006906747817993164
0.006983757019042969
0.007711172103881836
0.008562803268432617
0.007740497589111328
0.00671076774597168

>>759のnumpy計測がsingle threadになってたりしてる？

**デフォルトの名無しさん** · 2023/08/20(日) 22:44:27.85

>>763
シングルスレッドでの計測になってたぽい。この計測って最初のメモリ確保は含めてる？

**デフォルトの名無しさん** · 2023/08/21(月) 11:52:24.10

SIMDでの行列演算の最適化方法そのものとかさすがに関係なさ過ぎ。
RustとC++の違いに着目するならまだしも。

**デフォルトの名無しさん** · 2023/08/21(月) 14:56:42.48

>>764
>>762の通り行列積部分

JuliaをREPLで試した

function matgen(n, seed)
tmp = seed / n / n
[tmp * (i - j) * (i + j - 2) for i = 1:n, j = 1:n]
end
n = 1000
n = round(Int, n / 2) * 2
a = matgen(n, 1.0)
b = matgen(n, 2.0)
using BenchmarkTools
c=@btime(a*b)

OPENBLAS_NUM_THREADS=1 julia --optimize=3 --check-bounds=no
29.581 ms (2 allocations: 7.63 MiB)
OPENBLAS_NUM_THREADS=8 julia --optimize=3 --check-bounds=no
6.875 ms (2 allocations: 7.63 MiB)

juliaが行列積でnumpyの10倍遅いのが意外

**デフォルトの名無しさん** · 2023/08/21(月) 16:08:29.46

>>765
まあ、この板は実質雑談板なんで。アンチOSS君も大暴れしてますし大目にみてください。

**デフォルトの名無しさん** · 2023/08/21(月) 16:21:29.46

OSS関係無いわな。スレチ。別のところで好きなだけやればいい。

**デフォルトの名無しさん** · 2023/08/21(月) 16:41:35.26

OSSは関係大有りだと思う。

**デフォルトの名無しさん** · 2023/08/21(月) 16:46:18.02

Juliaとかは関係あるの？

**デフォルトの名無しさん** · 2023/08/21(月) 16:48:11.28

議論に関係あるかどうかの議論が必要ですね

**デフォルトの名無しさん** · 2023/08/21(月) 16:55:39.81

>>769
rustのエコシステムの話とかなら関係あるけど、OSS自体のメリデメ、とかそういう論点はスレチ。

**デフォルトの名無しさん** · 2023/08/21(月) 17:31:43.44

>>772
そんなことなくて、OSSであるということは、
非常に大きな影響を及ぼすので無視できない。

**デフォルトの名無しさん** · 2023/08/21(月) 17:54:01.38

>>773
それが通るなら少しでも擦れば何でもありになる。
影響の大小なんて本人が大きいと言い張れば大きいことになる。
スレタイ読んで関係あるかどうか常識で考えれば自明。もちろんあなたに言っても意味無いわけですけども。

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

>>774
そういうことじゃなくて、OSSは本質的に非常に大問題を
抱えてしまっているから、どうしようもない。

**デフォルトの名無しさん** · 2023/08/21(月) 18:33:57.42

>>775
そういうことじゃなくて、

じゃなくて、このスレそういうスレなんだよ。
マジで頭おかしいw

**デフォルトの名無しさん** · 2023/08/21(月) 18:35:45.82

Rustが失敗した原因の根底にOSSの問題があるって言いたいんじゃね

**デフォルトの名無しさん** · 2023/08/21(月) 19:07:31.63

「（すべての）OSSは本質的に非常に大問題を抱えている」→「Rustは本質的に非常に大問題を抱えている」
ってことだな
一応前提が正しければ結論も正しいけど前提の論証が大変そうだ

「一部のOSSは本質的に非常に大問題を抱えている」→「すべてのOSSは本質的に非常に大問題を抱えている」
みたいな論証魔法を決めれば何とかなるけどプログラマはこの類には耐性あるからな

「一部の」と「すべての」を削って後ろの修飾語を盛る程度だとまだ術式が足りなくて通らない

**デフォルトの名無しさん** · 2023/08/21(月) 19:20:23.58

どっちでもいいから、面白いことを書いてくれ

**デフォルトの名無しさん** · 2023/08/21(月) 19:32:31.36

>>775
boostは使わないの?

**デフォルトの名無しさん** · 2023/08/21(月) 19:53:38.34

矛盾を抱えているんだから論証とか無駄。
どんな結論でも導出できる。

**デフォルトの名無しさん** · 2023/08/21(月) 20:44:27.67

背理法の仮定を利用しなくても矛盾するなら、任意の結論を背理法で証明できる

だから「矛盾しているのはお前だけ」みたいな結論はむしろ出てこないんだよ
属人的な仮定を必要としないのだから全人類が矛盾する

**デフォルトの名無しさん** · 2023/08/21(月) 21:19:54.31

>>782
論理を語るのなら、まず共通の前提条件を全部出して合意取れよ。

前提条件より先に結論が出るとかありえないし、前提条件の合意が取れていないなら矛盾するから議論する意味がない。

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

>>778
おもしろい

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

>>782
合意がなければ義務はないというのは正しい
議論には義務が必要不可欠というのは間違っている
強制力があるべきという合意がもしあれば論理ではなく物理的な戦争が始まる

**デフォルトの名無しさん** · 2023/08/21(月) 22:02:41.22

ちょっと間違えたけど、どこを間違えたのかいちいち合意を取るのが面倒臭い

**デフォルトの名無しさん** · 2023/08/22(火) 00:06:37.51

まあ、この板はプログラム関連なら基本的に何話しても良いってことで。この6traits目を、立てた本人が言ってることなんで。次のtraitからはそれについても書いとく？

**デフォルトの名無しさん** · 2023/08/22(火) 00:42:55.89

>>787
君スレと板ごっちゃにしてない？

**デフォルトの名無しさん** · 2023/08/22(火) 06:46:28.34

このスレタイに釣られるって段階で、参加者がある程度絞られてる
別に何話そうが確かに構わんのだが、面白いことを書け

ライブラリ書いてるヤツが定着してるのは、Rustのライブラリ作りってこんな感じなのか、と思って眺めてる

そういや、hsutter氏がなんか動画出してたけど、まだ観てない
勉強しないといけないこと(non C++, non Rust)大杉

**デフォルトの名無しさん** · 2023/08/22(火) 12:18:07.09

>>773
スレタイを100万回読め

**デフォルトの名無しさん** · 2023/08/22(火) 19:02:47.39

>>766 訂正
測定自体はOKですが、最後の一文、桁を読み間違えてたorz

× >juliaが行列積でnumpyの10倍遅いのが意外

juliaとnumpyは同じスピードです(両方ともopenblasバックエンド、同一スレッド数の場合)

https://i.imgur.com/AKwAFec.png

>>747,759,764
そちらの環境でのマルチスレッドnumpyの測定数値が出ていたら自作ライブラリとの比較結果お願いします

**デフォルトの名無しさん** · 2023/08/22(火) 19:57:32.16

>>791
なんかnumpyでマルチスレッド指定しても速度上がんないんですけど何か要因は考えられますか？

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

>>792
こちらでは素のvenvでやり直しても、defaultでマルチスレッドが効いています

$ python311 -m venv venv
$ . venv/Scripts/activate
$ pip install numpy
$ pip list
Package Version
---------- -------
numpy 1.25.2
pip 23.2.1
setuptools 65.5.0
$ du -h venv
96M venv

$ python matmul-numpy.py 1000
0.006245136260986328
0.006272077560424805
0.006720542907714844
0.007251739501953125
0.006670713424682617
0.0067596435546875
0.006724119186401367
0.005736351013183594
0.005699872970581055
0.007322788238525391

condaの場合は分かりませんので、とりあえずpipのopenblas版numpyで計測してみては?
https://numpy.org/install/#numpy-packages--accelerated-linear-algebra-libraries

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

miniforgeのcondaでchannel指定してmkl版numpyを入れましたが、こちらもマルチスレッドが効いています(MKL_NUM_THREADS指定無しでも)

$ conda install -c intel numpy

$ du -h ****/tmpenv2
1.3G ****/tmpenv2 <-- orz

$ python -c 'import numpy; numpy.show_config()'
....
blas_mkl_info:
libraries = ['mkl_rt']
library_dirs = [****]
define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
include_dirs = [****]
....

MKL_NUM_THREADS=8 python matmul-numpy.py 1000
0.007200717926025391
0.007269620895385742
0.0062868595123291016
0.00983738899230957
0.007195472717285156
0.006726503372192383
0.006485939025878906
0.0068206787109375
0.006815910339355469
0.006788492202758789

**デフォルトの名無しさん** · 2023/08/22(火) 23:05:57.11

MKL版はthread数指定しないと=8よりも若干遅くなる

$ python matmul-numpy.py 1000
0.007860660552978516
0.009339094161987305
0.00830698013305664
0.006848335266113281
0.008496522903442383
0.007841348648071289
0.007840871810913086
0.00741887092590332
0.007982254028320312
0.006742000579833984

$ python -V
Python 3.8.11 :: Intel Corporation

芋づるインストールされた中でバージョンが気になるもの
mkl intel/win-64::mkl-2023.2.0-intel_49496
mkl-service intel/win-64::mkl-service-2.4.0-py38h9a4cf0c_35
mkl_fft intel/win-64::mkl_fft-1.3.6-py38h5020ddc_56
mkl_random intel/win-64::mkl_random-1.2.2-py38hf267b2b_76
mkl_umath intel/win-64::mkl_umath-0.1.1-py38h51af1d9_86
numpy intel/win-64::numpy-1.24.3-py38hcdfd0aa_0
numpy-base intel/win-64::numpy-base-1.24.3-py38h9b12b81_0

**デフォルトの名無しさん** · 2023/08/22(火) 23:11:09.00

シングルスレッドがopenblasよりも若干遅いじゃないか!
この辺でやめておきますorz

MKL_NUM_THREADS=1 python matmul-numpy.py 1000
0.032694339752197266
0.03222513198852539
0.03307652473449707
0.03224611282348633
0.031710147857666016
0.03175640106201172
0.032773494720458984
0.032234907150268555
0.03272652626037598
0.0316920280456543

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

crate の docs の comment 率上げるために
struct に comment 付け捲る仕様はホントうざい

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

python や bumpy の話題はスレ違い。
OSSの話題は許容範囲。
同一視してはいけない。

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

RustとC++の比較において、前者が「パソコンにおいて」
OSSからスタートしてしまったことは、全ての問題の始まり。
かつてC言語はUnixではOSSであったろうが、パソコンでは
原則的にクローズドであったからこそ発展を遂げた。

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

>>799
>かつてC言語はUnixではOSSであったろうが、パソコンでは
>原則的にクローズドであったからこそ発展を遂げた。
自分で書いていて論理がおかしいと思わないのかな?

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

>>799
C言語がクローズドって何がクローズなのかな?
ANSIは誰もが使えるオープンな規格だろうが?
他人に伝えたい文章は正確に書き給え

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

>>801
TurboC, msc, Watcom C/C++, LSI C, Lattice C,
Small C などがクローズであり、パソコンでOSSなものは
当時存在していなかったはずだ。

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

C言語は、規格はオープンと言えばオープンであったが、
PC-9801用のコンパイラのソースコードは非公開であった。
X68000 は gcc だったらしいが。

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

>>802

>>799
>パソコンでは原則的にクローズドであったからこそ発展を遂げた。
これは因果化関係を主張しているので
相関ではなくて因果の根拠を示すことが必要です
述べて下さい

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

分かると思うけどタイポ
-因果化関係
+因果関係

**デフォルトの名無しさん** · 2023/08/24(木) 03:19:55.67

>>804
クローズドだから競争が生じ、開発環境が高度に発展した。

**デフォルトの名無しさん** · 2023/08/24(木) 03:23:10.48

Win95が開発環境にとって終わりの始まりだった。
OSが32BIT化したことで、Unix系の無料OSSツールが
「主流のビジネスパソコン(PC-9801など)」の世界に
大量流入。
競争条件が破綻し、競争が不可能となり、衰退。

**デフォルトの名無しさん** · 2023/08/24(木) 04:23:51.68

>>759
(室温超伝導)サンプルの提出をお願いします

>>793-796
スルーか一言で済ませて、余計な知恵を付けさすな

**デフォルトの名無しさん** · 2023/08/24(木) 04:45:44.07

C/C++
/*
printf("hoge*/hoge\n");
*/
コンパイル通る

Rust
/*
println!("hoge*/hoge");
*/
コンパイル通らないωωω

**デフォルトの名無しさん** · 2023/08/24(木) 04:47:55.84

#[cfg(test)]
が原因か？

**デフォルトの名無しさん** · 2023/08/24(木) 04:51:35.83

>>799
>RustとC++の比較において、前者が「パソコンにおいて」
>OSSからスタートしてしまったことは、全ての問題の始まり。
一理ある

>かつてC言語はUnixではOSSであったろうが、パソコンでは
>原則的にクローズドであったからこそ発展を遂げた。
君の世界戦は異世界のものなのか？

**デフォルトの名無しさん** · 2023/08/24(木) 04:54:05.61

分かると思うけどタイポ
世界戦
世界線

**デフォルトの名無しさん** · 2023/08/24(木) 04:57:32.27

>>811
俺が言っているパソコンとは、PC-9801のことだ。
他のパソコンは知らんが、PC/AT機でもDOSでは、
OSSなコンパイラはほとんど動かなかったのでは。

**デフォルトの名無しさん** · 2023/08/24(木) 04:59:32.52

知らないならさっさと寝て下さい

**デフォルトの名無しさん** · 2023/08/24(木) 05:13:21.27

>>814
お前の方が知らんだろ。
OSSのせいで何もかも衰退してる。

**デフォルトの名無しさん** · 2023/08/24(木) 05:26:52.49

OSSは貧者(俺含む)の味方。これはガチ

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

みんなの予想通り
プリゴジン氏が暗殺された
ぜんぶOSSのせいだ

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

>>802
当時っていつだよ。
gnu cは1980年台からあるだろ。

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

>>813
ハナクソみたいな日本市場で世界を騙るとか、どこの異世界ですかね？

**デフォルトの名無しさん** · 2023/08/24(木) 12:14:49.40

>>819
5chでイキって気持ち良くなるとか、どこの暇人ですかね？

**デフォルトの名無しさん** · 2023/08/24(木) 13:03:33.51

>>802
確かにコンパイラは淘汰され減ったが
トータルのコンパイラの利用者つまり開発者は
OSSがない場合に比べて増加したんだと思うよ
誰でも直ぐに無料で開発を進められるようになり
開発者の裾野が広がったのは
ソフトウェアの進化速度を考える上で重要だったと思う

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

>>821
淘汰されたのはOSSのせいじゃなくてVisual C++のせい。

**デフォルトの名無しさん** · 2023/08/24(木) 15:13:16.73

>>818
DOSのPC-9801ではまともに使えなかった。

**デフォルトの名無しさん** · 2023/08/24(木) 15:51:29.49

競技プログラミングみたいな何の能力を測定しているのか、
また、参加者も限られるようなものの成績が良かった
ことと、言語に対する評価眼を持っていることは別である。
評価とは、審査する側が誰であるかによって異なってしまう。
国際組織でも、アメリカの金で成り立っている組織は、
アメリカの意見になってしまうことは良く知られている
のと同様、プログラムでも学問の世界でも同様だと考えられる。

**デフォルトの名無しさん** · 2023/08/24(木) 15:56:25.89

>>824
それで?

**デフォルトの名無しさん** · 2023/08/24(木) 15:56:54.62

「若いから年上の人より正しい判断が出来る」とは限らない。
しかも、その若者の能力が高いかどうかを判定しているのが
京大総長というような高齢の権威者の場合はなおさら。
何を持って人の能力を判断しているのか問題、という問題
が起きる。

**デフォルトの名無しさん** · 2023/08/24(木) 16:00:05.43

京大総長が、「この人はプログラミング能力がすばらしい」などと
判断したとしよう。
しかし、それは「京大総長基準」に過ぎない。
「プログラミング能力が素晴らしい」とは、一体何を
もって決めるのか。
仮に素晴らしかったとしても、プログラミング言語の
良し悪しをその人一人が判断してよいということでもない。

**デフォルトの名無しさん** · 2023/08/24(木) 16:12:01.07

それで?

**デフォルトの名無しさん** · 2023/08/24(木) 18:17:38.62

test

**デフォルトの名無しさん** · 2023/08/24(木) 18:50:59.70

パソコンが高価だった時代はゲーム機が貧者の味方
その時代のゲームは今でも売買されているが開発者の利益にはならない
むしろ過去の商用ソフトは衰退させた方が最新のゲームを売りやすい

**デフォルトの名無しさん** · 2023/08/24(木) 18:52:23.22

#[derive'Copy, Clone)]
たとえば古い passwd ファイルの形式とかで使われていた
root:x:0:0:root:/root:/bin/bash
user01:x:500:500::/home/user01:/bin/bash
のような「:」区切りのテキストファイルのデータベースを扱いたいとき
C標準のライブラリは何ですか？
Rust用のcrateで言うと何ですか？

**デフォルトの名無しさん** · 2023/08/24(木) 19:15:40.09

なんでそんなこと聞くの？

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

自作自演の準備じゃね

**デフォルトの名無しさん** · 2023/08/25(金) 00:12:20.33

>>831
区切るだけならstr.split(':')かstr.splitn(7, ':')
構造体に入れるなら一般的にserde crate
そのケースならcsv crateでコロンにデリミタ指定でもいけるはず

**デフォルトの名無しさん** · 2023/08/25(金) 00:21:37.84

Cなら自分はstrtokが好きかなあもちろんいろいろとunsafe

**デフォルトの名無しさん** · 2023/08/25(金) 03:14:57.13

Ruby で、CSV モジュールを使って書いた

UNIXプログラミング質問すれ Part10
https://mevius.5ch.net/test/read.cgi/tech/1303113996/936-937

**デフォルトの名無しさん** · 2023/08/25(金) 05:21:04.13

>>681
わかりみ

**デフォルトの名無しさん** · 2023/08/25(金) 07:20:56.16

BDS-C とか α-C の人は少数派かな