C++相談室 part151

**デフォルトの名無しさん** · 2020/05/14(木) 11:53:25.59

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part150
https://mevius.5ch.net/test/read.cgi/tech/1584975873/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

テンプレここまで

**デフォルトの名無しさん** · 2020/06/13(土) 17:06:07.88

>>293
よく読んでなかったわｻｰｾﾝｗｗｗｗｗｗｗｗｗｗｗｗ

>>292ので
>デストラクタ内で対処を完結させろ (例外を投げずに済ますために)
のアッパーコンパチになるのだから結果オーライで
オール無問題、

**デフォルトの名無しさん** · 2020/06/13(土) 20:11:16.15

個人でｃ＋＋使うことは少ないですか？
C#やelectronと比べて何倍手間がかかりますか？
２ｄのタイルマップエディタのようなものを作りたいのです、、、
https://www.mapeditor.org/

**デフォルトの名無しさん** · 2020/06/13(土) 20:19:12.06

挫折するリスクも加味すると100倍くらいじゃないかな

**デフォルトの名無しさん** · 2020/06/13(土) 20:42:52.21

>>295
個人の場合、実はC++は適している。
むしろ、大人数の場合、いろいろなレベルの人がいるので速度を落としてでも、
誰でも使えるような言語を使おうとする企業が多い。
ちゃんとしたものを作りたかったら、C++は最良の選択。

**デフォルトの名無しさん** · 2020/06/13(土) 20:55:51.74

ところで、全く関係ないけど、昔は、
標準変換(Standard Conversions)の1つに、
「Reference Conversions(参照変換)」
という項目があったのに、C++17では、Overload Resolution関連で
「Reference Binding(参照束縛)」
という項目だけになってしまった、という認識であってますかね？
もしかしたら古すぎて、もう分からないかな。

**デフォルトの名無しさん** · 2020/06/13(土) 21:10:55.91

c++がどうこういうこと自体無意味な気分。
OSとコンパイラのバージョン指定でもせん限り、特定の議論にもなりゃしない。

**デフォルトの名無しさん** · 2020/06/13(土) 22:13:05.14

これから始めようと思うのですが
C++とC♯の大きな違いは何ですか
どっちから先の方が良いですか？

**デフォルトの名無しさん** · 2020/06/13(土) 23:19:47.34

何作りたいかによるとしか言いようがない

**デフォルトの名無しさん** · 2020/06/13(土) 23:29:25.22

あーじゃあ、C++には何が出来なかったせいで
後からC♯が作られたの？

**デフォルトの名無しさん** · 2020/06/14(日) 00:35:35.69

違うよ

**デフォルトの名無しさん** · 2020/06/14(日) 00:45:05.04

んーでは、C++が劣っていてC♯が作られた理由は？

**デフォルトの名無しさん** · 2020/06/14(日) 00:55:29.50

インタープリ夛ー

**デフォルトの名無しさん** · 2020/06/14(日) 00:58:40.28

Javaの代わりが欲しかっただけであって優劣の問題はあまり関係がない
が結局Javaの領域には食い込めず、スクリプト言語の代わりになった
自由度を奪う代わりに楽に書けるみたいな
結局自由度が必要なのでC++から離れられないので余計書くのがつらい仕様になった
Win32APIのインクルードくらいＳＤＫにまとめとけやPinｳﾞｫｹって感じ

**デフォルトの名無しさん** · 2020/06/14(日) 01:08:08.89

インタープリティアひとつつくっておけば色々な環境に使い回せるし版権問題にうるさいJavaをぶっつぶすため

**デフォルトの名無しさん** · 2020/06/14(日) 01:08:40.52

>>306
> Javaの代わりが…スクリプト言語の代わりになった

なるほどぉ、それでunityのスクリプトになってるのか、
C++の自由度って具体的には何を指すんですか？

**デフォルトの名無しさん** · 2020/06/14(日) 01:17:15.70

常識だろjk

**デフォルトの名無しさん** · 2020/06/14(日) 01:21:41.82

