C++相談室 part151

■ このスレッドは過去ログ倉庫に格納されています
2020/05/14(木) 11:53:25.59ID:ZPCfyTux
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/07(日) 09:08:16.75ID:fhJ4vSsJ
だから std::forward が要るんだよ。
236デフォルトの名無しさん
垢版 |
2020/06/07(日) 11:40:26.26ID:uPPavgXr
昔のソースコードからの派生で開発する際、リソースの開放だけをデストラクタで行うように変えたいと考えています
RAIIだけを行う標準的な実装って何かあったりしますか？
あるいは、自分で調べた限りでは例えば、
HANDLE hFile = CreateFile(filename, GENERIC_READ, FILE_SHARE_READ, nullptr, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr);
unique_ptr<void, decltype(&CloseHandle)> dummy(hFile, CloseHandle);
// 以降dummyは使わずに生のhFileに対して操作
のようにunique_ptrを使えばできそうに見えますが、C++11以降の作法として正しいでしょうか？
2020/06/07(日) 13:44:00.54ID:ocvuft6U
作法とか正しいとかより自分で考えた方がいいと思うけど
その場合あえて言えば、hFile渡すとこは
直接CreateFileの戻り値使って(hFileを宣言しない)、dummyの持つハンドル経由で使った方が
一貫性が取れていいかも

理想を言えば全部ラップした方がいいんだろうけど
2020/06/07(日) 13:55:18.98ID:HzkE9Nko
>>236
その方法は始めてみた。
でも、unique_ptrなどを使わなくても、普通にC++98レベルのclassだけを使っても、RAIIは書ける。
2020/06/07(日) 14:54:05.65ID:HzkE9Nko
>>238
RAIIというのは物凄く簡単に実装できて、細かいことを抜きにすれば以下の様にすれば完成する :
class CMyX {
protected:
　HANDLE　m_hFile;
public:
　CMyX(HANDLE hFile) {m_hFile=hFile;}
　~CMyX() {CloseHandle(m_hFile);}
}

HANDLE hFile = CreateFile(filename, GENERIC_READ, FILE_SHARE_READ, nullptr, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr);
CMyX myx(hFile);　// これが初期化。後は勝手に hFileが解放される。
2020/06/07(日) 15:37:10.54ID:NFGxwtnl
ポインタ以外のリソースでRAIIやらせるためのstd::unique_resourceが提案されてるけど難航してる
リソースの種類や使い方でそれぞれ事情が違うから無理矢理一般化しても上手く行かないらしい
2020/06/07(日) 15:48:34.18ID:HzkE9Nko
>>239
補足すると、このコードだとCreateFile()した後、返されたハンドル値を No CheckでCMyXのコンストラクタに渡しているが、本当はその前にINVALID_HANDLE_VALUEかどうかをチェックしておく必要がある。
2020/06/07(日) 21:39:58.03ID:P1Z5Y5je
>>234
そこじゃなくて

int& r_i=7; // compile error

をエラーにする必要ある？ってこと
リテラルを右辺値参照できんならエラーにする必要ないじゃん
2020/06/07(日) 21:49:43.50ID:NFGxwtnl
それがエラーじゃなかったら右辺値参照は何のためにあるんだよ
2020/06/07(日) 21:56:24.65ID:P1Z5Y5je
>>243
別にリテラル受けるためにあるわけじゃないでしょ
別の言い方すると

int&& rr_i=7; // OK

わざわざ一時オブジェクトつくってこれOKにする理由って何なの？
245デフォルトの名無しさん
垢版 |
2020/06/07(日) 22:22:50.71ID:uPPavgXr
>>237,238,240
ありがとうございます
>>239
はい、そうなんですけれど、こういったコードも省略したいということと、
頻繁に必要になるので標準ライブラリに入っていないかなって期待していたわけです
>>240
なるほどstd::unique_resourceっていうので検討中なんですね
これが標準に組み込まれるのを期待しておきます
2020/06/07(日) 23:16:58.32ID:+YSUT0gy
More Effective C++ の、

項目9 : リソースリークを防ぐためにデストラクタを使う
項目11 : デストラクタから発生した例外を抑える

デストラクタ中で、例外がキャッチされない場合、
terminate を呼ばれて、受け身も取れず、強制終了させられる
2020/06/08(月) 11:21:10.82ID:KlUsfYw8
>>245
CreateFile以外にも似たようなのが沢山あって、それを楽にRAIIにしたいって話？
ならすでにunique_resourceはあるらしいけど(experimentalだかどこかに
あるいはそれに近い実装も公開されてるので落としてくればいいかと

逆にCreateFileだけなら素直に自分でクラス書いた方が後々楽になると思う
2020/06/08(月) 12:33:58.17ID:KAmnJXdU
リソースの解放以外は生のハンドルが使いたいという前提だと、
「unique_resource で包まれたオブジェクトからハンドル使うたびに (get で) 取り出す」という操作が必要になる。
たぶん >>236 の書きようだとそういうことはしたくないんだろうし、
包む前のハンドル (が入った変数) をそのまま使うとなると折角の所有権管理が台無しだ。
unique_resource はリソースの所有権管理の仕組みであって、
デストラクタでリソース解放もするのは所有権管理に付随するものに過ぎない。

どちらかというと scope_exit の方がやりたいことに近そうな気がする。

けど、いずれにしても中途半端なんだよな。
現時点でリソースの解放 (CloseHandle) がちゃんとできているなら
それを unique_resource (なり scope_exit なり) に置き換える意味はあまりないんじゃなかろうか。
「CloseHandle の書き漏らし」ってのと「scope_exit の書き忘れ」
ってのは同程度に有り得ることで、そんなに良くならないと思うよ。

型としての HANDLE の実態は void* なので、
HANDLE を HANDLE として扱おうとする限り C++ の型システムの恩恵はあまり受けられない。
古いコードをなるべくいじらずに使いたいという理由はとてもよくわかるのだけれど、
半端な書き換えをするくらいなら抽象レイヤをきちんと構築した方が結局は楽だと思う。
249デフォルトの名無しさん
垢版 |
2020/06/08(月) 15:51:51.35ID:blut5LG8
void * と型として区別出来ない？
型はともかくそもそも HANDLE は値の範囲が決まってたか
2020/06/08(月) 16:16:36.67ID:KAmnJXdU
かなり前から DECLARE_HANDLE マクロで HANDLE は固有の型として定義してた。
そこは私の認識間違いだ。 すまぬ。

>>249
void* という型として認識出来たところで何が出来るものでもないよねという意図だった。
2020/06/08(月) 23:54:23.01ID:3GgB/ZcK
>>239
しね〜よ

void bar(CMyX& x, HANDLE h) {
　// hを思わずclose
　CloseHandle(h);
}

void foo() {
　HANDLE hFile = CreateFile(filename, GENERIC_READ, FILE_SHARE_READ, nullptr, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr);
　CMyX y(hFile);
　bar(x, h);
　// このあとしぬ
}

>>239のCMyXはハンドルをマジWrapしてるだけで全く使えない
しねよ
2020/06/08(月) 23:56:48.34ID:3GgB/ZcK
というわけでget()メソッドが無いのも大概だが
それより悪いのはCloseHandle()が失敗したときのことを何も考えていないことだ
ファイルのClose失敗はエラーハンドリング省略で済まされる問題ではない

デストラクタでCloseHandle()を一概に否定するものではないが、
デストラクタから例外を飛ばすわけにもいかないので、エラーの通知先オブジェクトへのポインタをCMyXは持つ必要がある
2020/06/09(火) 00:00:40.22ID:Ah9aU5+0
いきってツッコむほどのことかそれ
2020/06/09(火) 03:22:41.56ID:SETbyCsO
>>252
File Handle のような OS Object については、RAIIで処理するのは実は難しいんだよ。
だから、WindowのDestroyWindow()もデストラクタで処理する前に明示的に
CWnd::DestoryWindow()を自分で呼び出すほうが良かったりするんだから。

デストラクタだけを頼りにすると、main()やWinMain()関数の後の
クリーンアップ処理の中で CloseHandle()が呼び出されたりすることになるが、
それは結構微妙な話になる。
なぜかといえば、まず、OS自体がそもそも、プロセスが終了する時には
勝手にすべてのハンドルを閉じてくれる。ならば、CloseHandle()なんて明示的に
書く必要が無い、というそもそも論が出てくる。
それプラス、あなたが言ったように、CloseHandle()で失敗した場合にどうなるか
という話もあることはある。
そもそも、個人的には、ファイルを開いたら、なるべく速く Closeする方が良いと思っている
ので、RAIIでファイルハンドルを処理するのは余りぴんと来ない。
2020/06/09(火) 06:33:30.92ID:iLzxHGzP
アプリ全体の終了が前提になっているおかしな主張だな
2020/06/09(火) 06:54:05.72ID:unijwXHc
CloseHandleやfileのcloseで失敗する様な状況って、普通のアプリじゃ実質対処不能な致命的な状態だろ

素直に落ちるなりおかしな挙動になるなりすればいいのよ
2020/06/09(火) 07:55:59.54ID:n28tZ6EV
OSやハードが正常稼働時ならそこら辺の例外発生はないからね。

リソース解放忘れてデスクリプタやらのリソース使い果たしたり、ファイルの占有したままで他のアプリに迷惑かけたりするのを防止するのにRAII使うのは有用
2020/06/09(火) 08:00:35.85ID:JJE9ezaH
HANDLEってOS側からはそれが有効か無効か判断できるから、無効なハンドルを
間違って使ったりCloseHandleしてしまってもエラーを返すだけで致命的な状態には
なりにくい
259865
垢版 |
2020/06/09(火) 09:27:54.99ID:cTF8gHLn
前提にしているのがどんなOSであろうと
C++的には環境依存な話だね
2020/06/09(火) 15:37:05.70ID:FUnSNOef
要素はintと任意オブジェ
int値を渡すと
論理和がゼロ以外の要素を
返すコンテナってないですか？
2020/06/09(火) 16:12:25.38ID:SETbyCsO
>>256
もし、CTRL+Sを処理するイベントハンドラの中で、単純に CloseHandle()を自分で呼び出して
失敗した場合であれば、保存に失敗した事をAfxMessageBox()で知らせた後、なんとか今までの
メモリ中のデータだけは壊さずに処理できればベスト。

しかし、他の何らかの例外が発生した時に、RAIIによって自動的に呼び出されたデストラクタの中で
CloseHandle()に失敗した場合には、対処が難しそう。
テストも難しいし、余りそういう状況は起きないので優先順位は低いが。
2020/06/09(火) 17:15:04.89ID:nNNGB7r+
>>260
std::pair<int, SomeObj> を格納するコンテナと
「int部分とある値とのビットORを結果とする述語」を
std::copy_if() に渡すような話かな。

「任意オブジェ」部分が要素ごとに異なる、だと難問な気がするけど。
2020/06/09(火) 17:30:16.71ID:n28tZ6EV
論理積ではなく？
2020/06/09(火) 17:42:20.88ID:nNNGB7r+
確かに論理和だと「つまらない」結果になりそうね。
普通の使い方なら論理積で抽出か。

排他的論理和は「もっと面白い」かも知れんけど。
2020/06/09(火) 22:35:23.41ID:FUnSNOef
>>262
それで組んでみます
ありがとうございました
あと実際は論理積です
2020/06/10(水) 05:39:12.94ID:67cF/bBY
>>256
「ログファイルなので書込みに失敗しても大勢に影響が無い」とか
「作業用ファイルfは書いた後必ず誰かがリードオープンするから書込みに失敗していたらそこでﾜｶﾙから書込みのエラーチェックを省略する」
みたいな判断はアプリの設計としてはアリかもしれないが、CMyHandleみたいな汎用部品的に使われ得る低水準クラスではナシ
これをアリだと思う香具師はお気楽すぐる、
2020/06/10(水) 05:44:30.52ID:OTs8rmHM
>>266
でも　>>256 の CloseHandle() や fclose() が失敗したからといって、何か手が打てるのですか？
何もできないのでは？
もしかして黙って exit() するのですか？
2020/06/10(水) 07:23:10.62ID:itI4VuCe
てか、自動解放するクラス作っても手動解放する手段残しておけば、使う側で特別な処理は出来るんだよね
2020/06/10(水) 08:13:57.83ID:V+CQutVh
C++ではexitをD組にして欲しい
2020/06/10(水) 12:31:11.80ID:BPKUZfdj
>>267 通知は欲しいかな。
黙って動作が続くくよりは terminate() のほうがマシだとも思うし。汎用部品ならなおさら。

破棄失敗する可能性のあるリソースの RAII wrapper にはエラー通知できる
close() なりの破棄操作を別に用意しておけという話で済むと思う。
2020/06/10(水) 21:10:53.11ID:OTs8rmHM
>>270
通知って簡単にいいますけれども、その例えば fclose() 失敗の通知をどこに送り、そして送った先では何をするのですか？
通知をもらって何か手を打てるのですか？

汎用部品／ライブラリの作法ですか
理解はできますが、しかし、何もできないのなら、あるいは何もできないことがわかっているのなら、特段の失着にはみえませんね…
2020/06/10(水) 21:56:31.91ID:yfneRFZn
大事なデータを保存したファイルのfclose()が失敗したらどうするかって？
場所変えて保存を試みるに決まってるだろ
それくらいしないプログラムは売り物にならないぞ
2020/06/10(水) 22:20:00.38ID:yQDU6thd
そもそも仕様で指定があるならそのように書くだけなんじゃ
2020/06/11(木) 00:27:51.81ID:flOLYJrB
>>271
たとえばコンソールアプリなら標準エラーに情報を出したうえで終了コードに反映して、
コマンドが失敗したのを見たユーザーが何をするか考えるっていうのはごく当たり前のことでしょ。
たとえばストレージ容量が足りないとして失敗したなら容量を確保して再実行すればいい。

fclose() の戻り値を捨ててるプログラムは現実としてたぶん多いんだけど、
そんなソフトがたとえばサーバー内でストレージ容量不足を数か月にわたって闇に葬り続け、
何かおかしいと気付いたサーバー管理者が自動スクリプトを緻密にトレースした結果、
保存されているはずの情報がもはやどこにも存在しないと気付いた時の怒り憎しみ悲しみを想像されたい。

少なくとも成功したと誤解しないのが重要。
275デフォルトの名無しさん
垢版 |
2020/06/11(木) 06:18:34.85ID:m7gaY4Qp
そんな状況じゃopenも失敗してるだろうな
2020/06/11(木) 09:58:48.19ID:Th6rh/3U
>>274
実はそれがRAIIの限界なんだよ。

ちゃんと明示的に fclose() してその戻り値をチェックするのが一番安全。
例外安全性のためにRAIIを使うべきという人が居るけど、それで勝手に
デストラクタ内でfclose()して容量不足やディスクエラーで書き込み失敗した時には、
多くの場合、対処に困る。
でも、例外安全のためにはそうせざるを得ないかも知れない。
ということは、そもそも論になり、例外の throw、catch機構自体が安全に扱うのが
難しいという結論に至り、議論百出する。
2020/06/11(木) 10:29:20.16ID:flOLYJrB
>>276
それは飛躍しすぎかな。
破棄が失敗する可能性のあるリソースの RAII ラッパーが破棄操作も提供すれば済む話でしょ。
std::fstream の close() みたいに。
2020/06/11(木) 10:38:30.62ID:3eiGl155
上から目線なくせに脇が甘いな
2020/06/11(木) 11:08:58.38ID:7wv0rqaB
デストラクタ内でエラーが発生する可能性があってそれに対処が必要なら
例外の送出とか言ってないでデストラクタ内で対処してしまえよ。
汎用的な部品にし難いのはしゃーないやろ。
実際に汎用的ではないんだから。
280デフォルトの名無しさん
垢版 |
2020/06/11(木) 11:47:39.02ID:DcPEy/qZ
おまいら (f)printf() の戻り値もちゃんと毎回観てるか？
2020/06/11(木) 11:54:46.87ID:Th6rh/3U
>>279
そうじゃなくて、何らかの別の事情で例外が送出された時に、fclose()し忘れを
防ぐためにRAIIのテクニックを使う場合の話をしてる。
2020/06/11(木) 11:56:16.72ID:Th6rh/3U
>>277
fstreamであろうがなんであろうが、GUIアプリに置いて、デストラクタ内で失敗した
時にユーザーに失敗したことを知らせるのは結構難しいぞ。
2020/06/11(木) 12:17:49.27ID:3eiGl155
そんなに難しいか？
深刻な事態が疑われるならシステムモーダルダイアログなり何なりすることあるだろ
あくまでOSではなくアプリとして事後条件が保証できない場合はterminateを呼び出して
OSに事故としての扱いをさせるのが「難しい」のは思いつかないだけじゃねえだろな

プログラミング以外の仕事でも事故はまず報連相
１人で握りつぶそうとするのは学生気分が抜けてないやつのすることだ
2020/06/11(木) 12:19:04.03ID:flOLYJrB
>>282
そりゃ難しいだろうな。
通知が要るならデストラクタ内で失敗させないように破棄操作を提供すれば済むだろうという話をしたつもり。
それで済まないケースを想定してるなら、どんなのか教えて。
2020/06/11(木) 12:21:07.06ID:flOLYJrB
>>283 そっか GUI ならダイアログ使えるから、通知するだけなら簡単だね。
2020/06/11(木) 12:22:43.78ID:Th6rh/3U
>>284
>通知が要るならデストラクタ内で失敗させないように破棄操作を提供すれば済むだろうという話をしたつもり。
意味が分からないので、説明を。
2020/06/11(木) 12:29:07.29ID:Th6rh/3U
>>283
Exceptionをthrowした時の自動フォローアップとしてRAIIのデストラクタが呼び出される。
それが呼び出されるのは原則的にどこかでかは余り仮定できない。
ということは、非常に変なタイミングで fclose()に失敗することがある。
メッセージボックスを出すと、そこでイベントに対するメッセージループが形成されるので、
タイマーイベントのハンドラのOnTimer()などが起動してしまうこともある。
OnTimer()を、Exceptionがthrowされた状態で実行してよいかどうかは注意を要する事だ。
また、アプリの初期化処理の InitInstance()や終了処理のExitInstance()の中で、RAIIの
デストラクタが呼び出されてしまう場合もあるかも知れず、その中でメッセージボックスを
出すと思わぬ問題が生じるかもしれない。
生じないかも知れないが。

ただ、Exceptionがthrowされたということは何か異常が生じているということで、
それがたまたまファイルに関するものであったとしたら、二重三重に、ファイル関連で
エラーが生じてしまい、何か危険な状態に陥ってしまう可能性も有るかも知れない。
そういう微妙な配慮が必要となる。
2020/06/11(木) 12:33:42.17ID:Th6rh/3U
>>287
もっといえば、Exceptionのthrowはどこで起きるかは仮定しにくいものなので、
何らかのダイアログを出すための初期化処理の中で生じることも有るかも知れない。
そういう場合にたまたま、関数の呼びだし元へ どんどん Exception の Unwinding
が生じて、RAIIのデストラクタで fclose()が呼び出される可能性も有るかも知れない。
そうなって、さらに、その fclose()がエラー終了する場合がある。
ダイアログの生成に失敗したタイミングで、エラーメッセージの表示のために、
メッセージボックスのダイアログを出すことになれば、もしかしたらかなり危険な
バグを含むことになってしまうかも知れない。
2020/06/11(木) 12:49:26.16ID:flOLYJrB
>>286-288
ごめん、別の例外でスタック巻き戻し中の fclose() 失敗は無視でもいい想定だった。
元の例外が通知されればそれでいいだろうと。
破棄操作を提供すれば済むっていうのは、たとえば fstream について
正常フローから close() 呼び出せば fclose() の失敗は普通に処理できるっていう意味。

エラー発生後の後処理でのエラーについてはもはや例外処理機構とか RAII とか関係なく
エラー処理一般で難しさは変わらないのでは？
2020/06/11(木) 13:14:41.21ID:4Jo+eUkD
>>287
何を言い出すかと思ったらシングルスレッドを
気分だけマルチっぽく見せかけてるだけなやつの話か
2020/06/11(木) 17:56:16.10ID:+WuQ8P1K
そんなに大事なデータならverifyするだろ
2020/06/13(土) 16:05:30.52ID:ifM7/RIh
>>271
>知って簡単にいいますけれども、その例えば fclose() 失敗の通知をどこに送り、そして送った先では何をするのですか？
最終的にはユーザーに通知する

>通知をもらって何か手を打てるのですか？
ユーザーが通知に従い手を打てる

>>279
デストラクタ内での例外を送出したら即アプリが死ぬﾊｽﾞ
コアを吐いてくれたら通知にあたる情報が取り出せるかもしれないが美しくない

>>287
異常の内容をユーザーに通知することを目的とするなら
>エラーの通知先オブジェクトへのポインタをCMyXは持つ(>>252)
で事足りる
メッセージループは、通知先オブジェクトが1個だけもちさえすればユーザーへの通知の役目を果たせる
CMyXのようなケースは通知先オブジェクトを保持するオブジェクトからFactoryMethodパターンでインスタンス化
するのがいかにもOOP的で個人的には好み（CMyXのインスタンス化のときに通知先を確実に渡せる
2020/06/13(土) 16:59:34.64ID:1nypd8FJ
>>292
私が書いた >>279 ではデストラクタ内で対処を完結させろ (例外を投げずに済ますために) と書いてあるつもりなんだが、お前にはそれが読み取れなかったか？

ちなみに、現在の C++ ではデストラクタ (と delete) はデフォルトで noexcept で修飾されているものと見なされる。
これは例外を外へ送出しないことを保障するんだが、内部で例外が発生しないとは保証されない。
もし発生した例外を内部でキャッチせずに外へ出ていこうとしたら std::terminate() が呼び出される。
(スタックの巻き戻しは起こらずに即死するかもしれない。)

陽に noexcept(false) を指定したらデストラクタから例外を送出することは可能。
ただし、スタックの巻き戻し中に起動される別のデストラクタから例外が送出されると死ぬ。
普通は色々なライブラリを組み合わせるから問題が出ないようにするには
一貫してデストラクタからは例外を投げないのが妥当な設計だと考えられているってだけ。
2020/06/13(土) 17:06:07.88ID:ifM7/RIh
>>293
よく読んでなかったわｻｰｾﾝｗｗｗｗｗｗｗｗｗｗｗｗ

>>292ので
>デストラクタ内で対処を完結させろ (例外を投げずに済ますために)
のアッパーコンパチになるのだから結果オーライで
オール無問題、
295デフォルトの名無しさん
垢版 |
2020/06/13(土) 20:11:16.15ID:K/U+GWpl
個人でｃ＋＋使うことは少ないですか？
C#やelectronと比べて何倍手間がかかりますか？
２ｄのタイルマップエディタのようなものを作りたいのです、、、
https://www.mapeditor.org/
2020/06/13(土) 20:19:12.06ID:lPN2rvMv
挫折するリスクも加味すると100倍くらいじゃないかな
2020/06/13(土) 20:42:52.21ID:AVSH26bs
>>295
個人の場合、実はC++は適している。
むしろ、大人数の場合、いろいろなレベルの人がいるので速度を落としてでも、
誰でも使えるような言語を使おうとする企業が多い。
ちゃんとしたものを作りたかったら、C++は最良の選択。
2020/06/13(土) 20:55:51.74ID:AVSH26bs
ところで、全く関係ないけど、昔は、
標準変換(Standard Conversions)の1つに、
「Reference Conversions(参照変換)」
という項目があったのに、C++17では、Overload Resolution関連で
「Reference Binding(参照束縛)」
という項目だけになってしまった、という認識であってますかね？
もしかしたら古すぎて、もう分からないかな。
2020/06/13(土) 21:10:55.91ID:XHF92Eb6
c++がどうこういうこと自体無意味な気分。
OSとコンパイラのバージョン指定でもせん限り、特定の議論にもなりゃしない。
2020/06/13(土) 22:13:05.14ID:rMzKFBuy
これから始めようと思うのですが
C++とC♯の大きな違いは何ですか
どっちから先の方が良いですか？
2020/06/13(土) 23:19:47.34ID:B/JuT+NG
何作りたいかによるとしか言いようがない
302デフォルトの名無しさん
垢版 |
2020/06/13(土) 23:29:25.22ID:dAI/jSW6
あーじゃあ、C++には何が出来なかったせいで
後からC♯が作られたの？
2020/06/14(日) 00:35:35.69ID:0sKu6MyV
違うよ
2020/06/14(日) 00:45:05.04ID:lm4ZS132
んーでは、C++が劣っていてC♯が作られた理由は？
2020/06/14(日) 00:55:29.50ID:7AEk3bXh
インタープリ夛ー
2020/06/14(日) 00:58:40.28ID:g+gmh/oa
Javaの代わりが欲しかっただけであって優劣の問題はあまり関係がない
が結局Javaの領域には食い込めず、スクリプト言語の代わりになった
自由度を奪う代わりに楽に書けるみたいな
結局自由度が必要なのでC++から離れられないので余計書くのがつらい仕様になった
Win32APIのインクルードくらいＳＤＫにまとめとけやPinｳﾞｫｹって感じ
2020/06/14(日) 01:08:08.89ID:7AEk3bXh
インタープリティアひとつつくっておけば色々な環境に使い回せるし版権問題にうるさいJavaをぶっつぶすため
2020/06/14(日) 01:08:40.52ID:lm4ZS132
>>306
> Javaの代わりが…スクリプト言語の代わりになった

なるほどぉ、それでunityのスクリプトになってるのか、
C++の自由度って具体的には何を指すんですか？
2020/06/14(日) 01:17:15.70ID:7AEk3bXh
常識だろjk
310デフォルトの名無しさん
垢版 |
2020/06/14(日) 01:21:41.82ID:iYtMGgBJ
C++はアルゴリズムの部品化が一般的になっているので、自由に組み合わせられるところが、良いと思います。
2020/06/14(日) 01:33:23.99ID:MJZpLG29
>>308
やりたければメモリのどこにでもアクセスできるってのが特に重要な違いかな。
デタラメなアクセスをしても実行時エラーとして検出されるとは限らない。

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

でも現実はそうではない。 (プログラマは間違う。)
2020/06/14(日) 01:35:24.50ID:lm4ZS132
C++で出来るんならいったい、C++の何が悪くてC♯が産まれたのやら
さっぱりですね、
Wikipedia見にいったらc#はBoolean型とスイッチケースでストリング型が使えるそうなので
c＃にしようと思います
お邪魔しましたわ、ありがとうございました。
2020/06/14(日) 01:41:28.38ID:9pT3ELpf
c#を選択するのは悪くないと思うが、そこじゃないだろ
2020/06/14(日) 01:45:14.17ID:lm4ZS132
あーうーん、自然言語処理とかネットのデータベースで
文字列比較を多用しそうな予定は未定なので・・
2020/06/14(日) 02:22:12.57ID:6myF93T5
>>298
MSDNのC++の仕様書を見ると、まだちゃんと Reference Conversionsの
項目があった。
C++17には無い項目だ。
2020/06/14(日) 03:45:35.31ID:PNQfdADa
文字列処理がメインで速度求めないならpythonとかの方がいいと思うぞ
2020/06/14(日) 03:48:19.28ID:kJWeEmyo
>>312
>C++で出来るんならいったい、C++の何が悪くてC♯が産まれたのやら
>さっぱりですね、
基本的に、Cの時代からポインタが理解できない人が多かった。
ポインタが理解できて無い人でも、コピペしたりすればC++も使えたかも知れないが、
ちゃんと理解できて無いので、理解できている人に比べてメモリーの解放を間違ってしまう頻度が高い。
そのため、ポインタが出てこないVBを使う人が多かった。
VBしか使えなかった人でもが使えるようにした上で、見かけ上の文法と言語の名称をC++に似せることによって
今までC++を使えずに肩身の狭い思いをしてきた人に希望の光を与えることに成功したのがC#。
2020/06/14(日) 03:50:45.95ID:kJWeEmyo
VB、VBと馬鹿にされてきた恨みつらみの反動で、C++は古いということにして、
新しいC#に適用できない老人が使う言語、という印象操作をする運動が
繰り広げられている。
2020/06/14(日) 04:05:18.35ID:kJWeEmyo
彼らの脳内では、なんとかしてC#の人気を出すことによって、
C++使いを減らしていけば、もう二度とVB、VBと馬鹿にされた暗黒時代に
戻ることがなくなると予定されている。
2020/06/14(日) 04:15:32.10ID:Lj4n2emQ
>>316
ありがとう、PerlやRubyも考えたんですが
文字列処理ってもコエカタマリン的な利用でDirectXが・・
2020/06/14(日) 04:43:58.99ID:kJWeEmyo
C#はC++は、現実にかなり遅い。
それはそれぞれを使って作成されたアプリを比較してみれば分かる。
よく分かる例としてはVSだ。C++製のVSは高速だったが、C#製のVSは劇遅。
もう一つは、FrontPageとExpressionWeb 4。
開発に使われている言語以外はほぼ同じアプリだが、C++製の前者に比べて
C#製の後者は劇遅。
322デフォルトの名無しさん
垢版 |
2020/06/14(日) 04:59:16.97ID:VVffaeyk
>>297
手間がかかりすぎると聞きますがどうなのでしょうか
2020/06/14(日) 05:00:21.83ID:Lj4n2emQ
それは.netフレームワークとかSilverlightの違いですか？WPF？でしたか？
Win XPとVistaの違いなようなDirectX使うか使わないかというかGUI処理ありきで画面とロジックを分けたゆえのXMLパーサーの重さなのか
グラボやドライバーがネックなような・・・
2020/06/14(日) 05:03:18.92ID:fGEYrFA/
俺も297と同意見
2020/06/14(日) 05:09:24.45ID:kJWeEmyo
>>322
MFCがGUI関連が弱いという問題はあるが、C++自体は、手間はそんなにかからない。
そんなに難しいわけでもない。
ちゃんとC言語のポインタ周りを勉強して理解することが大切で、
それさえ分かってしまえば、C++はCよりも開発効率がかなり高いし、安全。
メモリの解放の純粋なC言語では手間がかかったが、C++だとデストラクタが
発明されたことにより楽になり、そんなに危険度は高くない。
2020/06/14(日) 05:18:18.18ID:fGEYrFA/
Cでexitを安易に使う癖がついているやつには陰険な罠がデストラクタにはあるわけだが
2020/06/14(日) 05:29:57.20ID:qmm3PCBI
>>320
文字列処理なら、可読性が高い、Ruby 一択！

Perl は、意味の分からない暗号だらけで、ややこし過ぎる
2020/06/14(日) 05:35:47.32ID:qmm3PCBI
>>295
Electron も良いけど、Ruby on Rails も良い

ただし、Rails でも、GUI は、HTML, CSS/SASS, JavaScript, jQuery, Bootstrap。
または、React
329デフォルトの名無しさん
垢版 |
2020/06/14(日) 05:38:37.79ID:VVffaeyk
>>328
例えばウディタはC++で作成されているようです
３ｄでもないのにC++？と思ってしまうんですが、何らかのメリットがあるのでしょうか？
2020/06/14(日) 06:18:58.47ID:kJWeEmyo
>>329
まず、Electronは配布ファイルのサイズが数百MBあるので、それだけでも
プログラムの品質が下がる。
Rubyは、GUIに弱い。

C#は悪く無いとする人が多いが現実の本格的なアプリの例では遅いことが多い。
331デフォルトの名無しさん
垢版 |
2020/06/14(日) 06:21:59.90ID:iYtMGgBJ
C#、Electron、RubyはC++よりはるかに優れているので、そっち使ったほうが良いと思います。
それらは実行時最適化のおかげでC++の10倍速いという実験結果もあります。
2020/06/14(日) 06:23:08.37ID:kJWeEmyo
>>330
C#は、GUI部品はCで書かれているWin32を使っているので、簡単な
HelloWorld程度ではC++並の速度が出ているように見える。
ところが、使うメモリの量が上がってくると急激に遅くなる特徴がある。
メモリだけでなく、GUIパーツが多くなるだけでも遅いと聞いている。
凄腕プログラマの中には、実感としてC++の10倍遅い、という人がいる位。

現にVSやExpressionWeb 4の起動速度は以上に遅いし、起動後もとても遅い。
2020/06/14(日) 06:23:55.47ID:kJWeEmyo
>>331
みたいに嘘を言う人がいるのでだまされないほうがいい。
後で困るのは自分。
334デフォルトの名無しさん
垢版 |
2020/06/14(日) 06:25:03.87ID:iYtMGgBJ
>>333
対立求めてる人はとっとと追い出したほうが良い。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況