C++ vs Rust

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

競え

**デフォルトの名無しさん** · 2021/11/29(月) 02:59:57.67

ベンチマークとかはどうでもいいが、
CだろうがRustだろうが実装可能って話にしか見えん

**デフォルトの名無しさん** · 2021/11/29(月) 07:57:57.28

>>538
これな。
結局のところ実体へのポインタの配列であればリンクトリストになってなくても話は同じなんじゃないかな。

**デフォルトの名無しさん** · 2021/11/29(月) 08:02:08.66

実体へのポインタの配列だけでいいよなｗ
それで実体にはすべて到達できるもんｗ
ある実体の次も、前も、それも両方分かるしｗ

**デフォルトの名無しさん** · 2021/11/29(月) 10:19:47.16

抽象はabstract

**デフォルトの名無しさん** · 2021/11/29(月) 11:26:03.41

>>579
違う。
リンクトリスト + 配列だと >>538 が指摘している現象が生じてしまうが、
リンクトリスト + リンクリストだと生じない。

こういっても、数学力の無い人は理解できないだろうな。
数学力は数学という学問だけの能力ではなくて、脳内のワーキングエリアや
イマジネーションなどに関係しているから、生まれつきの影響が大きい。

**デフォルトの名無しさん** · 2021/11/29(月) 11:29:51.75

>>582
[補足]
抽象的理解が難しい人に具体的に書いておいてやろう。
LinkedList ll;
ArrayList al;　//自動伸張方式の動的配列だと仮定する
al[0] = ll.append("りんご");
al[1] = ll.append("みかん");
al[2] = ll.append("バナナ");
だと >>538 が指摘しているような不具合が起きる。しかし、
LinkedList ll;
LinkedList ll2;
ll2.append( ll.append("りんご") );
ll2.append( ll.append("みかん") );
ll2.append( ll.append("バナナ") );
だと起きない。

**デフォルトの名無しさん** · 2021/11/29(月) 11:36:08.77

>>583
中身が同じリストを二個用意しても意味がないのでもう少し実践的な例の方が理解のためにはよろしいのでは
スキップリストみたいな構造とは違うのですか？

**デフォルトの名無しさん** · 2021/11/29(月) 11:36:25.33

>>583
もっと具体的に書いてやろう。
リンクリストの中の追加した6つの果物の内、4つを他の配列やリンクリストの
中から参照する例を示しておこう。
これの応用としてリンクリスト内の1000個の品物の内、何らかの条件で選び取った10個を
別の配列やリンクリストから参照することが出来る。

1. リンクリスト + 配列
LinkedList ll;
ArrayList al;　//自動伸張方式の動的配列だと仮定する
al[0] = ll.append("りんご");
ll.append("みかん");
al[1] = ll.append("バナナ");
ll.append("すいか");
al[2] = ll.append("パイナップル");
al[3] = ll.append("ブドウ");

2. リンクリスト + リンクリスト
LinkedList ll;
LinkedList ll2;
ll2.append( ll.append("りんご") );
ll.append("みかん");
ll2.append( ll.append("バナナ") );
ll.append("すいか");
ll2.append( ll.append("パイナップル") );
ll2.append( ll.append("ブドウ") );

**デフォルトの名無しさん** · 2021/11/29(月) 11:36:55.60

>>584
>>585 を見ろ。

**デフォルトの名無しさん** · 2021/11/29(月) 11:39:40.44

>>585
これがどういう時に起きるかといえば、最初に1000個の品物の入った
リンクリスト ll がある時、条件に合う品物を1つ探してリンクリスト ll2
の末尾に参照を追加する。
それを10回繰り返した後に、実質的に生じる。

**デフォルトの名無しさん** · 2021/11/29(月) 12:08:42.24

>>587
queryに対する抽出結果をリストとして保持しておいて元のリストの更新に応じてquery結果も適宜更新されるイメージですか？

**デフォルトの名無しさん** · 2021/11/29(月) 12:10:54.78

一部のノードが2つのリストで共有されてんのこれ？

**デフォルトの名無しさん** · 2021/11/29(月) 12:15:46.59

l2のリストに入れる数によって変わるので結局O(N)の操作じゃね？

**デフォルトの名無しさん** · 2021/11/29(月) 12:42:23.24

>>590
正確にはll2のサイズN_ll2の半分に近づくね。
ll2のサイズが大きくなるなら、大きめに初期化するのが無難。スカスカならバランス木のmapかね。

**デフォルトの名無しさん** · 2021/11/29(月) 12:43:56.81

リンクリストを少し調べたところ様々な種類のものが使われているようで
様々な分類が生じるうち今回関係するノードの参照については以下の4種類あるようだ

(A) データを挿入しても作られたノード自体は返さない方式
実際にこの仕様でも困らない用途も多いようでこの方式も普通に使われている
もちろん問題は何も生じない

(B) データを挿入して作られたノードのポインタを直接返す方式
これは危険で最も推奨されない方式
ポインタを握っていても使う時にそのノードは削除されているかもしれない
削除で開放されてヒープに戻され更に再利用されているとデータの中身もnext辿りも滅茶苦茶になりうる
そしてデータの扱い次第で実際に削除は起き得るしUI人間や通信相手から発動ルーチンでの削除も有り得る

(C) データを挿入して作られたノードの(一般的な)スマートポインタを返す方式
これはshared_ptrなど安全とされているスマートポインタを返すためメモリ使用上は安全
しかしポインタ先がヒープへ戻されていないことしか保証がない
つまり(B)と同様にリンクリスト自体からの削除が起きている可能性がありそれを知る方法がない

(D) データを挿入して作られたノードを管理しているリンクリスト内部の何らかを返す方式
リスクの高い(B)や(C)と異なりこの方式は安全かつ整合性が維持される
もしノードがリンクリストから削除されていればそれに対して対応ができる
この返されたデータを用いて新たなデータをその位置に挿入する時に元ノードが削除されていた場合
(D)-1. 挿入はされず既に元ノードが削除されていると知らせる
(D)-2. 知らせずに削除された元ノードの次に有効なノードの位置に挿入する
などリンクリストの仕様や用意されたメソッドにより異なるようだ

以上まとめると現実的に安全に使える方式は(A)もしくは(D)となっている
例えばC++の標準リンクリストstd::listでもこの(D)方式を採用しており
insert()はリンクリスト上をその位置から順に辿っていくイテレータを返す

**デフォルトの名無しさん** · 2021/11/29(月) 12:52:17.03

>>585みたいなことできる連結リストって、
Rustでも作れると思うんですけど
Unsafe全振りにはなると思うけど

**デフォルトの名無しさん** · 2021/11/29(月) 13:00:24.04

>>593
rustだけはsafeじゃないとだめらしいですよ

**デフォルトの名無しさん** · 2021/11/29(月) 15:16:40.92

> 2. リンクリスト + リンクリスト

それだとさあ
最初から主張してるO(1)ランダムアクセスできないけどいいのｗ
配列だからこそi番目が定数時間でa[i]でアクセスできるんでしょ

**デフォルトの名無しさん** · 2021/11/29(月) 15:56:54.32

>>592
やはりポインタを直接返さないんだな
ポインタだけもらって保持していてもそのノードがリンクリスト上でアクティブかどうかすらわからないもんな

**デフォルトの名無しさん** · 2021/11/29(月) 16:56:11.45

C++ の std::list はポインタではなくイテレータで扱うけど、実質ポインタと同じだぞ。
Debug ビルドだと二重 erase は検出してくれるけど、Release ビルドだとセグフォで落ちる。

**デフォルトの名無しさん** · 2021/11/29(月) 17:12:06.45