C++はアルゴリズムの部品化が一般的になっているので、自由に組み合わせられるところが、良いと思います。

**はちみつ餃子** ◆8X2XSCHEME · 2020/06/14(日) 01:33:23.99

>>308
やりたければメモリのどこにでもアクセスできるってのが特に重要な違いかな。
デタラメなアクセスをしても実行時エラーとして検出されるとは限らない。

プログラマがメカニズムを理解して正しくプログラムを書けるなら (監視して実行時エラーを検出するための) 保護機構は無駄で、
余計なものがある分だけ実行速度が落ちるから無い方がいい。
それが C++ の基本思想であるゼロオーバヘッドの原則。

でも現実はそうではない。 (プログラマは間違う。)

**デフォルトの名無しさん** · 2020/06/14(日) 01:35:24.50

C++で出来るんならいったい、C++の何が悪くてC♯が産まれたのやら
さっぱりですね、
Wikipedia見にいったらc#はBoolean型とスイッチケースでストリング型が使えるそうなので
c＃にしようと思います
お邪魔しましたわ、ありがとうございました。

**デフォルトの名無しさん** · 2020/06/14(日) 01:41:28.38

c#を選択するのは悪くないと思うが、そこじゃないだろ

**デフォルトの名無しさん** · 2020/06/14(日) 01:45:14.17

あーうーん、自然言語処理とかネットのデータベースで
文字列比較を多用しそうな予定は未定なので・・

**デフォルトの名無しさん** · 2020/06/14(日) 02:22:12.57

>>298
MSDNのC++の仕様書を見ると、まだちゃんと Reference Conversionsの
項目があった。
C++17には無い項目だ。

**デフォルトの名無しさん** · 2020/06/14(日) 03:45:35.31

文字列処理がメインで速度求めないならpythonとかの方がいいと思うぞ

**デフォルトの名無しさん** · 2020/06/14(日) 03:48:19.28

>>312
>C++で出来るんならいったい、C++の何が悪くてC♯が産まれたのやら
>さっぱりですね、
基本的に、Cの時代からポインタが理解できない人が多かった。
ポインタが理解できて無い人でも、コピペしたりすればC++も使えたかも知れないが、
ちゃんと理解できて無いので、理解できている人に比べてメモリーの解放を間違ってしまう頻度が高い。
そのため、ポインタが出てこないVBを使う人が多かった。
VBしか使えなかった人でもが使えるようにした上で、見かけ上の文法と言語の名称をC++に似せることによって
今までC++を使えずに肩身の狭い思いをしてきた人に希望の光を与えることに成功したのがC#。

**デフォルトの名無しさん** · 2020/06/14(日) 03:50:45.95

VB、VBと馬鹿にされてきた恨みつらみの反動で、C++は古いということにして、
新しいC#に適用できない老人が使う言語、という印象操作をする運動が
繰り広げられている。

**デフォルトの名無しさん** · 2020/06/14(日) 04:05:18.35

彼らの脳内では、なんとかしてC#の人気を出すことによって、
C++使いを減らしていけば、もう二度とVB、VBと馬鹿にされた暗黒時代に
戻ることがなくなると予定されている。

**デフォルトの名無しさん** · 2020/06/14(日) 04:15:32.10

>>316
ありがとう、PerlやRubyも考えたんですが
文字列処理ってもコエカタマリン的な利用でDirectXが・・

**デフォルトの名無しさん** · 2020/06/14(日) 04:43:58.99

C#はC++は、現実にかなり遅い。
それはそれぞれを使って作成されたアプリを比較してみれば分かる。
よく分かる例としてはVSだ。C++製のVSは高速だったが、C#製のVSは劇遅。
もう一つは、FrontPageとExpressionWeb 4。
開発に使われている言語以外はほぼ同じアプリだが、C++製の前者に比べて
C#製の後者は劇遅。

**デフォルトの名無しさん** · 2020/06/14(日) 04:59:16.97

>>297
手間がかかりすぎると聞きますがどうなのでしょうか

**デフォルトの名無しさん** · 2020/06/14(日) 05:00:21.83

