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

1 名前：デフォルトの名無しさん [2023/07/29(土) 15:05:46.55 ID:2Hm/yplK.net] 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/ 752 名前：デフォルトの名無しさん [2023/08/20(日) 17:20:33.01 ID:V1e9lq/f.net] スパコンのコーディングは知らんけど 雑にスレッドプールにぶん投げるだけで速くなる並列処理の方が SIMDより使いやすいなって思う 753 名前：デフォルトの名無しさん mailto:sage [2023/08/20(日) 18:05:27.72 ID:a//hKKzV.net] >>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) } 754 名前：デフォルトの名無しさん mailto:sage [2023/08/20(日) 18:11:30.48 ID:gUvM95Xg.net] よかったね 755 名前：デフォルトの名無しさん [2023/08/20(日) 18:25:00.43 ID:MyoNrmjT.net] >>743 え？Rustって標準ライブラリでhttpリクエストすらできないの？ 756 名前：デフォルトの名無しさん mailto:sage [2023/08/20(日) 18:38:37.77 ID:iamuQ/3/.net] Rsutはwebやるための言語とか言ってたような 757 名前：デフォルトの名無しさん [2023/08/20(日) 19:01:10.42 ID:mA4FcHyW.net] とりあえず1000×1000の行列の行列積dotが0.015秒弱でできるようなところまで行列ライブラリーが実装できたので、何とか0.00秒台で計算が終わる様にしたい。 今の所手を出してない最適化 1) Simd命令 2) インラインアセンブリ 3)ループアンローリング(これはRustだと自動的にやってくれてる様で自分の実験した範囲ではあまり効果がなかった。) この中で一番効果的な最適化は何？ ちなみに今の所は以下の最適下は既に実装済み 1) ループ交換 2) キャッシュブロッキング 3) rayonによる並列処理 758 名前：デフォルトの名無しさん mailto:sage [2023/08/20(日) 19:10:25.82 ID:IxOV384F.net] >>745 Rustの標準ライブラリは言語サポートを必要とするものを中心に極めて絞っている 既出のhttpやbase64だけでなく正規表現や乱数など多くの機能がデファクトスタンダードライブラリ >>746 標準ライブラリにないだけで各種ライブラリは下位から上位フレームワークまで揃っている CPUとメモリのリソースコスパ重視でWebやるならRust一択でまちがいない Webインフラ各トップ企業たちも>>496のようにRustを採用している 759 名前：デフォルトの名無しさん mailto:sage [2023/08/20(日) 19:16:55.65 ID:55RG+hvj.net] デファクトスタンダードという選りすぐりに聞こえるが 単にそれしかないだけのような... ユーザ数少ないので 760 名前：デフォルトの名無しさん mailto:sage [2023/08/20(日) 19:20:14.76 ID:yJmfO0+S.net] >>747 simdに手を出すとarmのsimdまでやる羽目になる インラインアセンブリも同じ つまり今のところおすすめはない 外部のライブラリなどに依存するなら別だけど 761 名前：デフォルトの名無しさん [2023/08/20(日) 19:25:32.14 ID:mA4FcHyW.net] >>750 じゃあ基本的にはdot演算に関してはこれ以上の最適化の余地はないって感じ？ 762 名前：デフォルトの名無しさん [2023/08/20(日) 19:26:47.41 ID:MoWe6Sep.net] グーグルとアップルが流行らせようとしてるらしいが 763 名前：デフォルトの名無しさん [2023/08/20(日) 19:44:59.22 ID:sOv9anOF.net] paiza.io の Rust は crates 使えないから ホント使いもんにならんわ 764 名前：デフォルトの名無しさん mailto:sage [2023/08/20(日) 19:47:42.13 ID:rPtHvv2S.net] じゃあGitHubのCodespacesでも使ってれば 765 名前：デフォルトの名無しさん mailto:sage [2023/08/20(日) 19:54:55.65 ID:yJmfO0+S.net] >>751 おすすめはしないけどやればやったになるはず デバッグ環境があるかは知らないが 766 名前：デフォルトの名無しさん mailto:sage [2023/08/20(日) 19:58:02.59 ID:U3mkt6q/.net] >>753 それはpaizaが悪い 例えば>>712で意味のない比較をしているが Python版はimport requestsと標準ライブラリではないものを使っている つまりpaizaはPythonだと標準ライブラリ以外のライブラリも使える 同じようにRustでも標準ライブラリ以外を使えるようにpaizaが対応すれば解決 767 名前：デフォルトの名無しさん mailto:sage [2023/08/20(日) 20:00:15.86 ID:259yUXDO.net] >>747 これに即して測ってみては(1500x1500(f64)の生成、行列積、破棄の計測) https://github.com/kostya/benchmarks#matmul とりあえずnumpyとの比較とか https://github.com/kostya/benchmarks/blob/master/matmul/matmul-numpy.py 768 名前：デフォルトの名無しさん mailto:sage [2023/08/20(日) 20:00:40.96 ID:pu4udaaX.net] シミュレータなどは行列演算だけ高速化しても、全体の 高速化にはなら無い事が多い。 769 名前：デフォルトの名無しさん [2023/08/20(日) 20:04:56.81 ID:mA4FcHyW.net] >>757 手元のnumpyよりは少なくとも1000×1000の行列積は2倍から3倍速、10000×10000の行列積だと約5倍から10倍速い。手元よnumpyのバックエンドはIntelMKL。 770 名前：デフォルトの名無しさん [2023/08/20(日) 20:07:47.30 ID:mA4FcHyW.net] まだ、行列の対角化とか逆行列の計算は実装できてない。 771 名前：デフォルトの名無しさん mailto:sage [2023/08/20(日) 20:20:10.35 ID:259yUXDO.net] なんか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 772 名前：デフォルトの名無しさん mailto:sage [2023/08/20(日) 20:23:55.44 ID:259yUXDO.net] 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] 773 名前：デフォルトの名無しさん mailto:sage [2023/08/20(日) 20:37:44.31 ID:259yUXDO.net] 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になってたりしてる？ 774 名前：デフォルトの名無しさん [2023/08/20(日) 22:44:27.85 ID:mA4FcHyW.net] >>763 シングルスレッドでの計測になってたぽい。この計測って最初のメモリ確保は含めてる？ 775 名前：デフォルトの名無しさん mailto:sage [2023/08/21(月) 11:52:24.10 ID:lrfEI2bB.net] SIMDでの行列演算の最適化方法そのものとかさすがに関係なさ過ぎ。 RustとC++の違いに着目するならまだしも。 776 名前：デフォルトの名無しさん mailto:sage [2023/08/21(月) 14:56:42.48 ID:jPnmmh+2.net] >>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倍遅いのが意外 777 名前：デフォルトの名無しさん [2023/08/21(月) 16:08:29.46 ID:IYi1S2wl.net] >>765 まあ、この板は実質雑談板なんで。アンチOSS君も大暴れしてますし大目にみてください。 778 名前：デフォルトの名無しさん [2023/08/21(月) 16:21:29.46 ID:A+ik1f9X.net] OSS関係無いわな。スレチ。別のところで好きなだけやればいい。 779 名前：デフォルトの名無しさん mailto:sage [2023/08/21(月) 16:41:35.26 ID:W/JUog9y.net] OSSは関係大有りだと思う。 780 名前：デフォルトの名無しさん mailto:sage [2023/08/21(月) 16:46:18.02 ID:dQnAszLW.net] Juliaとかは関係あるの？ 781 名前：デフォルトの名無しさん mailto:sage [2023/08/21(月) 16:48:11.28 ID:US7qznQL.net] 議論に関係あるかどうかの議論が必要ですね 782 名前：デフォルトの名無しさん [2023/08/21(月) 16:55:39.81 ID:A+ik1f9X.net] >>769 rustのエコシステムの話とかなら関係あるけど、OSS自体のメリデメ、とかそういう論点はスレチ。 783 名前：デフォルトの名無しさん mailto:sage [2023/08/21(月) 17:31:43.44 ID:W/JUog9y.net] >>772 そんなことなくて、OSSであるということは、 非常に大きな影響を及ぼすので無視できない。 784 名前：デフォルトの名無しさん [2023/08/21(月) 17:54:01.38 ID:A+ik1f9X.net] >>773 それが通るなら少しでも擦れば何でもありになる。 影響の大小なんて本人が大きいと言い張れば大きいことになる。 スレタイ読んで関係あるかどうか常識で考えれば自明。もちろんあなたに言っても意味無いわけですけども。 785 名前：デフォルトの名無しさん mailto:sage [2023/08/21(月) 18:18:38.42 ID:W/JUog9y.net] >>774 そういうことじゃなくて、OSSは本質的に非常に大問題を 抱えてしまっているから、どうしようもない。 786 名前：デフォルトの名無しさん [2023/08/21(月) 18:33:57.42 ID:AlisErs6.net] >>775 そういうことじゃなくて、 じゃなくて、このスレそういうスレなんだよ。 マジで頭おかしいw 787 名前：デフォルトの名無しさん mailto:sage [2023/08/21(月) 18:35:45.82 ID:dQnAszLW.net] Rustが失敗した原因の根底にOSSの問題があるって言いたいんじゃね 788 名前：デフォルトの名無しさん mailto:sage [2023/08/21(月) 19:07:31.63 ID:8jq5nfQv.net] 「（すべての）OSSは本質的に非常に大問題を抱えている」→「Rustは本質的に非常に大問題を抱えている」 ってことだな 一応前提が正しければ結論も正しいけど前提の論証が大変そうだ 「一部のOSSは本質的に非常に大問題を抱えている」→「すべてのOSSは本質的に非常に大問題を抱えている」 みたいな論証魔法を決めれば何とかなるけどプログラマはこの類には耐性あるからな 「一部の」と「すべての」を削って後ろの修飾語を盛る程度だとまだ術式が足りなくて通らない 789 名前：デフォルトの名無しさん mailto:sage [2023/08/21(月) 19:20:23.58 ID:NjHCZBFl.net] どっちでもいいから、面白いことを書いてくれ 790 名前：デフォルトの名無しさん [2023/08/21(月) 19:32:31.36 ID:jTK4AVkF.net] >>775 boostは使わないの? 791 名前：デフォルトの名無しさん mailto:sage [2023/08/21(月) 19:53:38.34 ID:2W/Jw/4i.net] 矛盾を抱えているんだから論証とか無駄。 どんな結論でも導出できる。 792 名前：デフォルトの名無しさん mailto:sage [2023/08/21(月) 20:44:27.67 ID:oR9oJ1qa.net] 背理法の仮定を利用しなくても矛盾するなら、任意の結論を背理法で証明できる だから「矛盾しているのはお前だけ」みたいな結論はむしろ出てこないんだよ 属人的な仮定を必要としないのだから全人類が矛盾する 793 名前：デフォルトの名無しさん mailto:sage [2023/08/21(月) 21:19:54.31 ID:q/j5yT82.net] >>782 論理を語るのなら、まず共通の前提条件を全部出して合意取れよ。 前提条件より先に結論が出るとかありえないし、前提条件の合意が取れていないなら矛盾するから議論する意味がない。 794 名前：デフォルトの名無しさん [2023/08/21(月) 21:26:14.98 ID:6J/DqmTl.net] >>778 おもしろい 795 名前：デフォルトの名無しさん mailto:sage [2023/08/21(月) 21:58:53.90 ID:oR9oJ1qa.net] >>782 合意がなければ義務はないというのは正しい 議論には義務が必要不可欠というのは間違っている 強制力があるべきという合意がもしあれば論理ではなく物理的な戦争が始まる 796 名前：デフォルトの名無しさん mailto:sage [2023/08/21(月) 22:02:41.22 ID:oR9oJ1qa.net] ちょっと間違えたけど、どこを間違えたのかいちいち合意を取るのが面倒臭い 797 名前：デフォルトの名無しさん [2023/08/22(火) 00:06:37.51 ID:p77SLRC3.net] まあ、この板はプログラム関連なら基本的に何話しても良いってことで。この6traits目を、立てた本人が言ってることなんで。次のtraitからはそれについても書いとく？ 798 名前：デフォルトの名無しさん mailto:sage [2023/08/22(火) 00:42:55.89 ID:CKREFo3h.net] >>787 君スレと板ごっちゃにしてない？ 799 名前：デフォルトの名無しさん mailto:sage [2023/08/22(火) 06:46:28.34 ID:oV9q0mPv.net] このスレタイに釣られるって段階で、参加者がある程度絞られてる 別に何話そうが確かに構わんのだが、面白いことを書け ライブラリ書いてるヤツが定着してるのは、Rustのライブラリ作りってこんな感じなのか、と思って眺めてる そういや、hsutter氏がなんか動画出してたけど、まだ観てない 勉強しないといけないこと(non C++, non Rust)大杉 800 名前：デフォルトの名無しさん [2023/08/22(火) 12:18:07.09 ID:whNyN1Gw.net] >>773 スレタイを100万回読め 801 名前：デフォルトの名無しさん mailto:sage [2023/08/22(火) 19:02:47.39 ID:jvLbVv4g.net] >>766 訂正 測定自体はOKですが、最後の一文、桁を読み間違えてたorz × >juliaが行列積でnumpyの10倍遅いのが意外 juliaとnumpyは同じスピードです(両方ともopenblasバックエンド、同一スレッド数の場合) https://i.imgur.com/AKwAFec.png >>747,759,764 そちらの環境でのマルチスレッドnumpyの測定数値が出ていたら自作ライブラリとの比較結果お願いします 802 名前：デフォルトの名無しさん [2023/08/22(火) 19:57:32.16 ID:p77SLRC3.net] >>791 なんかnumpyでマルチスレッド指定しても速度上がんないんですけど何か要因は考えられますか？ 803 名前：デフォルトの名無しさん mailto:sage [2023/08/22(火) 21:29:39.50 ID:3Q3W0wKi.net] >>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 804 名前：デフォルトの名無しさん mailto:sage [2023/08/22(火) 22:57:52.73 ID:3Q3W0wKi.net] 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 805 名前：デフォルトの名無しさん mailto:sage [2023/08/22(火) 23:05:57.11 ID:3Q3W0wKi.net] 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 806 名前：デフォルトの名無しさん mailto:sage [2023/08/22(火) 23:11:09.00 ID:3Q3W0wKi.net] シングルスレッドが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 807 名前：デフォルトの名無しさん [2023/08/23(水) 11:18:41.09 ID:89z/H8g7.net] crate の docs の comment 率上げるために struct に comment 付け捲る仕様はホントうざい 808 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 02:29:53.65 ID:zGLBQFrp.net] python や bumpy の話題はスレ違い。 OSSの話題は許容範囲。 同一視してはいけない。 809 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 02:32:08.21 ID:zGLBQFrp.net] RustとC++の比較において、前者が「パソコンにおいて」 OSSからスタートしてしまったことは、全ての問題の始まり。 かつてC言語はUnixではOSSであったろうが、パソコンでは 原則的にクローズドであったからこそ発展を遂げた。 810 名前：デフォルトの名無しさん [2023/08/24(木) 02:42:41.30 ID:hEI/Eij5.net] >>799 >かつてC言語はUnixではOSSであったろうが、パソコンでは >原則的にクローズドであったからこそ発展を遂げた。 自分で書いていて論理がおかしいと思わないのかな? 811 名前：デフォルトの名無しさん [2023/08/24(木) 02:45:44.43 ID:hEI/Eij5.net] >>799 C言語がクローズドって何がクローズなのかな? ANSIは誰もが使えるオープンな規格だろうが? 他人に伝えたい文章は正確に書き給え 812 名前：デフォルトの名無しさん mailto:sage [2023/08/24 ] [ここ壊れてます] 813 名前：(木) 02:47:37.96 ID:zGLBQFrp.net mailto: >>801 TurboC, msc, Watcom C/C++, LSI C, Lattice C, Small C などがクローズであり、パソコンでOSSなものは 当時存在していなかったはずだ。 [] [ここ壊れてます] 814 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 02:53:01.56 ID:zGLBQFrp.net] C言語は、規格はオープンと言えばオープンであったが、 PC-9801用のコンパイラのソースコードは非公開であった。 X68000 は gcc だったらしいが。 815 名前：デフォルトの名無しさん [2023/08/24(木) 02:53:58.47 ID:hEI/Eij5.net] >>802 >>799 >パソコンでは原則的にクローズドであったからこそ発展を遂げた。 これは因果化関係を主張しているので 相関ではなくて因果の根拠を示すことが必要です 述べて下さい 816 名前：デフォルトの名無しさん [2023/08/24(木) 02:56:38.98 ID:hEI/Eij5.net] 分かると思うけどタイポ -因果化関係 +因果関係 817 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 03:19:55.67 ID:zGLBQFrp.net] >>804 クローズドだから競争が生じ、開発環境が高度に発展した。 818 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 03:23:10.48 ID:zGLBQFrp.net] Win95が開発環境にとって終わりの始まりだった。 OSが32BIT化したことで、Unix系の無料OSSツールが 「主流のビジネスパソコン(PC-9801など)」の世界に 大量流入。 競争条件が破綻し、競争が不可能となり、衰退。 819 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 04:23:51.68 ID:ejJL7Sq0.net] >>759 (室温超伝導)サンプルの提出をお願いします >>793-796 スルーか一言で済ませて、余計な知恵を付けさすな 820 名前：デフォルトの名無しさん [2023/08/24(木) 04:45:44.07 ID:UfAeCzV0.net] C/C++ /* printf("hoge*/hoge\n"); */ コンパイル通る Rust /* println!("hoge*/hoge"); */ コンパイル通らないωωω 821 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 04:47:55.84 ID:UfAeCzV0.net] #[cfg(test)] が原因か？ 822 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 04:51:35.83 ID:UfAeCzV0.net] >>799 >RustとC++の比較において、前者が「パソコンにおいて」 >OSSからスタートしてしまったことは、全ての問題の始まり。 一理ある >かつてC言語はUnixではOSSであったろうが、パソコンでは >原則的にクローズドであったからこそ発展を遂げた。 君の世界戦は異世界のものなのか？ 823 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 04:54:05.61 ID:UfAeCzV0.net] 分かると思うけどタイポ 世界戦 世界線 824 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 04:57:32.27 ID:zGLBQFrp.net] >>811 俺が言っているパソコンとは、PC-9801のことだ。 他のパソコンは知らんが、PC/AT機でもDOSでは、 OSSなコンパイラはほとんど動かなかったのでは。 825 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 04:59:32.52 ID:UfAeCzV0.net] 知らないならさっさと寝て下さい 826 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 05:13:21.27 ID:zGLBQFrp.net] >>814 お前の方が知らんだろ。 OSSのせいで何もかも衰退してる。 827 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 05:26:52.49 ID:7AUlTMfz.net] OSSは貧者(俺含む)の味方。これはガチ 828 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 07:39:52.41 ID:UfAeCzV0.net] みんなの予想通り プリゴジン氏が暗殺された ぜんぶOSSのせいだ 829 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 08:51:41.95 ID:TNcuPvYX.net] >>802 当時っていつだよ。 gnu cは1980年台からあるだろ。 830 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 08:53:47.64 ID:TNcuPvYX.net] >>813 ハナクソみたいな日本市場で世界を騙るとか、どこの異世界ですかね？ 831 名前：デフォルトの名無しさん [2023/08/24(木) 12:14:49.40 ID:fsW9ztQn.net] >>819 5chでイキって気持ち良くなるとか、どこの暇人ですかね？ 832 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 13:03:33.51 ID:hEI/Eij5.net] >>802 確かにコンパイラは淘汰され減ったが トータルのコンパイラの利用者つまり開発者は OSSがない場合に比べて増加したんだと思うよ 誰でも直ぐに無料で開発を進められるようになり 開発者の裾野が広がったのは ソフトウェアの進化速度を考える上で重要だったと思う 833 名前：デフォルトの名無しさん [2023/08/24(木) 15:07:09.15 ID:HFuNmebf.net] >>821 淘汰されたのはOSSのせいじゃなくてVisual C++のせい。 834 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 15:13:16.73 ID:YZsWFF7D.net] >>818 DOSのPC-9801ではまともに使えなかった。 835 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 15:51:29.49 ID:YZsWFF7D.net] 競技プログラミングみたいな何の能力を測定しているのか、 また、参加者も限られるようなものの成績が良かった ことと、言語に対する評価眼を持っていることは別である。 評価とは、審査する側が誰であるかによって異なってしまう。 国際組織でも、アメリカの金で成り立っている組織は、 アメリカの意見になってしまうことは良く知られている のと同様、プログラムでも学問の世界でも同様だと考えられる。 836 名前：デフォルトの名無しさん [2023/08/24(木) 15:56:25.89 ID:hEI/Eij5.net] >>824 それで? 837 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 15:56:54.62 ID:YZsWFF7D.net] 「若いから年上の人より正しい判断が出来る」とは限らない。 しかも、その若者の能力が高いかどうかを判定しているのが 京大総長というような高齢の権威者の場合はなおさら。 何を持って人の能力を判断しているのか問題、という問題 が起きる。 838 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 16:00:05.43 ID:YZsWFF7D.net] 京大総長が、「この人はプログラミング能力がすばらしい」などと 判断したとしよう。 しかし、それは「京大総長基準」に過ぎない。 「プログラミング能力が素晴らしい」とは、一体何を もって決めるのか。 仮に素晴らしかったとしても、プログラミング言語の 良し悪しをその人一人が判断してよいということでもない。 839 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 16:12:01.07 ID:M4GRlfeF.net] それで? 840 名前：デフォルトの名無しさん [2023/08/24(木) 18:17:38.62 ID:QG+ZRfMP.net] test 841 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 18:50:59.70 ID:RER6Zrq6.net] パソコンが高価だった時代はゲーム機が貧者の味方 その時代のゲームは今でも売買されているが開発者の利益にはならない むしろ過去の商用ソフトは衰退させた方が最新のゲームを売りやすい 842 名前：デフォルトの名無しさん [2023/08/24(木) 18:52:23.22 ID:CY1BVKcv.net] #[derive'Copy, Clone)] たとえば古い passwd ファイルの形式とかで使われていた root:x:0:0:root:/root:/bin/bash user01:x:500:500::/home/user01:/bin/bash のような「:」区切りのテキストファイルのデータベースを扱いたいとき C標準のライブラリは何ですか？ Rust用のcrateで言うと何ですか？ 843 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 19:15:40.09 ID:zclBScKH.net] なんでそんなこと聞くの？ 844 名前：デフォルトの名無しさん mailto:sage [2023/08/24(木) 22:11:36.44 ID:3ljd7W/g.net] 自作自演の準備じゃね 845 名前：デフォルトの名無しさん mailto:sage [2023/08/25(金) 00:12:20.33 ID:1ayFYibv.net] >>831 区切るだけならstr.split(':')かstr.splitn(7, ':') 構造体に入れるなら一般的にserde crate そのケースならcsv crateでコロンにデリミタ指定でもいけるはず 846 名前：デフォルトの名無しさん mailto:sage [2023/08/25(金) 00:21:37.84 ID:jCG33I6S.net] Cなら自分はstrtokが好きかなあ もちろんいろいろとunsafe 847 名前：デフォルトの名無しさん mailto:sage [2023/08/25(金) 03:14:57.13 ID:VpCvI12o.net] Ruby で、CSV モジュールを使って書いた UNIXプログラミング質問すれ Part10 https://mevius.5ch.net/test/read.cgi/tech/1303113996/936-937 848 名前：デフォルトの名無しさん mailto:sage [2023/08/25(金) 05:21:04.13 ID:+GAmI8K8.net] >>681 わかりみ 849 名前：デフォルトの名無しさん [2023/08/25(金) 07:20:56.16 ID:vekBwhc6.net] BDS-C とか α-C の人は少数派かな 850 名前：デフォルトの名無しさん mailto:sage [2023/08/25(金) 07:34:56.19 ID:jCG33I6S.net] THINK Cとか、CodeWarriorとかあったけどねえ 内製にはgccで十分だわって 851 名前：デフォルトの名無しさん mailto:sage [2023/08/25(金) 10:05:27.96 ID:QjCfYj97.net] マクロはズル 非売品はチート ネイティブコンパイラは商品という雰囲気 852 名前：デフォルトの名無しさん mailto:sage [2023/08/25(金) 21:47:21.62 ID:dgCh3EK3.net] スレタイだけ見て検証結果だけ見に来ました どこですか？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef