C++ vs Rust

**デフォルトの名無しさん** · 2021/04/24(土) 08:04:49.48

競え

**デフォルトの名無しさん** · 2021/11/30(火) 18:39:16.69

Rustで書かれたFirefoxはC++で書かれたChromeより三倍以上の安全性を持つ。

**デフォルトの名無しさん** · 2021/11/30(火) 18:41:46.86

>>633
なぜC++で説明しないのかといえば、std::listは、std::vectorなどの
他のコンテナと同じ使い勝手にするために、リンクトリスト本来の
アルゴリズムとは異なって実装されてしまっている可能性があるから。

**デフォルトの名無しさん** · 2021/11/30(火) 18:42:00.53

>>631
シングルスレッド内のマルチタスク(いわゆるグリーンスレッド)でも競合は起きます

例えばポインタを得た後にファイルや通信の読み書きを行えばシングルスレッド内の別タスクに切り替わります
その別タスクが人間UIから指示でリンクリストの一部削除も起き得ます
元のタスクに切り替わった時に保持してるポインタの先は既に削除されて存在しないかもしれません

したがってシングルスレッドでも競合対策は必要です

**デフォルトの名無しさん** · 2021/11/30(火) 18:43:00.57

>>634
そもそも Chromeが根本的にバグったりダウンした経験が無いので
そういわれても分からない。

**デフォルトの名無しさん** · 2021/11/30(火) 18:44:23.35

>>636
でもそのことを通常、「排他機構」とは言わないハズ。
独自定義の言葉は混乱するので使うべきでない。

**デフォルトの名無しさん** · 2021/11/30(火) 18:46:28.71

>>637
クレジットカードやパスワードが既に。

**デフォルトの名無しさん** · 2021/11/30(火) 18:55:31.01

>>638
ではそのシングルスレッドでの競合状況>>636を避けるための排他的な制御をあなたは何と呼ぶのですか？

**デフォルトの名無しさん** · 2021/11/30(火) 18:56:55.23

シグナルハンドラの中と競合が起きないようにするのは、排他と呼んでますよ。

**デフォルトの名無しさん** · 2021/11/30(火) 19:00:10.44

>>640
言葉は知らない。

ただし、MicrosoftのWinFormsやMFC、Win32だと、メッセージキューを
上手く使うことができていて、1つのメッセージ(イベント)を処理中は、他のメッセージを
受け付けないようにする仕組みになっているので、自分のアプリのイベントハンドラに
二重に入ってくることがない。だから、あなたの言っているような状況は絶対に起きないように
なっているため、心配要らないし、それを一般プログラマがコードで避けることも
通常は必要ない。

JSだとメッセージキューを上手く操れないためにイベントが二重に入ってくる
ことを一般プログラマが手作業で避ける必要がある場合が出てくるが。

**デフォルトの名無しさん** · 2021/11/30(火) 19:01:35.67

>>641
JSは、二重にイベントが呼び出されることがあるから必要になるだけ。
マイクロソフトのMFCやWinFormsではそもそも起きない。

**デフォルトの名無しさん** · 2021/11/30(火) 19:04:13.70

>>643
[補足]
正しくは「JS」ではなくて、ブラウザ上でJSで使ったイベント処理の話。
onclick="func()" みたいに書くやり方のこと。
イベントキューは有ることはあるが、一般プログラマが細かく制御できない。
Win32やMFCでは細かく制御できる。

**デフォルトの名無しさん** · 2021/11/30(火) 19:08:01.74

>>642
Microsoftは全く使うことがないので知らないのですがそんなダメ仕様なの？
さすがに通信I/O待ちになったら別タスクに切り替わると思いますよ
少なくとも他のまともなシステムならば別タスクへと切り替わります
ずっと通信I/Oを待ち続けるのは明らかに時間の無駄ですから

**デフォルトの名無しさん** · 2021/11/30(火) 19:20:14.50

>>638
は？何言ってんの？
プロセス対プロセスでも競合が発生するなら排他制御すると表現するのに

**デフォルトの名無しさん** · 2021/11/30(火) 19:46:30.08

>>645
「タスク」って言うのが、他のアプリのプロセスやスレッドに切り替わるというの
なら、その通りだが、自分のアプリのイベント中に、自分のアプリの別にイベントが
発生するのはプログラムが複雑になるので、MicrosoftのGUIではわざと避けられて
いる。でも、そのおかげでGUIプログラムが簡単に書けるようになっている。

**デフォルトの名無しさん** · 2021/11/30(火) 19:48:30.63

>>647
そんな効率の悪いお子様向けメニューがあるのですね
あなたはそんな効率悪いダメ環境でしかプログラミングしたことないのですか？

**デフォルトの名無しさん** · 2021/11/30(火) 19:56:09.78

>>648
ドローツールで、メニューからファイル保存ハンドラを起動して、
ファイル保存処理中に、マウスをクリックして、マウスイベントを起動して、
データを変更する必要は無いよね。
だから、マイクロソフトのMFCやWinFormsでは、最初から、メニューハンドラを
実行中は、マウスイベントが起動しないように設計されている。
同様に、あらゆるイベントは、必ず1つずつ順番に実行される設計になっている。

**デフォルトの名無しさん** · 2021/11/30(火) 19:59:43.64

>>649
それだとウェブブラウザすら実装できませんね
そういうお子様向けメニューがあると勉強になりました
ありがとう

**デフォルトの名無しさん** · 2021/11/30(火) 20:11:18.02

>>643
二重にイベントが呼び出されるとはどういう現象を指しているのでしょうか
またJSはシングルスレッドなのでデータ競合は発生しないと思うのですが

そもそもなぜ突然JSの話が出てきたのですか
シグナルハンドラとイベントハンドラを混同していませんか

**デフォルトの名無しさん** · 2021/11/30(火) 20:16:25.11

>>651
JSは、ファイルI/Oを非同期でやりたがる人が居て、例えば、
Unixの write() は、書き終わるまでその場で停止して、書き終わってから
次の行から実行が再開される。
ところが、JSの場合は、書いている間に、イベントキューの読み取りに戻って
別のイベントが起動される可能性が生まれる。
だから、メニューからファイル保存を選んで、write() 文に相当する関数を
呼び出すと、まだ保存が終了して無いのに、別のメニューをもう一回起動
できるようなアホな状況が生まれる可能性が出てくる。

**デフォルトの名無しさん** · 2021/11/30(火) 20:20:26.40

>>652
それはJS限定の場合ではなく
まともなシングルスレッド並列プログラミングならどれも同じで他へ切り替わります
通信I/Oで止まってしまい他へ切り替わらない方がおかしい

**デフォルトの名無しさん** · 2021/11/30(火) 20:29:47.98

>>653
あなたは、テキストエディタで保存中に、別の処理をしてしまう人？

**デフォルトの名無しさん** · 2021/11/30(火) 20:32:09.62

>>654
そんなことではなくて
そのMS仕様？ではウェブブラウザを作れませんよね

**デフォルトの名無しさん** · 2021/11/30(火) 20:32:20.30

>>652
そりゃノンブロッキングなAPIを使ったらそうなるでしょ
処理が先に進んで困るならブロッキングなAPIを使うかawaitなりすれば良いのでは
なにを問題に感じているのかがわかりません

**デフォルトの名無しさん** · 2021/11/30(火) 20:35:32.02

>>655
いや、作れる。

**デフォルトの名無しさん** · 2021/11/30(火) 20:37:39.44

>>656
>>636のようなデタラメを書く人が居たからだ。

**デフォルトの名無しさん** · 2021/11/30(火) 20:46:39.91

>>658
グリーンスレッドの話にMFCやWinFormsの描画スレッドの話を持ち出すのはなんの反論にもなってないと思うのですが...

そもそも >>628 のいう排他は rust の aliasing xor mutability の意味での排他なので論点がすれてます

**デフォルトの名無しさん** · 2021/11/30(火) 20:52:01.15

>>657
通信やI/O待ちしたままシングルスレッド内で他へ切り替わらないと主張しているのですからウェブブラウザを実装するのは無理でしょ
JavaScriptを含むまともなシステムのように通信やI/O待ちの時はシングルスレッド内の他のタスクへ切り替わるのが普通であってそれだと実装できます

**デフォルトの名無しさん** · 2021/11/30(火) 20:53:04.96

あんたたち、まず、世界標準であるところの、マイクロソフトのGUIプログラミング
の構造を理解しなくては。基本は、MFCとWinForms。

**デフォルトの名無しさん** · 2021/11/30(火) 20:54:17.71

>>660
あなたは、ゲームで、それぞれのキャラクターが同時に動いて見えるのは、
非同期に動いていると思ってる人？