それは.netフレームワークとかSilverlightの違いですか？WPF？でしたか？
Win XPとVistaの違いなようなDirectX使うか使わないかというかGUI処理ありきで画面とロジックを分けたゆえのXMLパーサーの重さなのか
グラボやドライバーがネックなような・・・

**デフォルトの名無しさん** · 2020/06/14(日) 05:03:18.92

俺も297と同意見

**デフォルトの名無しさん** · 2020/06/14(日) 05:09:24.45

>>322
MFCがGUI関連が弱いという問題はあるが、C++自体は、手間はそんなにかからない。
そんなに難しいわけでもない。
ちゃんとC言語のポインタ周りを勉強して理解することが大切で、
それさえ分かってしまえば、C++はCよりも開発効率がかなり高いし、安全。
メモリの解放の純粋なC言語では手間がかかったが、C++だとデストラクタが
発明されたことにより楽になり、そんなに危険度は高くない。

**デフォルトの名無しさん** · 2020/06/14(日) 05:18:18.18

Cでexitを安易に使う癖がついているやつには陰険な罠がデストラクタにはあるわけだが

**デフォルトの名無しさん** · 2020/06/14(日) 05:29:57.20

>>320
文字列処理なら、可読性が高い、Ruby 一択！

Perl は、意味の分からない暗号だらけで、ややこし過ぎる

**デフォルトの名無しさん** · 2020/06/14(日) 05:35:47.32

>>295
Electron も良いけど、Ruby on Rails も良い

ただし、Rails でも、GUI は、HTML, CSS/SASS, JavaScript, jQuery, Bootstrap。
または、React

**デフォルトの名無しさん** · 2020/06/14(日) 05:38:37.79

>>328
例えばウディタはC++で作成されているようです
３ｄでもないのにC++？と思ってしまうんですが、何らかのメリットがあるのでしょうか？

**デフォルトの名無しさん** · 2020/06/14(日) 06:18:58.47

>>329
まず、Electronは配布ファイルのサイズが数百MBあるので、それだけでも
プログラムの品質が下がる。
Rubyは、GUIに弱い。

C#は悪く無いとする人が多いが現実の本格的なアプリの例では遅いことが多い。

**デフォルトの名無しさん** · 2020/06/14(日) 06:21:59.90

C#、Electron、RubyはC++よりはるかに優れているので、そっち使ったほうが良いと思います。
それらは実行時最適化のおかげでC++の10倍速いという実験結果もあります。

**デフォルトの名無しさん** · 2020/06/14(日) 06:23:08.37

>>330
C#は、GUI部品はCで書かれているWin32を使っているので、簡単な
HelloWorld程度ではC++並の速度が出ているように見える。
ところが、使うメモリの量が上がってくると急激に遅くなる特徴がある。
メモリだけでなく、GUIパーツが多くなるだけでも遅いと聞いている。
凄腕プログラマの中には、実感としてC++の10倍遅い、という人がいる位。

現にVSやExpressionWeb 4の起動速度は以上に遅いし、起動後もとても遅い。

**デフォルトの名無しさん** · 2020/06/14(日) 06:23:55.47

>>331
みたいに嘘を言う人がいるのでだまされないほうがいい。
後で困るのは自分。

**デフォルトの名無しさん** · 2020/06/14(日) 06:25:03.87

>>333
対立求めてる人はとっとと追い出したほうが良い。

**デフォルトの名無しさん** · 2020/06/14(日) 06:42:43.23

>>333
おまえみたいに片棒担ぐやつもいないほうが良い。
おまえには王者の風格が無い。
何言ってんだふふんと、真のC++使いなら思えるはず。
おまえはC++を使えていない。

**デフォルトの名無しさん** · 2020/06/14(日) 07:29:43.89

>>355
>何言ってんだふふんと、真のC++使いなら思えるはず。

いや、C++は沢山の問題点を持っていることは事実である。
しかし、効率面でC#は、C++には大差で負けることも、現実のアプリの例では
垣間見えることもまた事実。

