C vs C++ vs Rust Part.3

1 名前：デフォルトの名無しさん mailto:sage [2022/01/27(木) 22:19:47.56 ID:avZQ9Wm7.net] 闘え ※前スレ C++ vs Rust https://mevius.5ch.net/test/read.cgi/tech/1619219089/ C vs C++ vs Rust Part.2 https://mevius.5ch.net/test/read.cgi/tech/1639539350/ 29 名前：デフォルトの名無しさん mailto:sage [2022/01/30(日) 00:54:30.09 ID:zeCbxF6p.net] >>28 同じ処理でも入力内容次第で変わるからそんな簡単にいかないよ 30 名前：デフォルトの名無しさん mailto:sage [2022/01/30(日) 01:16:02.14 ID:iWlFH2We.net] async-stdならgoみたいにタスクが一定時間経っても制御返してくれないときに勝手にスレッド起こしてくれるんじゃなかったっけ 31 名前：デフォルトの名無しさん mailto:sage [2022/01/30(日) 18:58:15.77 ID:9ei8l7Ku.net] >>29 入出力が行なわれたらタスクのスイッチングが発生するので 意図的にブロッキングするものを呼んでブロックしているケースを除くと いつまでもタスクが切り替わらないのは演算のみを延々と続けるケースのみになる 対応策としては自分で定期的に手放すか以下の方法で回避 >>30 それは様々な問題点で中止 結局tokioもasync_stdもそのような特殊ケースはspawn()の代わりにspawn_blocking()することで タスクのスイッチングに影響が出ないように別スレッドで実行させる方針 その場合は結局スレッドを自分で起動して同期ブロッキングで使う昔からの方法と実質同じだが そのような特殊なケースも含めて統一的にタスクを扱える 32 名前：デフォルトの名無しさん mailto:sage [2022/01/30(日) 20:50:10.05 ID:dly2JmLT.net] >>31 延々と演算を続ける意図はなかったのに結果としてそうなる場合があるということ それを最初から想定できてyieldを挟めるなら問題ないのだが現実はそうはなっていない https://tokio.rs/blog/2020-04-preemption 33 名前：デフォルトの名無しさん mailto:sage [2022/01/30(日) 21:57:34.87 ID:C4ZQL08k.net] そのbudget方式は戻ってこないとペナルティ与えられないから本質的な解決になっていない yield相当をコンパイラが上手く挟むのも無理だからプログラマーが自らすればいい 34 名前：デフォルトの名無しさん mailto:sage [2022/01/30(日) 22:13:02.89 ID:46YJeJfB.net] 歴史から学ばない人 35 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 00:52:40.26 ID:wgfsi16C.net] 歴史ってのがマルチタスクOSにおける cooperative vs preemptive の話だとするなら前提が違いすぎない？ 任意のアプリケーションが動く可能性のあるOSと自身のプログラムのルーチンが実行されるアプリとではスケジューラに求められる制約条件は違って然るべきかと 36 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 07:30:22.38 ID:qlFEomu1.net] シングルスレッドかつcooperativeなJavaScriptがNode.jsを含めて成功しているように問題なく動作する 同期ブロッキングを完全排除してしまえばタスク切り替えが起きない場合すなわちスケジューラに戻らない場合は 入出力もなくループでメモリ上演算を繰り返している場合となる そのような場合でもループ内で自分で定期的にスケジューラへ制御を戻してやればよい そのためにRustではtask::yield_now()がある 37 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 10:15:42.24 ID:O/M0tTc6.net] イベントループがハングアップした時の対処とか考えたことないでしょ？ バグだからfixすればいいじゃ能がない 歴史に学ぶといいよ 38 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 10:24:59.23 ID:qlFEomu1.net] >>37 GoやJavaScriptなどは言語内蔵だが問題が起きたことはない Rustは言語から切り離されているが同様 いずれもそれらのランタイムの製作者以外がその部分のコードを触ることはなくバグが発生しようがない 39 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 10:27:00.53 ID:/Hwves02.net] >>37 > イベントループがハングアップした時の対処とか考えたことないでしょ？ そういうのは上位で対処（タイムアウトでプロセス再起動とか）することもあるからケースバイケースでしかない 40 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 10:46:15.49 ID:5QuAHu0k.net] イベントループがハングアップするってなに？ epoll_waitをブロッキングで使う場合でもタイムアウト設定すればハングアップなんてしないでしょ？ 41 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 11:35:28.84 ID:BNlzdeLS.net] タイムアウト設定忘れみたいなバグの話でしょ そんなに引っ張る話でもないと思う 42 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 12:52:34.54 ID:qlFEomu1.net] >>41 それは万が一あるとしても非同期スケジューラランタイム実装者の管轄 その利用者である一般プログラマーが引き起こすバグではないため関係ない 43 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 13:02:21.71 ID:dnOSCP4X.net] > epoll_waitをブロッキングで使う場合でもタイムアウト設定すればハングアップなんてしないでしょ？ の話だぞ？ 44 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 13:17:00.70 ID:wgfsi16C.net] 歴史って言葉持ち出してるんだしそんなしょうもない話じゃなくてもっと有名なエピソードなんじゃないの 45 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 13:24:49.76 ID:HGCqFbKg.net] 「Rustのタスクの欠点は？」 「プリエンプティブじゃないところ」 「プログラマーが注意すればいいだけだから問題ない」 46 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 13:35:30.64 ID:qlFEomu1.net] そりゃepollやselect相当を自分で使っていてミスをすればイベントループがハングアップするのは当たり前 しかし非同期タスクのイベントループは非同期スケジューラの中にあって自分でepollやselectを扱わなくてよくなった だから自分のミスでイベントループがハングアップすることはなくなった それ以前の歴史では色々あったが状況が変わった 47 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 13:51:12.77 ID:dnOSCP4X.net] はいはい、理想的な環境で羨ましいですね これでいいかな？w 48 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 14:52:14.32 ID:QZLkrRiL.net] メモリ開放忘れみたいなバグの話でしょ そんなに引っ張る話でもないと思う 49 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 14:57:56.44 ID:wgfsi16C.net] バグ耐性高めるためにタスクをプリエンプティブにしたいならすれば良いのでは プログラマーのスタンスに合わせて適切な物を選べるよう選択肢は用意されてると思うが 何について言い争ってるのかよくわからない 50 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 15:37:58.82 ID:UHXhumHV.net] GoやNode.jsが上手くいってる主因は非同期並行プログラミングのしやすさ 両者は方向性が真逆だけどそこが共通点で時代の要請 逆にC++が振るわないのは非同期並行プログラミングのしにくさ その状況でRustが登場して非同期並行プログラミングのしやすい環境も装備されたという流れ 51 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 18:03:53.30 ID:dLpRlGxR.net] >>49 タスクはプリエンプティブにはできないよ スレッド使えって言ってるの？ 52 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 18:33:21.76 ID:fs07R1AL.net] >>51 そうじゃね？ 53 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 18:56:25.41 ID:UHXhumHV.net] Node.jsもプリエンプティブではないけど困っていない タスクがプリエンプティブではないことを欠点だと主張する人は 欠点だという具体的な例を挙げてから主張すべき 54 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 19:02:29.41 ID:wgfsi16C.net] >>51 そうだよ ここで言うタスクはtokioやasync-stdの用語のタスクのことね spawn_blockingでタスク生成すれば専用スレッドが割り当てられるので特定のタスク選んでプリエンプティブにできる (OSにタスクスイッチの制御を委譲できる) 55 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 19:03:44.27 ID:wgfsi16C.net] >>53 spawn_blockingみたいなAPIが用意されてるのはプリエンプティブなタスクの需要はあるんじゃないの そこを否定する意味が分からない 56 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 19:28:57.02 ID:UHXhumHV.net] >>54 それはレイヤーが違う まずOSスレッドは何をしようが常にプリエンプティブ だからOSスレッド上で動いているタスクも途中で一時中断されたり再開されたりしうる だからといってタスクをプリエンプティブだと言わないのはタスクの階層で話をしているため タスクスケジューラに制御を戻さない限り他のタスクに切り替わらないため「プリエンプティブではない」と言われる 次にspawn_blockingで起動されるのもタスクの一つ だからタスクスケジューラが管理するスレッドの中で動く それがspawnだと一つのスレッドに対するキューに複数のタスクが割り当てられる 一方でspawn_blockingは一つのスレッドに対するキューにそのタスクのみが割り当てられる それだけの違いであり両者ともにタスクスケジューラの管理下にあるタスクである もちろん動作中も終了後もタスクとして同じ扱い つまりspawn_blockingはプリエンプティブにするものではない 同じタスクでありスタックレスなコルーチンであることも同じ >>55 その意見は成立していない 57 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 19:56:01.95 ID:wgfsi16C.net] >>56 確かにプリエンプティブという用語を使ったのは適切ではなかったかもね タスクがスレッドを占有するか他タスクと共有するか選択できると言い換えればよいかな 58 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 21:28:17.75 ID:L8OnQfxN.net] >>54 最初からspawn_blockingで呼ぶべきだと誰もがわかるような処理だけじゃないよ Goと同じでRustもそのうちプリエンプティブなスケジューラが作れるような機構を用意すると思うけどね 59 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 22:11:33.46 ID:qlFEomu1.net] >>58 preemptiveは必要ない シングルスレッドかつcooperativeなJavaScriptがNode.jsを含めて問題なく動作し成功している 60 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 22:59:08.63 ID:UPbAych9.net] Rustってデータ競合を許さない、ってあたりが並列処理とめちゃくちゃ相性良いように見えるけど、 まだそういうスケジューラとか非同期ランタイムらへんの仕組みがちっとも枯れてないんだね 将来のデファクトがどうなりそうか、ってのはある程度見えてきてるのかな？ 61 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 23:10:00.73 ID:9ggC0jgK.net] >>59 tokioの開発者もasync-stdの開発者もそうは考えてない a major source of bugs and performance issues in concurrent programs: accidental blocking. https://async.rs/blog/stop-worrying-about-blocking-the-new-async-std-runtime/ 62 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 23:16:15.33 ID:UHXhumHV.net] >>61 それはすぐに廃止された そして現在tokioもasync-stdもプリエンプティブを許すコードは存在しない 63 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 23:18:46.34 ID:9ggC0jgK.net] >>62 知ってるよ 問題認識の話をしてるんじゃん 64 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 23:21:44.46 ID:9ggC0jgK.net] Node.jsはタスク単位で高い信頼性が求められるシステムでは使われない イベントループがブロックしたら他のタスクを道連れにしてプロセス丸ごと再起動する以外に対処法がないから それもexecution managerできちんとモニタリングしてればの話 JSやNodeとRustとはポジショニングが違う 65 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 23:28:55.88 ID:qlFEomu1.net] >>64 イベントループがブロックすることはない 何を言いたいのか意味不明 66 名前：デフォルトの名無しさん mailto:sage [2022/01/31(月) 23:47:16.39 ID:UHXhumHV.net] >>64 Node.jsまで否定し始めるとは発狂もほどほどに 67 名前：デフォルトの名無しさん mailto:sage [2022/02/01(火) 01:18:54.05 ID:NlOJHFhB.net] >>58 rustでプリエンプティブなタスクって実装できるのかね goみたいなシグナルでスイッチする仕組みは使えない気がするが 68 名前：デフォルトの名無しさん [2022/02/01(火) 09:02:19.73 ID:YxH4csZd.net] 昔は標準で出来たのに「そういうのはライブラリでやればいい」って嘯きながら削除して、そのあと一生それが出来る標準ライブラリが登場しないいつものRust 69 名前：デフォルトの名無しさん mailto:sage [2022/02/01(火) 14:23:13.43 ID:fJKShZ3h.net] >>67 Cで実装できることはRustでも実装できる もちろんRustにもプリエンプティブなスケジューラは存在する Rustで書かれたプリエンプティブなリアルタイムOSもある >>68 Rust標準にプリエンプティブなタスクであるグリーンスレッドがあったのは Rust 1.0が正式リリース(2015年)となる以前Rust 〜0.9 の試行している時代 しかし重厚となりベアメタルもターゲットとするRustでは不適なため放棄 例えばGoの方法だと巨大なランタイムや個別スタックが必要など そのためRust標準ではスタックレスで軽いタスクを提供 さらに加えてasync/awaitもサポートし現在の軽く便利な環境となった 70 名前：デフォルトの名無しさん mailto:sage [2022/02/01(火) 15:14:51.45 ID:7ZSm+F9e.net] あと5年寝かせれば使えるようになるかな 71 名前：デフォルトの名無しさん mailto:sage [2022/02/01(火) 15:26:14.30 ID:0bEAn4zq.net] 別に今でもasync-stdを使えばええんちゃうか？ 72 名前：デフォルトの名無しさん mailto:sage [2022/02/01(火) 15:54:32.70 ID:aP+3H5wQ.net] >>69 ユーザーランドでプリエンプティブなタスク実現するという話なんだけど 具体的にどのライブラリがサポートしてるの？ 73 名前：デフォルトの名無しさん mailto:sage [2022/02/01(火) 16:14:56.52 ID:fJKShZ3h.net] >>71 async_stdでのプリエンプティブな試みは軽さの方針等に合わず、組み込まれないままで終わった >>72 上記の後継がasync_stdから独立していてsmolscaleとなっている 74 名前：デフォルトの名無しさん mailto:sage [2022/02/01(火) 17:44:48.05 ID:IGt6++7z.net] >>72 lunaticってのがWASM限定だけどプリエンプティブ実現してるらしいよ WASM以外はコンパイラのサポートがないと無理 >>73 async-stdがやろうとしてたのはプリエンプティブではないよ 75 名前：デフォルトの名無しさん [2022/02/01(火) 23:44:18.44 ID:rLXhSAw+.net] 話題になってる分野だとC++が惨敗すぎて Rustの話題一色になってしまってる感じ 76 名前：デフォルトの名無しさん mailto:sage [2022/02/02(水) 00:32:45.41 ID:Bknypv+c.net] C++が落ち目なのはまっとうなエンジニアの間では共通認識だろ 77 名前：デフォルトの名無しさん mailto:sage [2022/02/02(水) 02:30:31.45 ID:YscELMZC.net] 78 名前：変な拡張し杉てワケワカになってきてるよな [] [ここ壊れてます] 79 名前：デフォルトの名無しさん [2022/02/02(水) 11:27:34.63 ID:jvlsF+ng.net] 変な拡張を使わなければ良いだけでは？　使いこなせないのを使えなとは言わない。 80 名前：デフォルトの名無しさん mailto:sage [2022/02/02(水) 14:23:10.98 ID:X76n4047.net] RustがGo位の位置にたどり着くのは、あと何年かかるかね 81 名前：デフォルトの名無しさん mailto:sage [2022/02/02(水) 15:00:57.22 ID:O+j3A95O.net] GoはWebとかのアプリケーションでカジュアルに使われるようになってきたから、使う人数もかなり多くなってきたけど、 Rustはそういうポジションにつくことないだろうから、現在のGoほどの人気になることはないんじゃない？ RustはC/C++のシェアを塗り替えていく程度だろうけど、そういう低レイヤーでは最強言語になりそう 82 名前：デフォルトの名無しさん mailto:sage [2022/02/02(水) 15:03:25.91 ID:6tF6MeYL.net] RustがTIOBE Indexに出てくるのはいつなんだろう？w https://i.imgur.com/DNijd0h.jpg 83 名前：デフォルトの名無しさん mailto:sage [2022/02/02(水) 22:30:37.00 ID:yDHN0aKU.net] 言語機能としてはC++が完敗だから 過去遺産しか誇るものがない 84 名前：デフォルトの名無しさん mailto:sage [2022/02/02(水) 22:35:52.80 ID:/PkFuWcg.net] 何言ってんだこのバカ 85 名前：デフォルトの名無しさん mailto:sage [2022/02/02(水) 22:46:31.08 ID:J71gX0gE.net] シェアもユーザー数も過去遺産と言われてしまえばそうだが そんなことは興味がないのでC++での非同期並行プログラミングについても語って欲しい 86 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 16:11:01.01 ID:VWdjVpzZ.net] C++の非同期っていうとstd::asyncとか？ 87 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 17:48:17.26 ID:rBa0lj+C.net] >>81 今26位で、Kotlin, Lua, Scalaとかより上なんだが 88 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 17:52:10.90 ID:6/rx3Wgr.net] >>86 COBOLより下なんかwwwww 89 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 18:30:47.00 ID:VWdjVpzZ.net] KotlinやScalaは結局流行らずJavaで十分だし Luaも一時期熱狂したけど記法や環境が多くの人の好みに合わずPerlのように嫌われてる RustもC/C++で十分という認識が強くて普及せずに一部の通好みに終わる可能性がある Rustは有力企業もプッシュしてるけど三つの言語の流行らない特徴を全て備えてる そうこうしてるうちにRustより優れた言語がぽっとでて席巻する未来だってある 90 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 18:38:00.04 ID:I6DodtQJ.net] 流行るの閾値高くない？ 何位以上になったら満足なんだ 91 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 18:48:22.27 ID:Y+zgwr9T.net] 普通にTop10じゃね？ 92 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 18:51:38.73 ID:OQgvAcI9.net] しかしTop10のVisualBasicやアセンブリが流行ってるとか言われてもあまり納得感はないな… 93 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 19:08:22.03 ID:Ajxf7YAY.net] TIOBEってトレンドを計測してるわけじゃなくて、あくまで検索エンジンで検索結果のヒット数が多かったランキングだからな CとかVBみたいに昔から一定の人気を保ち続けてるような言語がランキング高くなりやすいんじゃないかな 94 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 19:24:04.62 ID:I6DodtQJ.net] GitHub上の活動に基づいたランキングの方がプログラマ間の流行を知るには良いのかな https://madnight.github.io/githut/#/pull_requests/2021/4 95 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 19:40:42.80 ID:NxnOaIbO.net] せやな TIOBEはJavaScriptとアセンブラが隣の順位に並んでるとかおかしすぎるやろ 96 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 21:31:55.43 ID:8HqROgrm.net] >>88 Scalaも当時は熱狂的なファンがいたよなｗ 97 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 21:44:00.20 ID:OJ3iv254.net] ScalaはJVMベースだという点以外は特に悪いところは無いと思うんだが 98 名前：デフォルトの名無しさん mailto:sage [2022/02/03(木) 23:27:45.66 ID:VxNIdQ9k.net] コラッツ関数を上手く実装できないかな 99 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 00:31:37.55 ID:tMDf8XuC.net] >>93 githubはアマチュアプログラマも沢山混じってる。 日経の調査ではプロのプログラマで最も使われている言語はC/C++だとされている。 なお、githubでも、CとC++を合算すると、9.82%、Rustは 0.694%で、 14.1倍の差がある。 100 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 00:34:29.27 ID:uF1Qc9S6.net] >>98 C vs C++でもあるんだから足したらだめでしょ 101 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 00:35:47.48 ID:tMDf8XuC.net] >>91 VisualBasicは結構使われているのではなかろうか。Excelなどで。 アセンブリは、基礎的なライブラリを作る人や組み込み、OS、BIOS を作ったり、グラフィックや数値計算の高速化を行う場合に必要な場合がある。 102 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 00:36:35.60 ID:tMDf8XuC.net] >>99 Cにクラスを入れたものとしてC++を使っている人は多いはず。 MFCなどもそう。 103 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 00:44:19.25 ID:uF1Qc9S6.net] >>101 いやいや、スレタイ通りこのスレではCとC++は対立する物として区別すべき 104 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 00:45:03.38 ID:zhkygWhI.net] 今どき言語マウントするやつは メンタルも技術力もアマチュア 105 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 00:47:42.81 ID:tMDf8XuC.net] C++はCを基礎にしてるくせに、Cに歯向かって宿主を殺してしまう寄生虫みたいな ことになってるからな。 106 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 05:41:15.73 ID:3M0ClPfa.net] いまのc++の拡張がな autoとラムダとdecltypeくらいでやめときゃいいのにあとでボツになりそうな仕様までモリモリに盛りやがって下手したらobjective-cみたいになりそう なのにいまだにpropertyも実装されてないとか 107 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 06:48:54.05 ID:GRC0hKFU.net] conceptsは許せる 108 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 08:29:55.22 ID:rPvrWkyY.net] >>105 それほどへんなもの追加されてるか？ 右辺値参照、constexpr、可変引数テンプレートは必要だしな 109 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 08:53:37.86 ID:O81zVfQh.net] 色々理解できない機能が増えて辛いんだろw 110 名前：デフォルトの名無しさん [2022/02/04(金) 09:58:17.78 ID:nTZc+xED.net] conceptはむしろ必須だろうよ 111 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 10:06:51.33 ID:xcjLhLWs.net] C++11移行では、変数定義で、 TYPE a = b; の形式が非推奨で、 TYPE a{b}; が推奨になった。 これは、C/C++の今までの伝統を全否定している。 C++11以後は、宿主を殺すウイルス的な存在に成り下がった一例。 112 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 11:28:12.62 ID:i2fLUlAL.net] hp.vector.co.jp/authors/VA000092/jokes/strup.html すこ 113 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 11:33:17.83 ID:O81zVfQh.net] >>110 みたいな爺さんは書き方変わるだけでアタフタw 114 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 12:53:41.07 ID:6YwPoRaj.net] >>110 TYPE a{b}; ↑これって何がうれしいの？ c++よく知らんので教えてほしい 115 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 12:55:43.71 ID:m8EcUnam.net] コンパイラ都合じゃね？知らんけど 116 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 14:18:18.78 ID:vKz9Nbsj.net] >>113 オブジェクトの定義に対して初期化子を与えると、オブジェクトの初期値を 決定することになるが、初期化子には次の4種類ある : T a{b}; T a={b}; T a = v; T a(v); ・このうち、あらゆる局面で利用できるのは、最初の T a{b}の形式のみ 　(なおこの形式はC++11で新しく導入された。)。 ・一番大きな理由はこの形式は「縮小変換を許さないから」とされる。 ただし、ややこしいのが、Tの部分を autoにした場合は、T a{b}の形式は 落とし穴がされるので使うべきではないとされている。 なぜなら: auto z1{99]; // z1は initializer_list<int>型になってしまう。 auto z2 = 99; // z2は、int型。 ところが、Tが具体的な型の場合には、T a{b} が推奨される: int x1{99};　// 推奨される書き方。 int x1 = 99;　// 縮小変換があるので推奨されない書き方。 全く一貫性が無く、C++11が駄目な部分の一つ。 117 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 14:21:57.65 ID:vKz9Nbsj.net] >>115 [誤字訂正版] オブジェクトの定義に対して初期化子を与えると、オブジェクトの初期値を 決定することになるが、初期化子には次の4種類ある : T a{b}; T a={b}; T a = b; T a(b); ・このうち、あらゆる局面で利用できるのは、最初の T a{b}の形式のみ 　(なおこの形式はC++11で新しく導入された。)。 ・一番大きな理由はこの形式は「縮小変換を許さないから」とされる。 ただし、ややこしいのが、Tの部分を autoにした場合は、T a{b}の形式は 落とし穴が有るので使うべきではないとされている。 なぜなら: auto z1{99]; // z1は initializer_list<int>型になってしまう。 auto z2 = 99; // z2は、int型。 ところが、Tが具体的な型の場合には、T a{b} が推奨される: int x1{99};　// 推奨される書き方。 int x1 = 99;　// 縮小変換があるので推奨されない書き方。 全く一貫性が無く、C++11が駄目な部分の一つ。 118 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 14:40:30.04 ID:MGyBlJhW.net] ふーん、レガシー言語は大変だね 119 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 14:44:09.08 ID:vKz9Nbsj.net] Rustはもっと最悪に汚い。 C++の最大の欠点は、仕様が難しいことに有るが、 Rustはさらに仕様が難しい。 よって、RustはC++をさらに悪くしたと言えて、改良には全くなってない。 120 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 14:54:48.13 ID:WO7o5PWJ.net] ふーん、レガシー脳は大変だね 121 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 14:59:52.64 ID:vKz9Nbsj.net] >>119 馬鹿は黙ってろ。 122 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 15:11:33.72 ID:dFWqGnrm.net] つまり仕様が簡単な方が良いということ？ 123 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 15:17:49.19 ID:wTfQ05na.net] >>119 ばーかｗ 124 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 16:13:01.17 ID:sAwXze1R.net] 効きすぎだろwww 125 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 16:23:37.19 ID:J8iEhnuL.net] c++は（ランタイム速度落とさなくても）できらぁ！ってなったらとりあえず入れるからな。 ある意味とてもガキくさいがそれはそれでありなポジションに到達してる気はする。 126 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 20:04:05.51 ID:JLdS+NWr.net] そんな凄いんだったらもっと普及してるよねRust でも現実はブビにもコボルにも負けてる泡沫言語 127 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 20:40:31.16 ID:b3SZZj/4.net] 単純に新しい言語だから累積となるユーザ数でまだ不利なだけ 2019年11月のasync導入で非同期プログラミングがまともに使えるようになってまだ2年余り Linux OSのようにC++を頑なに拒否していたプロジェクトでもRustは受け入れられたように C++に未来はないがRustには未来がある 128 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 20:44:24.76 ID:JLdS+NWr.net] 最後間違い C++に未来はないがRustも未来はない 129 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 20:49:40.24 ID:jGBmcDmC.net] 日本は先進国の技術トレンドから5年以上遅れてるからね

---

---

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

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