**デフォルトの名無しさん** · 2021/11/30(火) 21:02:11.91

>>661
マイクロソフトには興味ないのでどうでもいいです
シングルスレッドである限りは通信やI/O待ちで他へ切り替わらずに全体が止まってしまってはどうしようもありません
通信やI/O待ちになるところで他のタスクへ切り替わるのが普通のシステムです

**デフォルトの名無しさん** · 2021/11/30(火) 21:07:36.86

>>663
伝統的な理解では、その場合の、タスクというのは、JSのasyncのタスクの事
ではなくて、別のアプリの「プロセス」のことである事は分かってる？
JSのような意味でのタスクだと切り替えた瞬間にアプリがおかしくなってしまう。
だから、あなた自身が分かっているような「排他処理」が必要だと考えに至る。
ところが、MSが採用している標準的なGUIシステムでは、最初からそうならない
ようになっているから、その心配が無い。

**デフォルトの名無しさん** · 2021/11/30(火) 21:22:23.73

>>664
いいえ
ここでタスクと呼んでいるのはそのJSだけでなくRustでも同じで
シングルOSスレッドの中でも複数が動くタスクのことであって
別名グリーンスレッドと呼ばれる並行プログラミングでの単位のことです

シングルスレッド内のタスクの中でI/Oや通信待ちとなる時は他のタスクへスケジューラーが切り替えます
別タスクへ切り替えないとI/Oや通信待ちのままプログラムが動かなくなるからです

**デフォルトの名無しさん** · 2021/11/30(火) 21:31:24.72

>>665
その仕組みはどれくらい採用されているの。
世界標準は、マイクロソフトの MFCとWinFormsなんだが、それはそんな
仕組みは採用して無いぞ。

**デフォルトの名無しさん** · 2021/11/30(火) 21:37:25.41

>>666
マイクロソフトには興味がないので知りませんが並行プログラミングの常識ですよ
少なくともウェブブラウザで動くJavaScriptは通信I/O待ちで止まったままにはなりませんね
その間も例えば人間が操作すると反応するように他のタスクが並行して動いています

**デフォルトの名無しさん** · 2021/11/30(火) 21:50:24.93

>>667
JavaScriptはスクリプト言語だし、ブラウザのセキュリティー的にもあえてそう設計されているから、
C++やRustのようなコンパイル言語とは比較出来ないのでは？

**デフォルトの名無しさん** · 2021/11/30(火) 21:58:56.83

>>668
Rustでも普通にasync-stdやtokioを用いてシングルスレッドでマルチタスクの普通のプログラムを組むと全く同じですよ
もちろん通信やI/O待ちになると別のタスクへ切り替わります

**デフォルトの名無しさん** · 2021/11/30(火) 22:24:13.84

>>669
結局の所、Rustって基本は非同期で、プログラマが await-std や tokio を使って
明示的に非同期プログラミングするってことですよね。
それだったら C++ や Windows の WinForms/WPF アプリでも非同期プログラミングのフレームワークを使えば同じ事。

あなたのこれまでの投稿内容を見て、JavaScript では全てが勝手に非同期で動くと私は受け取りました。

**デフォルトの名無しさん** · 2021/11/30(火) 22:47:13.22

>>670
つまりWindowsのシングルスレッドのプログラミングでも通信I/O待ちになると他のタスクへ切り替わるわけですね

そうすると元々の話
シングルスレッド内でもマルチタスクならば競合を避けるために何らかの排他的な制御が必要、と合意できますよね
そしてその排他的な制御が無ければ他のタスクにより書き換えや削除も起き得るということがわかっていただけましたでしょうか？
リンクリストか否かに関わらず全てのデータ構造で。

**デフォルトの名無しさん** · 2021/11/30(火) 22:53:37.50

>>671
>つまりWindowsのシングルスレッドのプログラミングでも通信I/O待ちになると他のタスクへ切り替わるわけですね
Win32の場合、ファイルI/Oは、通常は同期式だが、特殊な場合には非同期に
することも出来ることは出来る。
しかし、その場合、プログラミングが難しくなるので上級者向きで、
初心者はやるべきではない。
その場合、もちろん、何らかのフラグで危険な状態になるのを防ぐ必要がある。

**デフォルトの名無しさん** · 2021/11/30(火) 23:04:55.17