**デフォルトの名無しさん** · 2020/06/14(日) 07:32:52.41

じゃあいちいち他言語を下げるのはおやめなさい。
王者には王者の気品が求められるのです。

**デフォルトの名無しさん** · 2020/06/14(日) 07:34:59.87

>>330
>>332
労力的にはどれほど違うと思いますか？イメージでいいのですが
個人で

**デフォルトの名無しさん** · 2020/06/14(日) 07:35:16.26

ｃ＋＋使うといつまでも完成しないなんて話を聞いたもんですから

**デフォルトの名無しさん** · 2020/06/14(日) 08:29:10.72

いつまでも完成しないって
バカだからだろ

**デフォルトの名無しさん** · 2020/06/14(日) 08:36:28.26

可読性・難易度・バグりにくさ

動的言語
Ruby : 1
JavaScript : 3

静的言語
C# : 5

ポインターのある言語
C : 15
C++ : 75

**デフォルトの名無しさん** · 2020/06/14(日) 08:39:06.10

わかりやすい例でいうと、Windows10がどんどん重くなっているが
それは今までC++で書かれてた部分をC#で書き換え続けられているからといっても過言ではない

**デフォルトの名無しさん** · 2020/06/14(日) 09:06:28.85

>C++で書かれてた部分をC#で書き換え続けられている
それは別になっとらんぞ
Windowsチームって.NET嫌ってるし

**デフォルトの名無しさん** · 2020/06/14(日) 09:14:55.23

>>340
手間がどのくらい違うのですか？

**デフォルトの名無しさん** · 2020/06/14(日) 09:18:34.27

>>344
同じダロ
頭悪くなければ
ライブラリを集めて使いこなせるくらいの頭な

**デフォルトの名無しさん** · 2020/06/14(日) 09:20:16.16

>>343
例えばタスクマネージャーや電卓はUWPだと思うが、これって.NETの焼き直しか再利用だと思ってるけどどうなんだろう

**デフォルトの名無しさん** · 2020/06/14(日) 09:32:29.33

>>346
シェルとかも含めたXAML UIの部分のこと言ってるんだろうけど
あれはC#からも呼び出せるだけのネイティブで実装されたAPI（WinRT）だよ
今の電卓なんかはまさしくわかりやすい例で、特例でコード公開されてて全部C++（/CX）だよ
新規に打ち出そうとしてるWinUIもC++（/WinRT）での実装

UWPアプリ単体で見ればC++だったりC#だったりまちまちだろうけど
今はXAML=WPF=C#のイメージは切り離した方が良い

**デフォルトの名無しさん** · 2020/06/14(日) 10:00:52.61

>>347
納得した
にしても以前の電卓よりはるかに動作が重い
呼び出し元より呼び出し先に重い何かがある気がしてならない

**デフォルトの名無しさん** · 2020/06/14(日) 10:31:38.76

>>335
王者の風格とか気品とか、真のC++使いだとか、そのキッズが喜びそうなワードばかり並べ立てて何がしたいの？

**デフォルトの名無しさん** · 2020/06/14(日) 10:36:59.36

(精神的)キッズが喜びたがってるのだろう

**デフォルトの名無しさん** · 2020/06/14(日) 10:59:07.21

確かに「王者の風格」がでてきたときは0.5秒くらい「えっ？」てなった

**デフォルトの名無しさん** · 2020/06/14(日) 10:59:49.90

>>338
プログラムの実装時の労力は言語だけでなく作る対象によっても変わるからケースバイケースだけど、言語の習得の労力で言えば、C++でまともな実用的なプログラムを作れるレベルに達するのは他の言語に比べて大変だよ。
もし今現在まったくプログラミングの経験がないなら、C++よりC#から始めた方がいい。
C#で速度がでないことを心配するなら、C#で作ってどう改善しても速度が足りないとなってからC++を学習してC++に移植する方がトータルでは早くできそう。
そもそもC#では速度的に厳しいような難易度の高いプログラムを、未経験者がいきなりC++で作り始めることはかなりこんなんだと思うぞ。

