C++相談室 part151

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 02/25 20:53 / Filesize : 288 KB / Number-of Response : 1016
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

C++相談室 part151

1 名前：デフォルトの名無しさん mailto:sage [2020/05/14(木) 11:53:25.59 ID:ZPCfyTux.net]: C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

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

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

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

テンプレここまで
237 名前：デフォルトの名無しさん mailto:sage [2020/06/07(日) 01:57:43 ID:loMZGJMS.net]: &&嫌いだわ
238 名前：デフォルトの名無しさん mailto:sage [2020/06/07(日) 03:20:06 ID:NFGxwtnl.net]: 右辺値参照自身は左辺値定期
239 名前：はちみつ餃子 mailto:sage [2020/06/07(日) 09:08:16.75 ID:fhJ4vSsJ.net]: だから std::forward が要るんだよ。
240 名前：デフォルトの名無しさん [2020/06/07(日) 11:40:26 ID:uPPavgXr.net]: 昔のソースコードからの派生で開発する際、リソースの開放だけをデストラクタで行うように変えたいと考えています
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以降の作法として正しいでしょうか？
241 名前：デフォルトの名無しさん mailto:sage [2020/06/07(日) 13:44:00.54 ID:ocvuft6U.net]: 作法とか正しいとかより自分で考えた方がいいと思うけど
その場合あえて言えば、hFile渡すとこは
直接CreateFileの戻り値使って(hFileを宣言しない)、dummyの持つハンドル経由で使った方が
一貫性が取れていいかも

理想を言えば全部ラップした方がいいんだろうけど
242 名前：デフォルトの名無しさん mailto:sage [2020/06/07(日) 13:55:18.98 ID:HzkE9Nko.net]: >>237
その方法は始めてみた。
でも、unique_ptrなどを使わなくても、普通にC++98レベルのclassだけを使っても、RAIIは書ける。
243 名前：デフォルトの名無しさん mailto:sage [2020/06/07(日) 14:54:05 ID:HzkE9Nko.net]: >>239
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が解放される。
244 名前：デフォルトの名無しさん mailto:sage [2020/06/07(日) 15:37:10.54 ID:NFGxwtnl.net]: ポインタ以外のリソースでRAIIやらせるためのstd::unique_resourceが提案されてるけど難航してる
リソースの種類や使い方でそれぞれ事情が違うから無理矢理一般化しても上手く行かないらしい
245 名前：デフォルトの名無しさん mailto:sage [2020/06/07(日) 15:48:34.18 ID:HzkE9Nko.net]: >>240
補足すると、このコードだとCreateFile()した後、返されたハンドル値を No CheckでCMyXのコンストラクタに渡しているが、本当はその前にINVALID_HANDLE_VALUEかどうかをチェックしておく必要がある。
246 名前：デフォルトの名無しさん mailto:sage [2020/06/07(日) 21:39:58 ID:P1Z5Y5je.net]: >>235
そこじゃなくて

int& r_i=7; // compile error

をエラーにする必要ある？ってこと
リテラルを右辺値参照できんならエラーにする必要ないじゃん
247 名前：デフォルトの名無しさん mailto:sage [2020/06/07(日) 21:49:43 ID:NFGxwtnl.net]: それがエラーじゃなかったら右辺値参照は何のためにあるんだよ
248 名前：デフォルトの名無しさん mailto:sage [2020/06/07(日) 21:56:24.65 ID:P1Z5Y5je.net]: >>244
別にリテラル受けるためにあるわけじゃないでしょ
別の言い方すると

int&& rr_i=7; // OK

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

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

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

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

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

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

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

>>250
void* という型として認識出来たところで何が出来るものでもないよねという意図だった。
255 名前：デフォルトの名無しさん mailto:sage [2020/06/08(月) 23:54:23 ID:3GgB/ZcK.net]: >>240
しね～よ

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);
　// このあとしぬ
}

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

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

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

素直に落ちるなりおかしな挙動になるなりすればいいのよ
261 名前：デフォルトの名無しさん mailto:sage [2020/06/09(火) 07:55:59.54 ID:n28tZ6EV.net]: OSやハードが正常稼働時ならそこら辺の例外発生はないからね。

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

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

「任意オブジェ」部分が要素ごとに異なる、だと難問な気がするけど。
267 名前：デフォルトの名無しさん mailto:sage [2020/06/09(火) 17:30:16 ID:n28tZ6EV.net]: 論理積ではなく？
268 名前：デフォルトの名無しさん mailto:sage [2020/06/09(火) 17:42:20.88 ID:nNNGB7r+.net]: 確かに論理和だと「つまらない」結果になりそうね。
普通の使い方なら論理積で抽出か。

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

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

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

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

少なくとも成功したと誤解しないのが重要。
279 名前：デフォルトの名無しさん [2020/06/11(Thu) 06:18:34 ID:m7gaY4Qp.net]: そんな状況じゃopenも失敗してるだろうな
280 名前：デフォルトの名無しさん mailto:sage [2020/06/11(木) 09:58:48.19 ID:Th6rh/3U.net]: >>275
実はそれがRAIIの限界なんだよ。

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

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

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

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

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

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

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

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

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

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

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

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

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

Perl は、意味の分からない暗号だらけで、ややこし過ぎる
333 名前：デフォルトの名無しさん mailto:sage [2020/06/14(日) 05:35:47 ID:qmm3PCBI.net]: >>296
Electron も良いけど、Ruby on Rails も良い

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

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

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

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

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