そもそも途中ノードのポインタを保持していても普通の使い方だとそこへ挿入することないよな
リンクリストの先頭挿入か最後挿入かあるいは何らかのデータ順になっていてその位置に挿入だよな
可能性があるのはエディターくらいだけどそれならばカレントポジションをエディター用リンクリストの中で保持した方が便利

**デフォルトの名無しさん** · 2021/11/29(月) 17:31:01.57

ポインタだらけのデータ構造ってそれをファイルに保存するとかネットで繋がった別のマシンに送るのって大変じゃない？
ポインタの代わりにインデックス使ってればそのままシリアライズできるけど

**デフォルトの名無しさん** · 2021/11/29(月) 17:39:15.23

というか std::list はメモリも速度もコスト高いし、普通は std::vector を使う。
途中への挿入・削除が頻繁に発生するようなら std::list の使用も検討するべき。

ノードが既に分かっているとして、当該ノードの保持する値へのアクセスが O(1) で
行えるのは当たり前の話で、これが出来ないコンテナって存在するのか？
リンクリストは（既に分かっている）ノードの削除、
（既に分かっているノードの前後への）挿入が O(1) で行えることに意味がある。

**ハノン** ◆QZaw55cn4c · 2021/11/29(月) 19:03:52.90

>>585
C でも rust でもいいから動くソースを出してもらえませんか？ここ、確かプログラム板でしょ？

**デフォルトの名無しさん** · 2021/11/29(月) 19:45:36.73

>>599
多くのケースではシリアライザ手書きしないから気にならないのでは
例えばrustならserdeがLinkedList対応してるからVecと同じ手軽さでシリアライズ・デシリアライズできると思われる

**デフォルトの名無しさん** · 2021/11/29(月) 19:59:41.83

>>602
その中の切れ端へのポインタをもらってどうするの？って話だから話がずれてる

**デフォルトの名無しさん** · 2021/11/29(月) 20:15:59.10

リンクリストのノードをさらにリンクリストにいれてなにがしたいんだ

**デフォルトの名無しさん** · 2021/11/29(月) 20:28:16.85

>>604
リンクリストはポインタだからO(1)で速い！とナゾ主張する勘違い君がさらに暴走した結果

**デフォルトの名無しさん** · 2021/11/29(月) 21:15:38.25

>>603
普通にVec相当の構造に変換された上でシリアライズされてデシリアライズ時にlistに変換されるよ

**デフォルトの名無しさん** · 2021/11/29(月) 21:27:48.38

>>606
それ怪しいな
LinkedList型はser/de定義されていて先頭保持してるところから順にたどって全体を巡るとして
途中ノードのポインタを渡されてもまずそのノードだけ対象になるのかそれとも次をたどるのか曖昧
もし同じように順にたどるとしてもLinkedListの一部分が出来上がりそれに意味があるのか疑問

**デフォルトの名無しさん** · 2021/11/29(月) 21:32:39.40

そりゃsafety売りにしてる言語が実はunsafeばっかとか言えませんよね。普通の感覚ならね。

**デフォルトの名無しさん** · 2021/11/29(月) 22:50:59.13

>>607
CursorではなくてLinkedListのシリアライズに対応してるから必ずリストの先頭からのシリアライズ

>>608
なぜ？
safeを売りにするという言葉をどのように解釈しているの？

**デフォルトの名無しさん** · 2021/11/29(月) 22:59:12.77

あわしろ氏はC++の危険性を見過ごせないと言ってた。
ダングリングポインタは諸悪の根源と言える。

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

他の言語なら危険でないとでも？

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

>>595
ll2にllの検索条件に合うノードのポインタを順に入れて言った場合、
llのノードが順序がバラバラで入っていることになり、
ll2を先頭から順にシーケンシャルアクセスすると
llはランダムアクセスされることになる。
なお、ランダムアクセスとはシーケンシャルアクセス以外のアクセスを全て指す
言葉。

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

>>612
もちろん、O(1)だ。

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