>>672
このスレで初心者用のお子様向けメニューの話をしても仕方ないでしょ
現在プログラミング界ではasync/awaitが普通となっている現状で非同期プログラミングは当たり前のことなので
プログラムが難しくなるから同期だけ使う、というケースだけを前提に考えては駄目ですよ

**デフォルトの名無しさん** · 2021/11/30(火) 23:11:44.10

>>673
>現在プログラミング界ではasync/awaitが普通となっている現状で非同期プログラミングは当たり前のことなので
JS業界では耳にするが、C++業界では耳にしないな。

**デフォルトの名無しさん** · 2021/11/30(火) 23:18:26.84

「C++では安全なプログラムが難しい」
と思ってる人も、「非同期I/Oを使わなければ成らない」と思い込んでる人が
多いのかもね。
実際は、非同期I/Oは高度なので避けることが賢明と考えられている。
同期I/Oでもほとんどの場合は十分に機能を果たし、十分に高速なプログラムになる。
イバラの道を避けることで安全なプログラムが簡単に書けるようになる。

**デフォルトの名無しさん** · 2021/11/30(火) 23:30:35.59

>>674
async/awaitはJavaScriptだけだと思い込んでるの？？
PythonからC#まで幅広くサポートされている
もちろんRustもね

>>675
非同期が難しいって、初心者なのにこのスレにいるの？
あとawaitは同期するので初心者でも使うよ

**デフォルトの名無しさん** · 2021/11/30(火) 23:38:36.37

>>676
JSがある程度以上高度なプログラミングができないのは、非同期を使おうと
する人が多いからも有るかも。しかも、それを推奨したりする人が多くて。
簡単な方法で十分なのに、敢えてロジックがこんがらがる方法を使う必要は無い。

昔から言われていることとして、初心者ほど、マルチスレッドや、高度な
メッセージ通信、Mutexやセマフォなどの同期処理に興味を持ちやすい、
ということがある。

そして、上級者ほど、ほとんどの目的ではそれらを使わなくても
十分に良いプログラミングできることを知っている。

初心者ほど独特の複雑な記法を好み、一行で何もかも書こうとし、
関数に分けずにラムダ式で書こうとする。

上級者ほど、単純で平易な書き方をしようとし、複雑な記法や難しい
仕組みは避ける。

**デフォルトの名無しさん** · 2021/11/30(火) 23:51:36.86

>>677
あなたが全く理解できていないから
このスレに無関係なJavaScriptをデタラメに叩いている
メジャーな言語の多くでasync/awaitや類するものが導入されている
時代遅れのC++ですらC++20で半分だけ導入するらしいぜ

**デフォルトの名無しさん** · 2021/11/30(火) 23:58:50.35

数学100点マンの人が
同期プログラミングしか出来ない初心者だと判明したことが大きいな

**デフォルトの名無しさん** · 2021/12/01(水) 00:01:00.14

>>678
全く理解出来て無いわけではなくて、Promise や then() や await も
使ったことは有ることはあって、色々テストしてみたが、理解が難しい部分が
残るなとは思った。
で、俺は馬鹿だと思うかも知れないが、これでも数学100点連続マンだったからね。
少なくともそれ位は数学が出来たのに、Promiseが易しい概念だとは思わない。
e.responseWith()や、e.waitUntil()も未だにちゃんと理解出来てる自信が無い。
async関数をthenの中に入れているような場合も、ちゃんとは理解出来て無い。

**デフォルトの名無しさん** · 2021/12/01(水) 00:01:49.75

>>679
CやC++には、基本的にそのようなタイプの非同期システムは無いからね。

**ハノン** ◆QZaw55cn4c · 2021/12/01(水) 00:01:56.93

>>677
＞上級者ほど、ほとんどの目的ではそれらを使わなくても
＞十分に良いプログラミングできることを知っている。

金子氏も Windows を信用せず自前で並行処理を記述していたというし、しかし本当なのでしょうか？誰か解析してください…

**デフォルトの名無しさん** · 2021/12/01(水) 00:21:49.47

>>681
std::future

**デフォルトの名無しさん** · 2021/12/01(水) 00:37:59.70

>>680
Promise(言語によってはFuture)が難しいって数学も苦手なんだな
Promiseは単なる先物であって内部はpending/ok/error(言語によって名称など異なる)の状態を持つだけ
async関数はPromiseを返すだけだしawaitはpendingじゃなくなるのを待つだけ
thenの引数はokとなったら呼ばれるだけ
一方でresponseWithやwaitUntilは上述のような言語の基本構成ではなく
ブラウザのWeb APIに過ぎないからそこをまず区別できないと