**デフォルトの名無しさん** · 2020/06/14(日) 11:01:19.61

コードの王子さま「まだまだだね」

**デフォルトの名無しさん** · 2020/06/14(日) 12:21:48.10

孤高だからな

**デフォルトの名無しさん** · 2020/06/14(日) 13:07:15.05

>>322,>>339は(ある程度)事実だろ

**デフォルトの名無しさん** · 2020/06/14(日) 15:06:28.05

>>347
>今の電卓なんかはまさしくわかりやすい例で、特例でコード公開されてて全部C++（/CX）だよ
>新規に打ち出そうとしてるWinUIもC++（/WinRT）での実装

C++/CX はC++ではない。
それが遅い原因だ。
C++/CXを勝手にC++と思ってしまう人が出て本物のC++は迷惑。

**デフォルトの名無しさん** · 2020/06/14(日) 15:42:22.25

>>341
>C : 15
>C++ : 75

もともと、C++は、C with class 程度の意味で現れて、それで人気が出た。
その時は今ほど複雑でなく、Cではメモリー解放 free() を全部完全にプログラマが
書かなければならなかったところと、C++のデストラクタを使えば、ほぼ自動化することが出来た。
これにより、C++はCよりはメモリー安全になった。
型をC以上に厳密にすることで、コンストラクタとデストラクタの呼び出される回数が、ほぼ必ず同じに
なるように設計されていた。
キャスト構文を使わず、それぞれのデストラクタの中で、子供のオブジェクトに対する delete 文を
書き忘れない限り、ほぼ、コンストラクタとデストラクタは一対一に対応するので、
結果的にメモリーの解放間違いはほぼ無くせる設計になっていた。
これが、(恐らく)後になって RAII という言葉で語られるようになっていった。
また、クラスメンバに対しprotected属性が使えることも安全性を高めた。
さらに、Cでは実行段階で関数を超高速に切り替えるためには関数ポインタを使うことが必須であったが、
C++では仮想関数でそれを行うことが出来るようになり、間違いを減らすことが可能になった。
クラスの継承の概念は、既に作ったプログラムを少しずつ変化させることに役立つため、
プログラムを美しく設計できるようになった。

C++は今のバージョンは難しく見えるが、もともとはCを安全にすることにとても役立つものであった。

**デフォルトの名無しさん** · 2020/06/14(日) 16:14:13.31

「本物のC++」であるかどうかと速度は直接関係はないと思うが

◆QZaw55cn4c · 2020/06/14(日) 16:48:51.00

>>357
＞C++のデストラクタを使えば、ほぼ自動化することが出来た。

それ、全然「自動化」になっていないですよ…

**デフォルトの名無しさん** · 2020/06/14(日) 17:11:05.05

>>358
C++/CXは、メモリ関連で本物のC++とは異なったやり方をしている。
C++が速いのはまさにメモリ関連であるのだから、ソースの書き方が似ていると
しても、そこを変えた言語で書いたプログラムの速度がC++と同じであるとは
とても言えない。

**デフォルトの名無しさん** · 2020/06/14(日) 17:28:22.41

この狂人C++/CXをC++/CLIと勘違いしてないか？

**デフォルトの名無しさん** · 2020/06/14(日) 18:05:23.75

デストラクタをまともに設計できる奴があんまおらんからな。
てか資源解放てインスタンスの種類よりも生成したシチュエーションによることのが多いし
シチュエーション事に開放メソッド選ぶ方がわかりやすい。
だからgoではdefer文による解放なんだろ。

**デフォルトの名無しさん** · 2020/06/14(日) 18:12:49.93

>>349
そらキッズを説得するためだからよ。

**デフォルトの名無しさん** · 2020/06/14(日) 18:16:02.14

>>362
ファイルハンドルの様な「資源」は、デストラクタによる解放は実は向いてない。
メモリーが向いている。
もともと、C++のデストラクタは、メモリー安全のためが主目的であったと
言っても過言ではなく、RAIIの R = Resource というのは、変な話。

**デフォルトの名無しさん** · 2020/06/14(日) 18:29:52.90