>>612
> ll2にllの検索条件に合うノードのポインタを順に入れて言った場合

なぜポインタを辿って遅くて不便なリンクリストを使うの？
順に入れるならベクタを使えば速くてメモリも食わないのに

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

>>614
そこをベクタにしてしまうと、せっかくのリンクリストの特性であるところの
O(1)性が完全な意味では維持できなくなるからだよ。

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

リンクリストは、損して得取れの考え方だからね。
配列は、ちょっとしたことで使うには良いが、
一見得してるようだが、複雑なことをやる場合には損することが多い。

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

>>615
リンクリストはランダムアクセスO(n)で遅いから特殊な用途でしか使われていない
ほとんどのケースではランダムアクセスO(1)のベクタが使われている
シーケンシャルアクセスだけならどちらも同じだけどポインタをたどるリンクリストは遅くてメモリも余分に使って結果不利

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

>>617
アホは黙っててくれないかな。
俺は数学100点マンなんだぞ。
お前は完全に間違ってる。

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

今後、秀才か天才しか書込み禁止。
そうでないと、まともな議論にならない。
IQ130以上限定。

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

数学100点マンがなんだ俺はセンター数学2科目200点マンだぞ

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

東大入試数学満点、数オリ経験者のオレ登場

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

>>621
今までの論争？についてどうですか？

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

>>622
細かくは読んで無いけど
限定がなければ当然同じ計算オーダーの構造は作れるはず
いずれもリソースを限定しなければチューリング完全な言語であるわけだから

あとは限定次第
特定のコンテナを使う場合とか安全性とか
各言語での流儀とか

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

計算可能性と計算オーダーは関係無かったか
2文目は取り消しでお願い

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

>>623
>限定がなければ当然同じ計算オーダーの構造は作れるはず
>いずれもリソースを限定しなければチューリング完全な言語であるわけだから
確かに同じ計算オーダーの構造は作れるが、制限を回避するためにかなり遅くなる。

例として、参照もポインタも無いBASIC言語で、配列だけを使ってポインタを
模倣することも可能ではあり、実際にポインタと同じような計算オーダーを
持つものをそれでも実現可能ではあるが、「速度係数」が大きくなる。

Rustの場合、safeモードでは、1つのリンクリストに対して、読み書きが出来る
参照を複数同時にはマシン語レベルの生アドレスとしては持つことが出来ない。
その制約を回避するため、別の配列をわざわざよういして、アドレスの代わりに
配列の添え字番号を持つ整数型を参照型の代替として用いるやり方が、
提示されていた。

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

>>625
Rustでも生ポインタを使えば制約は一切ない
ソースコード>>542

さらにリンクリストで生ポインタを返すのは危険なので一般的にもっと安全な形が取られている
リンクリスト分類まとめ>>592

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

>>626
あなたは、秀才じゃないでしょ。
分かるから。
言ってること的外してるし。

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

safe Rustが要求するレベルの安全性（特に共有参照が存在する間はそれを変更できない）を実現するには、
C言語だろうとC++だろうと排他機構が必要になって、実行時コストを払わずに行うことは不可能

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

>>628
C++は、プログラマが自分の頭で考えて、安全性を確保する思想だから、
あなたの言ってるコストは元々必要ないという思想。

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

>>629
聞いたことないが誰の言葉？

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

>>629
[補足]
なお、マルチスレッドにおける、排他制御はCやC++では必ず必要。
それはプログラマが頭で考えても省略できない。

なお、シングルスレッドにおける Rustの借用規則のような仕組みを
に「排他制御」という言葉は通常は使わない。

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

>>630
あなたも秀才じゃないでしょ。
書いてあることで分かる。

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

イテレータをポインタだと思ってやっぱ複雑なC++じゃなくてC言語で話そうとか言っちゃう人が自分の頭で考えて安全性確保できる秀才ってマジですか

**デフォルトの名無しさん** · 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で半分だけ導入するらしいぜ