**デフォルトの名無しさん** · 2021/12/01(水) 01:04:02.61

>>684
関数の最後に○○をreturnするとPromiseでラップされるとか、qiitaなどでは
見つけられたんだが、公式サイトで見つけられなかった。
それと実際色々実験して見ると、単にコールバック関数を登録していると
すれば予想される順序とは異なった順序でconsole.log()文が呼び出されて
いたりした。
その順序はとても独特だった。

また、Proimseを解説する記事において、Aを解決するBなどという言葉が
多用されていたが、その定義を見つけられなかった。
推定は出来るが。しかし、定義が無いと分かりにくい。

**デフォルトの名無しさん** · 2021/12/01(水) 01:30:16.63

>>685
公式を見なさい
RustではPromiseはFuture traitでゼロコスト設計
https://doc.rust-lang.org/std/future/trait.Future.html
Futureはpoll()を持ち呼ばれると以下の2状態いずれかを返す
・Poll::Pending
・Poll::Ready(val)　【Rustではエラー状態はなくResult<正常値,エラー値>で返す】
https://doc.rust-lang.org/std/keyword.async.html
asyncはFutureを返す

JavaScriptがそんなに好きならこちら
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise
Promiseは以下の3状態を持つ
・pending
・fulfilled　【正常値が得られた時】
・rejected　【エラー値が得られた時】
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function
asyncはPromiseを返す

このように概念は全く同じ
ただしJavaScriptはPromise作れば自動的にスケジューラーに登録されてタスク切り替え実行されるが
Rustはゼロコスト設計だからFuture作ったら自分で好みのスケジューラーに登録してタスク切り替え実行される
もし非同期プログラミングが不得意ならば数学も不得意だろう

**デフォルトの名無しさん** · 2021/12/01(水) 01:33:52.46

>>686
というか、Promiseは自分では使いたくないから興味が沸かないし、
実験する時間も取りたくないのに、サンプルなどでは大量に使われてる
場合が多いからもある。
意味が無いものには興味が沸かないというか。

**デフォルトの名無しさん** · 2021/12/01(水) 01:36:10.77

なお、俺が数学が不得意に分類されるなら、全人口の99.99%位は数学が
超不得意になるだろうな。

**デフォルトの名無しさん** · 2021/12/01(水) 01:45:02.34

一生そのままRustにも興味持たないで平和に暮らしてくれ
意味無いから

**デフォルトの名無しさん** · 2021/12/01(水) 01:46:47.59

Promise知らないことは単なる知識。
O(1)やリンクリストの話は、イマジネーションの世界だから生まれつきの
頭の良さの影響が大きい。
Promiseを知らないことを馬鹿にされても、俺の意見が間違っていることには成らない。

**デフォルトの名無しさん** · 2021/12/01(水) 01:52:57.27

明らかに間違ってるのに、俺を馬鹿にしてくるのは、この分野は、
博士課程などにも馬鹿が多いからかもな。
どうみても生まれつきの頭は大したことが無いのに、大学に残ってるような
人が多い分野。
それで馬鹿なのに勘違いして、明らかに間違ったことをいつまでも信じ続ける
人が居る。
さらに悪いのは間違ったことを流布してしまう。

**デフォルトの名無しさん** · 2021/12/01(水) 01:53:04.71

rustの非同期ランタイムは非標準ライブラリで提供されているからフリースタンディング環境でも使えるものがあったりするんだけど
c++ の future とかコルーチンってその辺どうなんですか？

**デフォルトの名無しさん** · 2021/12/01(水) 02:18:40.66

非同期と同期のどちらがよいかは場合によりけりでしょ。
複数のクライアントから同時接続されるサーバだとあるクライアントと通信している間に別のクライアントからの要求を処理しないと効率悪いだろうし。
ネットからファイルを一つダウンロードして解凍して中のファイルを読み込むだけのプログラムだったら前の処理が終わらないと何もできないから同期処理で十分。

**デフォルトの名無しさん** · 2021/12/01(水) 02:25:30.27

>>690
知るか知らないかではなく
理解できるか理解できないかの違い
もし非同期プログラミングが出来ないならば数学も弱いとわかる

>>693
後者の初心者向けプログラミングだけしか理解できずに終わるか
それとも前者の普通のプログラミングもできるようになるかの違い