>>364
全く逆だなぁ。
資源のように解放するタイミングが比較的重要なものこそデストラクタが向いているだろう。
メモリだけならGCでも全然問題ないし。

**デフォルトの名無しさん** · 2020/06/14(日) 18:36:46.54

int と long long の和って long long ですよね？
int と double の和も double ですよね？
こういうのって大きいデータ型にキャストされると思って良いですか

**デフォルトの名無しさん** · 2020/06/14(日) 19:18:11.35

タイルマップエディタを作る場合はC++とC#どちらがいいですか？

**デフォルトの名無しさん** · 2020/06/14(日) 19:26:48.64

>>366
基本的にその考え方であってる。
細かいところは汎整数拡張でググってwikipediaを見てくるといいよ。

**デフォルトの名無しさん** · 2020/06/14(日) 19:36:58.18

>>367
どっちでもいい
どうせほとんどは途中で挫折するんだし、苦労して作ったところで現実には誰にも使われずに消えていく
しかしその努力は決して無駄になるわけではなく、君の中には多少なりとも技術と経験が残るだろう
目先ではなく、将来何がしたいのか、そのためには何を習得すべきなのかを考えなさい

**デフォルトの名無しさん** · 2020/06/14(日) 19:48:57.07

将来何をしたいか、わからないです
2dにopenglは必要ですか？
必要ならC++なんでしょう

**デフォルトの名無しさん** · 2020/06/14(日) 19:53:15.45

2dにOGLは正直オプションだな。
OGLはグローバル規格だから、WindowsとかOSに縛られるということが少ない。
しかし、近年のGPUは3Dを基準に作っているからOGLを使った方が速度は出るかもしれない。
なお、OGLは特に言語は規定していない。

**デフォルトの名無しさん** · 2020/06/14(日) 19:56:51.60

ゲーム作りたいのか？
今時のゲーム開発ではそもそもOpenGLを直で叩く必要はまずなくて、Unityなどの開発スイートを使うのが普通だ
まあC#でいい

**デフォルトの名無しさん** · 2020/06/14(日) 20:05:56.73

じゃあエレクトロンで作るよ

**デフォルトの名無しさん** · 2020/06/14(日) 20:21:24.84

その場合は、もしかしたらWEBGLかもしれんな。

**デフォルトの名無しさん** · 2020/06/14(日) 20:33:14.43

