C++相談室 part133
■ このスレッドは過去ログ倉庫に格納されています
次スレを立てる時は本文の1行目に以下を追加して下さい
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part132
http://mevius.5ch.net/test/read.cgi/tech/1507561894/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.102【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1509780815/
■長いソースを貼るときはここへ。■
http://codepad.org/
https://ideone.com/
[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured >>224
最終的に何をしたいんだ?
俺にはそこが見えない。
一つずつ詰めると、頭三行
> await/asyncのコルーチンは並列化じゃなくて非同期処理を同期処理っぽく書くための物だとおもうよ
> 「これを実行して、終わったらこれを実行してね」
> っていうときに、スタックの内容がそのまま残ってるからデータの受け渡しが楽というだけだろう
については同意する。これは>>218-220含めて3人の共通理解でいい。
(ただし俺には逆に、君自身は「並列化の為に」async/awaitを使おうとしているように見える)
> ただ>>220が言ってるように順不同のresumeが起こったらアブナイので
これについては、一般的には逆だ。順序が逆になったら危ないような物を非同期にしてはいけない。
違う言い方をすると、非同期の結果をbarrierを張ってキャンセルするのではなく、
barrier後に非同期にして、結果は必ずcommit出来る構造にする。
ちなみにJavaScriptの連中はここら辺が分かっていなくて、
(というより連中は制御構造云々を議論できるレベルではないのでこれ以前なのだが)
同期前提の制御構造で非同期を扱おうとするからおかしなことになる。
JavaScriptには非同期しかないんだから、選択の余地もないんだが。
C#のasyncはこれとはちょっと違って、イベントで起動するから必ずUIスレになるんだが、
それにジョブをやらせるとUIがカクつくから他スレッドを起動しろ、
しかしそれだと結果を画面に表示できないからそこだけUIスレッドを呼び戻せ、
ただこれだとソースが汚いから、asyncというキーワードをつけ、あたかも全てUIスレッドが処理しているように見せる、
みたいな、なんだかなあ、という状況になっている。
つまり処理順と処理スレッドを入れ替える為の糖衣構文のようなものであって、
本来のasync/awaitのように、非同期を同期的に書くための物自体ではない。ただしそうとも使えるから流用してるが。
それで話を戻すと、君は非同期部分に一般とは逆の「非同期の結果を普通にキャンセルできる構造」を作ろうとしているようだが、
これは何故?或いは何のメリットがあると考えている? Java厨はハードの基本がわかってないニワカなんちゃってPGが殆どだからな 予告犯でホリエモンもどきがシンブンシにそんな事言っていたな コルーチンをキャンセルとか意味わかんない事言ってるから途中から読んですらない。 >>226
引数が違うだけで、内部的には、どれも同じだろ。
つまり、ラッパー関数
OS をすべて知っている奴は、いない
だから皆、神の書と呼ばれる、この本を枕にして寝ている。
著者は、man ページの作者。
この本が翻訳されているのは、日本だけ
Linux プログラミング・インタフェース、2012 >この本が翻訳されているのは、日本だけ
もうだめだこの国 Linux 資格の、LPIC 取得者も、半分以上は日本人だろ
日本は、Linux 大国 Linuxは日本に入ってきたのが早かったし、最初期に一気に広まった。
日本がLinux王国というのは間違いではない。
しかし、それを生かせなかった。
なんでだろ。 >>240
PC98 のリソースが freebsd に注がれ、linux への移植が遅れたため 当時書店でBoWとか売ってたけど、そのせいで遅れたような感じはしなかったけどなあ。
むしろLinuxでX11動かすのに四苦八苦してた頃、すでにコンソールで日本語が使えてたのは、
UNIXの人たちのおかげのような気がする。 検索してみるとコンパックショックが1994年なんだな。
DOS/V機自作したのが1993年だからもうちょっと前かと思ってたけど。
正規流通前にショップが輸入して売ってたんだろか。 その当時、漏れは、Windows 3.1 で、UNIX プログラミングやってた。
テキストエディタ MIFES を使っていた
Oracle で、銀行とか、新幹線とか >>245
>銀行とか、新幹線とか
暗号方式はなにを使っていましたか? NECは当時経営陣が自社の社員が開発したソフトを押し退けてMSのソフトをごり押ししてたからな
終わっているよな 派生クラスのデストラクタでなにもしないなら、
基底クラスのデストラクタを仮想にしなくてもいいですか? >>250
自由にクラスを設計すればいいよ。
デストラクタを仮想クラスを必ず定義しておかなければならないとか、そんな義務はない。
あらかじめ定義しておくと、仕様変更があった時などで、派生クラスで、デストラクタを使いたい時に、基底クラスをいじらずに定義できるだけだよ。
仮に、複数人で、アプリを作ってるなら、基底クラス担当がいたとして、わざわざ基底クラスをいじりますよーとか連絡しないでいいという利点はあるかもな。
もし、基底クラス担当で、他人に基底クラスを触らせたくないなら定義しておいたほうがいい。
基底クラスをいじられて、変なバグとか追加されても困るw >>250
規格は知らんが問題が発生するコンパイラは存在しないと思う。が、デストラクタで何もしないというのはデータメンバーも含まれるからね。
派生クラスにstd::stringのメンバーが居るだけでアウト
そんな事を気にするより素直にvirtual付けるか基底クラスでdeleteされないようにする方が有意義に時間を使えると思うよ。 >>254
>派生クラスにstd::stringのメンバーが居るだけでアウト
それだけでアウトなのではない
DerivedがBaseの派生だとして、実体はDerivedなのにコンパイラからはBaseにしか見えないケースで問題になるだけ
DerivedをDerivedとして宣言したらスコープを抜けたらちゃんとDerivedのデストラは呼ばる
問題なやつの例:
Derived g_d;
void foo() {
Base* p = (Base*)&g_d;
/*...*/
delete p; // Base::~Base()は呼ばれるがDerived::~Derived()は呼ばれない
} ごめ、一点抜けた
誤: 実体はDerivedなのにコンパイラからはBaseにしか見えないケース
正: 実体はDerivedなのにコンパイラからはBaseにしか見えない状態で当該オブジェクトが破棄されるケース
なお、(規格でどういう言葉使いをしているかわ知らんが、)
Derivedが多態性をきちんと実装してあるなら、Derivedは「コンパイラからはBaseにしか見えないケース」には該当しない ごめ、一点抜けた
誤: 実体はDerivedなのにコンパイラからはBaseにしか見えないケース
正: 実体はDerivedなのにコンパイラからはBaseにしか見えない状態で当該オブジェクトが破棄されるケース
なお、(規格でどういう言葉使いをしているかわ知らんが、)
Derivedが多態性をきちんと実装してあるなら、Derivedは「コンパイラからはBaseにしか見えないケース」には該当しない >>255
だから
「基底クラスでdeleteされないようにする方が」
って言ってんだろ 大事なことなので2回ry
まあ一般論として、>>255の問題なやつがプログラム内に存在しないことの確実で安価で
ウザく無い検出方法というものはこの世に存在しないので、
継承関係を使うならデストラクタを見たらvirtualにするパブロフの犬に徹するべきではある >delete p; // Base::~Base()は呼ばれるがDerived::~Derived()は呼ばれない
~Derived()が呼ばれないけど、
呼ばれたとして何も仕事をしないのであれば、呼ばれなくても不都合ないのでは? なにも仕事をしないデストラクタという前提がおかしいのですか? メイヤーズが言ってる
ポリモーフィズムを目的とした基底クラスはvirtualデストラクタにする
それ以外はしないってルールでいいだろ >>261
Yes
デストラクターの仕事はプロクラマーの書いたコードだけではない >>260
このあたりで話題になったことがある。
https://echo.5ch.net/test/read.cgi/tech/1478440682/651-
結論から言うと不都合は有る。
少なくとも言語仕様上は未定義に踏み込むのでクラッシュしても泣かない強い心を持ち合わせているのでなければやらない方が良い。 >>254
暗黙的なメンバー変数の破棄が呼ばれるべきってのはあるけど、何もアウトなことはないぞ? >>259
その考えはどうかと思うけどな
vtblが邪魔になるような、メモリ上では純粋にデータしか持たないクラスとか作れなくなるぞ 継承関係を使う=vtbl
と考えてしまうような無知な者には理解するのは難しい
他人の作ったものも構わずナマポをdeleteしておいて「virtualにしておけば安全」というのはマッチポンプと言えよう 正直何を言いたいのかはよくわからん w
まあ>>251みたいな頓珍漢野郎なんだろう... >>270
いや、この件に関してはお前の方が無知だぞ 結局のところ
何も仕事をしないデストラクタはあるが、(空のデストラクタかつメンバ変数なし)
基底クラスのデストラクタだけで派生クラスをdeleteすることが未定義だから
基底クラスのデストラクタは仮想にしないとダメという理解でよろしいでしょうか。 デストラクタは仮想にしておくことにより通常の仮想関数と違って継承元辿って全自動ですべて呼び出されるから基底はやることなくても以後継承で実装を変更することがあるのなら空の{}で括っておいたほうが良いよ もしかして本当に継承使ったPOD型に思い至ってないのか くそー>>254の簡潔すぐる日本語のせいで暗黒の日曜日になってしまったわ、
だいたい質問者の>>250も簡潔すぐる
初心者質問と思ったし、だいたい理解している上で確認の意味で質問しているのならそう書いてホスイ、 もうここ完全に初心者様質問無しにしろよ
上級者様もそれで満足だろ >>278
漏れのように語りたい初心者は一体どうすれば…orz これまでinlineを関数に適用するとインライン展開されるんじゃなかったでしたっけ?
c++17の説明を読むと翻訳単位で共通のアドレスになるって書いてあるのだけど仕様が変わった? 何を言っているんだお前は
ISO/IEC 14882:1998 7.1.2/p4
An inline function with external linkage shall have the same address in all translation units 以前void f(A &a, int num)をa.f(num)みたいに呼べる機能が追加されるとかされないとかを見た気がするんだけど知ってる人いたらURLか機能名を教えてほしい ウニファイドコールシンタックスは死んだのだ。
よみがえれ! accelerated c++ をやっている人いませんか?
今やりなおしているけれども、5年ほど前の自分の回答をなくしてしまった…
4章章末練習問題4-6の回答を、よろしければお見せいただけませんか?
この章、EOLine と EOFile を std::cin の eof フラグ 1 個でなんとかしようとしているのが非常にまずいと分かりましたが
逆に教科書掲載のプログラムでうまくいっているのが不思議です…取り組まれた方のコメントをお待ちしています…
普通 getline() をつかうんだろうけれども、なんでこんなに変てこな実装になっているのだろう?
教科書の内容 https://ideone.com/rdtZWG
>>44-45 悪書を薦めてしまいました、ごめんなさい >>289
メソッドチェインしたいだけなら拡張メソッドの方が筋がいいだろ。そっち応援してやれよ 拡張メソッドってデコレータパターンで充分なのに、なんで最近の言語には結構ついてんだろ。 >>292
>>44-45
結局のところ、std::stringstream を使うべきだという結論になりました。(std::stringstream は今回初めて知った)
教科書本文(64ページ、項4.2.3、70ページ、項4.5)
https://ideone.com/F761bo
73ページの練習問題4-5の方は
https://ideone.com/H9iE4j
このように >>42 は多大な努力を強いられる教科書ですので、お勧めです、強くなりたい人はどうぞ
私はもう強くなくてもいいから、この本はもういいです…
教科書をお持ちでない人には関係ない話ですみません >>285
別に驚くほどのことじゃないし…
関数のインライン展開と、同じ機能の非インライン関数の存在は両立する
>>284の規定は関数のアドレスをとられたときのため用 >>151
template の話もお願いしていいですか?
型安全を優先するあまりに instantiate(これいい訳がないね) してまで、という思考と void * を許してしまう思考の両方について、比較していただくとうれしいんですけれども >>168
std::make_shared はあっても unique 版はない、とかなんとか、そこらへんが徹底されていない、とか、確かあったような気が >>150-152
ファイルのopen/close とか、RAII /デストラクタが Java にもあればなあ、と思っています。
あと、Java の syncronized って、結局、テキトーなダミー変数を mutex 代わりにしちゃう、とかありません? >>115
古来ゆかしき Boehm GC を思い出しました。これ、C++11 later とかの対応はどうなんだろう?
http://www.hboehm.info/gc/ よくわからん… >>101
>K&Rも「関数ポインタも使えるよ」としか書いて無い。あれはもっと力説されて然るべきだった。
これが本題かな?
いや、関数ポインタってそんなに特筆すべきものだったかな…むしろ setjmp()/longjmp() の方がインパクトが、ってこれはexception として広く採用されていましたっけね
いや、関数ポインタってコールバック(とvtable)は別として、何か使えるネタが他にあるかなって考えてました、今のところ思いつかないな… >>99
>(instance.method()とstaticMethod(instance)の実行時の違いがほぼ無い、
うーん、Java で、これでもか、これでもか、と this が null でないことをチェックするのを読んだことがあります。
C++ だと(virtual でなければ)普通に this = 0 にして this->method() できちゃうんですが、この this の null チェックって、広く行われているのでしょうか?http://codepad.org/gtEBWFKR これでおしまい
try〜catch はいいとして、finally って使いにくい、というか使い方がわからないんですが、finally って意味あるんでしょうか? > RAII /デストラクタが Java にもあればなあ、と思っています
RAIIは7年前にジャバに入った筈だが
何を言っているのだろうか >>305
C++ 的にはなるべくデストラクタで後始末がつくようにやれというスタンスっぽい >>304
C++ ではヌルポインタからメンバ関数を呼び出すのは未定義だよ。
メンバ関数内でデータメンバにアクセスする要素がなかったとしても未定義。 this->method()は(*this).method()と等価で、ぬるぽに*適用したらその時点で未定義だからアウト 未定義だけどvirtualじゃなきゃ大抵動く
だからNULLチェックも意味がある thisをNULLチェックするようになったらそれはもう終わってるコード >>305
catchの中で再スローしてもとにかくリソースを解放したいとか普通にあるでしょ >>315
RAIIを徹底すればそんな危なっかしいことは不要 >>309
自分にレスすんなよ
見てて恥ずかしいだろ >>300
std::make_uniqueがあるだろうが(C++14) 返答を期待しないでただ聞いて文句言ってもらいたんですけど
03以来久し振りにc++いじってます
17だか20の最新仕様も未だにclassでgetter/setter定義しなきゃいけない仕様なんですかね?
C#のpropertyがあれば便利と思うんですけど。今あるか知りませんが
どうなんでしょ?今後の仕様も導入予定なし?
おやすみなさい >>311
いや、俺は意図通りに動かない場合にガチで遭遇したことあるからこれはホントにお勧めしない。 >>320
そもそも、せったげったってそんなに重要か? 一応 >>324 を解説しておくと、 this が真のときはもちろん真だし、
this が偽 (ヌル) のときは未定義なのでどういう挙動をしてもかまわないので真と解釈してもええやろという超推論で常に真として扱われる。 できないよ
thisは常にconst修飾されている
禿本1stではthisへの代入があったんだけどね >thisは常にconst修飾されている
それは規格のどこに書いてあるのですか ■ このスレッドは過去ログ倉庫に格納されています