**デフォルトの名無しさん** · 2021/12/01(水) 02:58:41.60

>>694
需要が無いのに知っていることを自慢するって、真空管技術を知っていて
偉いと思ってるのと同じようなことだと思うが。

**デフォルトの名無しさん** · 2021/12/01(水) 03:01:24.50

>>693
通信の場合、マルチスレッドプログラミングなら意味はあることもあるな。
しかし、単一スレッドで非同期にすることにどれだけ意味があることか。

**デフォルトの名無しさん** · 2021/12/01(水) 03:15:28.24

>>695
需要があるから使われているし
さらに利便性を高めるためにどの言語もasync/await導入したり導入検討している

>>696
例えば1000か所から通信でデータを取ってくる場合
(1)順番に同期的に一つずつ順に1000回処理するの？
(2)マルチスレッド1000個生成するの？
(3)普通はシングルスレッドかCPUスレッド数(2個とか4個とか8個とか)分までのマルチスレッドにてスレッド内マルチタスクをして実行します

このようにマルチスレッドでも各スレッド内では複数のタスクが非同期に多数動きます

**デフォルトの名無しさん** · 2021/12/01(水) 03:22:45.28

>>697
使用用途は、通信に限られるような気がするな。
余り一般化して欲しくない。
面倒だから。
それになんかわかりにくい。

**デフォルトの名無しさん** · 2021/12/01(水) 03:42:46.81

>>698
このネット時代では通信しないアプリの方が例外的な特殊な存在
そして通信だけでなくヒューマンインタフェースも非同期に発生
その『それになんかわかりにくい。』から数学が苦手だと予想します

**デフォルトの名無しさん** · 2021/12/01(水) 04:21:18.83

OpenGLやCUDAでもGPUに処理をお願いする関数を呼んだら計算が完了する前に戻る非同期処理は一般的に使われているよ。

**デフォルトの名無しさん** · 2021/12/01(水) 07:22:02.74

>>698
GUIなアプリは非同期プログラミングが避けられないと思うぞ
でないと、何か処理するごとにユーザーに待たせることになる
シングルスレッドでも工夫次第で待たせなくは出来るが、かえって実装が複雑になってしまう

**デフォルトの名無しさん** · 2021/12/01(水) 08:05:39.60

>>701
ブラウザ上で動いているJavaScriptはシングルスレッドですが
スレッド内で非同期に複数のタスクが動くのでGUIに対応出来ています
例えばマウスが動いたりクリックされたりするたびに次々と新たなスレッドが起動したら重すぎて困ります
プロセス起動よりは軽いとはいえスレッド起動はかなりのコストがかかります
だからマルチスレッドではなくシングルスレッドで動いています
このようにシングルスレッド内で並行プログラミングできるところが非同期プログラミングの良いところです

**デフォルトの名無しさん** · 2021/12/01(水) 08:19:28.96

これはサーバー側も同じです
今どきサーバーは数万のクライアント接続が同時に来ても捌けますが
これを数万のスレッド起動で実装したらリソースが足りず動きません
実際にサーバーが使用するスレッド数は最大でも使用CPUが同時実行できるスレッド数で8個とか16個などだけです
したがってそのスレッド各々が何千や何万のクライアントを相手に並行して非同期に処理しています

**デフォルトの名無しさん** · 2021/12/01(水) 08:56:34.20

Windowsアプリの件はわかる気がするわ。
Wixdowsアプリ(イベントドリブン)はイベントのキャッチはシングルスレッドでやっているのでイベントの実行から終了は全て同期処理。
ただし、イベントの実処理(中身)は非同期で実行する(しているケースが多い)からイベントの実処理が終わらずとも次のイベントが実行されているってことなんじゃない？
イベントドリブンの認識間違ってたらごめんね

**デフォルトの名無しさん** · 2021/12/01(水) 10:40:28.38

数学100点の人はgoやったら良いのでは
同期プログラムと同じ書き方で非同期になるよ

**デフォルトの名無しさん** · 2021/12/01(水) 11:14:17.47

>>705
同期プログラムと同じ書き方といっても局所的な表面上だけだからgoroutine間のやり取りや制御で理解できなくなると思われる
そして同期プログラムと同じ書き方という点ならばasync/awaitサポートする任意の言語でawaitを付ければ同期的にプログラミングできるわけだけどこれも彼には厳しいかも

**デフォルトの名無しさん** · 2021/12/01(水) 18:57:51.36