大事ナノは結局ロジックだと思うので(´・ω・`)速度とか考えずにやります

**デフォルトの名無しさん** · 2020/06/14(日) 21:07:35.45

UE4はC++なので、ゲームを仕事にしたいなら、C++は使えた方がいい。
unityもスマホゲーや小規模開発でシェア大きいので、Unityで使うC#もやっておこう。
つまり、C#とC++両方を当然に使えるようになるべき。
趣味で作りたいだけなら、資料の多いunityでも、最近VE5の発表で熱いUE4でも、好きな方やればよい。
グラフィックエンジニアやりたいなら、DirectX12やVulcanにてをだしてもよいかもしれない。茨の道だがね

**デフォルトの名無しさん** · 2020/06/14(日) 22:02:31.10

>>365
そうだよね
GC言語はある意味一番簡単なメモリの管理は自動化できても、それよりクリティカルなメモリ以外のリソース管理が悲惨なことになる

**デフォルトの名無しさん** · 2020/06/14(日) 22:11:34.75

>>365
だから、あなたみたいなGC言語に慣れた人が多くなって、C++の本質が理解出来て
無くて RAIIなどといい始めたんだ。
ちがうんだよ、本来のデストラクタの主目的は。

デストラクタの中には、pure C の free() のように、本質的にはどんな場合に
呼び出しても失敗することが無いような関数だけを書くことが基本。
それを昇華すれば、deleteを書いても、絶対に失敗しないことになる。
これは数学的帰納法を理解できない人に入っている意味が分からないと思うが。

とにかく、デストラクタの役割も作られた目的も、メモリの安全な解放だったの
であって、リソースの開放のためでは無いので、リソースの解放をデストラクタ
の中に書くというのはさまざまな問題を生む。

**デフォルトの名無しさん** · 2020/06/14(日) 22:29:21.16

>>365
>資源のように解放するタイミングが比較的重要なものこそデストラクタが向いているだろう。
少なくとも初期のころのC++は、そのようなことがデストラクタの主目的ではなかった。
今、GCでやっていることが効率が悪いことを見越して、かつ、メモリー安全性を確保するために
発明されたのがデストラクタだ。

数日前にも、ファイルハンドルなどのリソースをRAIIを使ってデストラクタで閉じようとすると、
失敗した時に対処できなくなるという非常に難しい問題が生じることが議論されていた。
メッセージボックスさえ出すことができないかも知れないのだ。
メッセージボックスを出そうとすることがむしろ仇となって、その瞬間に大切なデータが保存できて無い
アプリもろともダウンしてしまう可能性がある。

なぜそういうことがおきるかというと、もともと、デストラクタは、失敗する関数をそこに
含めることを想定していなかったからだ。

**デフォルトの名無しさん** · 2020/06/14(日) 22:37:05.85

>C++の本質が理解出来て無くて RAIIなどといい始めたんだ。

RAIIって20世紀の頃の禿のお言葉なんだがｗ

**デフォルトの名無しさん** · 2020/06/14(日) 22:52:30.07

Bjarne Stroustrup 氏の事を禿と言ってしまう人の人間性を疑う。
名前が覚えられないのか。

**デフォルトの名無しさん** · 2020/06/14(日) 22:54:20.28

あら議論から逃げよったわw

**デフォルトの名無しさん** · 2020/06/14(日) 22:58:03.93

妙だな？　誰も禿をびよーねとは言っていないのに・・・

**デフォルトの名無しさん** · 2020/06/14(日) 23:03:05.44

>>379
向いてる向いてないと元々の目的というのは直接関係ないな。
後半の話も、リソースの解放ができないということではなくてメッセージボックスを
出せないというだけでしかないし。

**デフォルトの名無しさん** · 2020/06/14(日) 23:04:20.52

まあ、RAIIが、20世紀に考え出されていたのであれば、それはそれで良しとしよう。
でも、彼の頭の中でどうであったとせよ、当時の本を見れば、デストラクタの
説明としてほぼ必ずと言って、メモリ解放のために用いる例が書かれていたのだから、
C++を実用的な観点で見た時にデストラクタの一番の使い道はメモリ解放であった
ことは疑いの無い事実だろう。

**デフォルトの名無しさん** · 2020/06/14(日) 23:09:16.33

>>385
誰も言ってくれてないから俺が言ってやるけど
お前は自分が見えてないよ
お前は人に教える立場ではなく
みんなに教えてもらってる立場なんだぞ
見てて恥ずかしいわ

**デフォルトの名無しさん** · 2020/06/14(日) 23:13:56.65

>>385
ではここで太古から存在するハゲFAQを見てみましょう
https://www.stroustrup.com/bs_faq2.html#finally

**246** · 2020/06/14(日) 23:28:20.22

>>246
に書いたけど、

デストラクタ中の例外の扱いについて、
More Effective C++ にも書いてある

**デフォルトの名無しさん** · 2020/06/14(日) 23:32:05.30

>>387
英語じゃねーか、日本語で書けよ。

**デフォルトの名無しさん** · 2020/06/14(日) 23:57:28.27

アメリカ人は馬鹿だから参考にならない。
彼らのために世界中の生産性が下がっている。

**デフォルトの名無しさん** · 2020/06/15(月) 00:10:53.34

禿先生はデンマーク人だぞ

**デフォルトの名無しさん** · 2020/06/15(月) 00:13:02.53

>>389
王者の気品とか言っちゃう奴の日本語よりはまともな人の書いた英語の方が遥かに読みやすいし、内容の価値は比べるまでもないw

**デフォルトの名無しさん** · 2020/06/15(月) 00:23:21.40

以上、本日のASDLおじいちゃん演説会でした