posixシグナル完全対応。

**デフォルトの名無しさん** · 2021/12/01(水) 20:55:01.67

>>706
そんな...
数学100点なのに比較的学習が容易とされているgoも使えないなんて悲しすぎる

**デフォルトの名無しさん** · 2021/12/01(水) 21:05:34.73

彼がしきりにアピールする東大の入試数学やセンター試験の出題範囲だとBASICがせいぜいだから
非同期やデータ構造に対する理解を求めるのが酷だったか

**デフォルトの名無しさん** · 2021/12/01(水) 22:03:37.03

東大の品位を下げるようなことはやめてくれ

**デフォルトの名無しさん** · 2021/12/01(水) 23:31:46.90

センターでBASIC出題って何年前よオイ

**デフォルトの名無しさん** · 2021/12/02(木) 01:07:51.06

2015年まであったらしい

**デフォルトの名無しさん** · 2021/12/02(木) 02:35:29.16

>>704
イベントではなく、シングルスレッドでメッセージキューに溜まったメッセージを
1つづつ取りだして処理するので、1つのメッセージ処理実行中、同時に別のメッ
セージ処理が実行されることはないので、排他処理が要らない。

ところが、メッセージ処理の中で受信待ちとか発生するコードだと、タイムアウト等で
抜けるまでメッセージ処理が終了しないので、ウィンドウ再描画などのメッセージも
処理されず、見かけ上GUIが固まったようになる。

だから、通信とかは、マルチスレッド化する必要がある。　C/C++はOSが走ってない
ワンチップマイコンのソフト開発にも使われるので、言語仕様にスレッドを持ち込む
必要はないと思う。

**デフォルトの名無しさん** · 2021/12/02(木) 11:04:55.74

関係ないけどautoが動的な型付けだと思ってたわ
auto = automaticだろ
名前負けしてんじゃねーよ
クソ言語か

**デフォルトの名無しさん** · 2021/12/02(木) 11:36:20.37

>>714
仕様で明確に定義されている以上、そんなアホな勘違いするやつが悪い。

**デフォルトの名無しさん** · 2021/12/02(木) 13:28:19.92

>>702
さすがにこの理解はないわ
もうちょっと勉強したほうがいいぞ

**デフォルトの名無しさん** · 2021/12/02(木) 13:37:53.33

>>716
合っとるよ
そのへんはC10K問題などで知見が広まりプロセスやスレッドを増やすのではダメだと結論出ている
それ以降はスレッドの中で非同期にどれだけ多数のタスクをこなすかが勝負となった

**デフォルトの名無しさん** · 2021/12/02(木) 15:03:03.48

Cのauto
C++のauto
本来の仕様は一緒のはずなのに使われ方が違ってて笑う

**デフォルトの名無しさん** · 2021/12/02(木) 17:16:10.79

だって誰も使わなかったし……

**デフォルトの名無しさん** · 2021/12/02(木) 17:21:01.57

次は　register がつぶされる番ですねっ

**デフォルトの名無しさん** · 2021/12/02(木) 17:29:10.36

>>718
そんな事で笑ってたらC/C++を覚えるまでに笑いすぎて死ぬぞ

**デフォルトの名無しさん** · 2021/12/02(木) 20:09:00.51

>>415-416 シークする必要どうのこうの
>>583 アクセス用にArrayListを使う例
この辺↑の話題のやつを実装してみた
Rc<RefCell>をまず共有しておいて、中身へのborrow()や
borrow_mut()は最小限の時間で行えば十分じゃないかな？　ダメ？
実行時にうまく中身を借用できているかは使う人次第ってことになる

https://ideone.com/bd0cFx
・注意：双方向リストだけど循環参照は未解決のまま
・注意：要素への参照を使っての操作はリスト側には未反映
　（front, backを正しく再設定し直したりはしないということ）
　（両端の要素の外側に追加したときとかおかしくなるはず）
・手元の1.8.0で主に動作チェック
・基本的によく分かってないので妙な箇所があるはず
・イテレータを提供したかったがよく分からなかったので諦めた
・fmt::Debug for LinkedList<T>は本来はもっとスッキリ書けるはず
・push_prev(&self, h)などが何も返さないのは、selfを返すかhを返すか
　どっちを返すのが自然なのかという判断に迷って決め切れなかったため

**デフォルトの名無しさん** · 2021/12/02(木) 21:02:35.79

>>717
クライアントの話なのにC10K持ち出して
しかも無知晒しただけやんw

**デフォルトの名無しさん** · 2021/12/02(木) 21:38:58.00

c10kはリソース問題だからブラウザサイドでも同じだよな
5chのページとか見ると多数の広告やら何やら大量にコネクション貼りに行くけど非同期で並行にシングルスレッドでも余裕で可能
これが同期プログラミングしかできない人が作ると数十のコネクションに数十のスレッドを無駄に使うか
もしくはシングルスレッドで1つずつ順に時間をかけるかのどちらかとなる

**デフォルトの名無しさん** · 2021/12/02(木) 21:47:37.10

広告アクセスに時間がかかるなんてのはc10kと全然関係ないだろう

**デフォルトの名無しさん** · 2021/12/02(木) 22:21:10.00

コネクション多数確立するという意味では同じだがC10Kと比較するのはおおげさすぎる
今時のブラウザは非同期処理の塊だろうからもっと良い例あるのでは

**デフォルトの名無しさん** · 2021/12/02(木) 22:30:51.78

ブラウザではそもそもHTML5の登場までマルチスレッド自体使えなかったし
そんな中でもAjaxでイベントによる非同期処理は要求されたし

ブラウザjsに関して言えばマルチスレッドのオーバーヘッドに耐えられず必要に駆られてっていう理由ではなく
従来のイベント非同期をPromiseで簡便に書けて、async/awaitでもっと簡便に書けて喜ばれた、というのが正しい理由でしょうね

**デフォルトの名無しさん** · 2021/12/02(木) 22:41:56.03

>>724
それブラウザがマルチプロセス・マルチスレッドで仕事をこなしてるからGUIアプリとして使いものになるんだぞ

まさかJavaScriptだけで実現できてると思ってたのか？

**デフォルトの名無しさん** · 2021/12/02(木) 22:45:23.47

どこかのスレで見たグリーンスレッド知らないおじさん？

**722** · 2021/12/03(金) 00:10:46.04

>>722
https://ideone.com/IY3aFj
・イテレータを提供
・impl Debug for LinkedListも若干スッキリ

**デフォルトの名無しさん** · 2021/12/03(金) 00:22:36.68

>>722
リスト構造ってほとんど使わんなぁ。　C++だとインスタンスの配列じゃなくて、
インスタンスへのポインタ配列を使えば、配列サイズの拡張に伴う領域確保とコピー
が行われるのは、配列要素であるポインタだけなので、要素数が増えようが、複雑な
オブジェクトだろうが、処理時間は最小限で済む。

リスト構造の欠点はソートに弱いこと。　オブジェクトインスタンスへのポインタ配列
ならソートの場合でも、ソート対象はポインタの並び替えだけで、ポインタが指す
オブジェクトのインスタンスには一切触らない(コピーや再配置は行わない)で済む。

「100日後に退職する47歳」に出てくる「クイックソートの計算量」なんて質問をする
面接官は、記憶力が全ての学力試験が産んだ馬鹿でしかない。　現実問題としては、
ソートする必要がある時はソートしなければならない。　聞くべきは『効率的にソート
するには、どんなデータ構造を採用すべきか』である。

**デフォルトの名無しさん** · 2021/12/03(金) 00:34:51.88

リスト構造も結局のところポインタやん

**デフォルトの名無しさん** · 2021/12/03(金) 00:38:41.22

>>697
GUIスレッドの裏で動く、通信専用のワーカスレッドを1つ作成して、順番に1000個
のサーバヘアクセスに行くのが簡単かつ現実的じゃないかな。

むろんコア数を調べてワーカスレッド数の上限を可変にしてもいいが、アクセス先
リストの消し込みやエラー処理とか自動リトライとか面倒になるし、そこらを頑張っ
たところで、実際のところほとんどの場合は回線速度で頭打ちになる。

それと、たとえスレッドが1000個作れても、実際の環境では、経由するルータや
相手サーバ側の制限などで、同じIPアドレスから、同時に1000個の通信セッション
が張れないことの方が多い。

**デフォルトの名無しさん** · 2021/12/03(金) 00:40:38.11

n番目の要素とm番目の要素を入れ替えるのに
配列だとポインタの読み込み2回、書き換え2回で済むのに対し
単方向リンクリストだと読み込みmax(n, m)+4回、書き換え4回必要になるからこれだけでかなりの差が生じる