C++相談室 part137

2018/08/27(月) 16:02:00.94

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

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

前スレ
C++相談室 part137
https://mevius.5ch.net/test/read.cgi/tech/1531558382/

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

■長いソースを貼るときはここへ。■
　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

2018/09/05(水) 00:30:09.32

ｺｺにｻﾝﾌﾟﾙｺｰﾄﾞがある
http://eternalwindows.jp/ipc/namedpipe/namedpipe02.html

FILE_FLAG_OVERLAPPED　を追加する
よく分からんがｺﾚとはまた違うのか

2018/09/05(水) 00:37:34.35

>>224
FILE_FLAG_OVERLAPPEDの使用はまだ試してないので明日試してみますありがとう
FILE_FLAG_OVERLAPPEDに関しては持たないときの条件を使ってたんだけどだめだったんかな...

これをしたかったのだが...
https://msdn.microsoft.com/ja-jp/library/cc429611.aspx
hNamedPipe ハンドルが FILE_FLAG_OVERLAPPED フラグを持たないとき、かつ、lpOverlapped パラメータで有効なポインタを指定したときは、この関数は非同期的に実行されます。
制御はすぐに返り、戻り値は 0 になります。GetLastError 関数は、ConnectNamedPipe 関数を呼び出す前にクライアントプロセス側が接続されていたときは
ERROR_PIPE_CONNECTED を、そうでないときは ERROR_IO_PENDING を返します。

peekNamedPipe読んでるけど難しい

2018/09/05(水) 01:24:39.22

peekで調べるのはcbAvailだけ
データは読まなくていい
読むときはReadFile

2018/09/05(水) 02:51:54.52

C++関係無いよね
Win32APIスレに行くべきだと思う

https://msdn.microsoft.com/ja-jp/library/windows/desktop/aa365146(v=vs.85).aspx
こっちにはその部分に相当する箇所が無いようにみえる

FLAG_OVERLAPPEDの有無で非同期/同期は決まるんじゃないのかなぁ
>If hNamedPipe was not opened with FILE_FLAG_OVERLAPPED, the function does not return until a client is connected or an error occurs.
ってあるし

2018/09/05(水) 12:47:17.08

>>223
>クライアント側が居なかった場合、ずっと待機し続ける

パイプって、パイプラインにデータが流れてくるまでは、ブロックされるものだろ。
データも流れて来ないのに、先へ進んだら、バグるだけ

その際、非同期なら、データ無しで、即座に返答が返ってくるのでは？

2018/09/05(水) 13:15:20.01

入力が「まだ来んからちょ待っとれ」なのか
「来るわけないやろアホかおまえ」なのかは
別の手段で判断せにゃならん

2018/09/05(水) 15:48:09.73

まあ常識的には適当な時間でタイムアウトするようにするくらいのものかな。

2018/09/05(水) 16:08:15.65

>>221
https://stackoverflow.com/questions/14306499/non-blocking-connectnamedpipe-event-not-getting-signaled/14306743

PIPE_NOWAIT を使えば ERROR_PIPE_LISTENING だの ERROR_IO_PENDING が即座に返されるが
WaitForSingleObject は発火しない

PIPE_WAIT だと当然ブロックする
PIPE_NOWAIT はlan managerとの互換性のために残されているだけで使用は推奨されていない

面倒でも FILE_FLAG_OVERLAPPED を使うしかない

2018/09/05(水) 16:09:55.39

と書いたけどカッコつけずに後先考えず PIPE_NOWAIT でポーリングしてもいいか

2018/09/05(水) 18:53:58.76

void hoge(int x, int *returnint){
returnint = int * 2;
}
int hoge(int x){
return int * 2;
}

これって内容同じですか？

2018/09/05(水) 19:15:02.29

どっちもコンパイルエラー出る点では同じ

2018/09/05(水) 19:32:27.66

>>233 C言語に対して重大な勘違い、または質問レスに些細な打ち間違い、
どちらかだと思うが、どちらかは分からない。

**235** (ﾜｯﾁｮｲ 9593-kT/R) · 2018/09/05(水) 19:33:03.57

C言語じゃなくてC++だね、ここ。

2018/09/05(水) 22:59:59.06

selectしろや

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-3+v7) · 2018/09/05(水) 23:22:24.89

>>215
内容をみてくださり感謝いたします、とても考えさせられました

まず >>211 に二点誤りがありました
・コンストラクタ引数に与える bit 数から、内部 vector<atomic<int>> の確保容量を計算する方法に誤りがあった
・CAS 後にスピンロックするかどうかの判断にあやまりがあった

修正 https://ideone.com/nwcmzq

>>215
＞while (!_v[q]. _a.compare_exchange_weak(e, e|(1<<r)) {}
＞while (!_v[q]. _a.compare_exchange_weak(e, e& ~(1<<r)) {}
＞(e は未初期化状態でも構わない）

>>195 「やりたいことはエラトステネスのふるいなので、この場合オンしたあとオフすることはありません」
に範囲を限定するのならば >>215 はうまくいくと思います。これには「なるほど！！」と思いました。

ビットセットの最中は別スレッドのビットリセットやビットテストをスピンロックさせたい、
とかの排他制御をやるのならば、dirty-bit（というか1ビットセマフォ）を作らないといけないと考えています

2018/09/06(木) 02:04:16.57

>>234,235
すみません
C++にあまり詳しくないのでわからないのですが、どこがおかしいのでしょうか？
これなら内容等しいですか？

void hoge(int x, int& ret){
ret = int * 2;
}

int hoge(int x){
return int * 2:
}

2018/09/06(木) 02:08:35.51

それはギャグで言っているのか？

void hoge(int x, int& ret){
ret = x * 2;
}

int hoge(int x){
return x * 2:
}

2018/09/06(木) 02:15:35.03

>>240
すみません素でボケてました…
それなら同一ですか？
returnする場合と参照渡しする場合の違い(速度など)があるのか知りたかったです

2018/09/06(木) 02:38:44.74

えーっと、
上段の参照渡しは呼び出し時に渡した変数そのものがやってきて書き換える。
下段のやつはコピーを返すので一手間ある。

理論的には下段の方がちょっと遅い。
まぁ、コンパイラが頑張ってきえるかもしれんし、
デルタ時間的に差はあるかもしれないが最近のコンピュータならあまり問題にならない。
それよりも速度を気にするなら採用しているアルゴリズムを精査したほうが効果的。

ちょっと変な文になった。

2018/09/06(木) 05:45:03.77

厳密なところはアセンブラ出力を個別に見ないと分からない、
という前提はひとまず措くとして…。

int x, ret1, ret2; // x が未初期化ってところは見逃してくれ
hoge_ref(x, ret1); // void hoge(int x, int& ret)
ret2 = hoge_val(x); // int hoge(int x)

上は第2引数に参照を渡す手間が必要な代わりに返り値の処理は不要
下は引数1個で済む代わりに呼出側で返り値を別の変数に代入しなきゃいけない
相殺してどっこいどっこい大差なし、じゃないかな。
計算結果を変数に入れる必要がない場合、等はまた別のお話。

2018/09/06(木) 05:49:16.79

>>240
後者の末尾がコロンになってるのがそのままやで。

2018/09/06(木) 05:59:16.76

仮に差があったとしてもナノ秒レベルの話やん

2018/09/06(木) 07:14:55.98

速度どうこうは1兆回回すループの中にあるとか1マイクロ秒以内に完了しないと原子炉が爆発するとか
プロファイラでクソ時間がかかってることが判明したとかした時だけ気にしよう

**243** (ﾜｯﾁｮｲ 5393-WN3X) · 2018/09/06(木) 08:27:46.68

実際のところ「別のお話」と切り捨てた部分が大切でね。
元の質問から逸れてしまうけど。

関数が計算する結果の値だけが欲しい(別の変数に格納する必要がない、
格納すべき変数そのものが存在しない)場合とか、
返り値に相当するのがint等の単純なデータでなく大きなクラスの場合とか、
その辺りを基準に比較すべきなんだよ。

2018/09/06(木) 08:44:12.19

早すぎる最適化は諸悪の根源っていうもんな。

2018/09/06(木) 08:51:51.10

同意。固定長オンリーなどの最適化を最初から入れ込むとロクなことがない。

2018/09/06(木) 09:29:04.75

そーそー
尻拭く時間だけ早くしてもンコが早く出なきゃしゃーない

2018/09/06(木) 10:29:33.35

>>242
何言ってんの、逆でしょ
差が観測できるかは別にして下の方が速い(効率的)
int返すならレジスタ返しなんだから
メモリアクセスよりずっと速い

2018/09/06(木) 10:57:52.18

>>251
関数単独を見るとそうだが、
レジスタで返してもそれを結局は変数に書き込むじゃんという >>243 の話と合わせて考えると
レジスタを経由する分だけ遅くなり得るっしょ。
ただ、この関数を実行した結果を長期には保存しない (式の途中でこの関数を使うとか) のだと
後者の方が速かったりもするだろうし、まあ、状況によるよな。

2018/09/06(木) 10:58:36.13

実際のところ、インライン化されて更に他の最適化とコンボが起こったりすると
普通の人間にはどうなるか予測がつかんので考えるだけ無駄。

2018/09/06(木) 11:15:06.66

>>252
なんで呼び出し側の話がはいってくるんだよ
そっちの話を含めるとしても
呼び出し側もレジスタのまま処理が行われるのが普通だし、
メモリに書き出されるとしても、
参照と同程度になるってだけ

このABIを理解するのはc/c++使う上で基本
無意味と思うのは結構だがそれはお前の関心がないってだけ
レスしなけりゃいい

2018/09/06(木) 12:11:07.39

intの場合は速度差は特に考慮しなくて良いんですねありがとうございます
それと、関数内でOpenCVで画像をゴニョゴニョして、結果の画像をリターンしたい場合は、どちらが良いのですかね？
特にメモリリークを起こしたくない(今現在起きてるので改善したい)ので、もし何か重大な違いがあるなら知りたいです

void hoge(cv::Mat x, cv::Mat ret){
ret = x + cv::Scalar(100);
}

cv::Mat hoge(cv::Mat x){
return x + cv::Scalar(100);
}

2018/09/06(木) 13:28:43.07

>>254
呼出し側の状況によっても変わりうるから呼出しの状況を含めるってのがそんなにおかしな話かね。
あと、あくまでもこれは C++ という言語を中心にした一般原則としてどうコンパイルされることも「有りうる」ということを述べているのであって、
特定のアーキテクチャやコンパイラや ABI を想定したものではないよ。

多くの (あるいは主要な) 処理系であなたが言うような結果になるというなら、
それはそうかもしれないが、そこには単に私の関心がないのも確か。

2018/09/06(木) 13:34:38.93

>>255
前者のコードの cv::Mat ret は cv::Mat& ret の間違い？

2018/09/06(木) 13:53:20.00

>>256
それはお前の間違った理解であって一般とは言わない
だいたい呼び出し側も含めて反論されてんのになにぼけたレスしてんだよ

お前の理屈だとレジスタの返しが無用となるじゃないか
x64ならraxでaarch64ならx0で返り値を返す
32bitのレガシーならいざしらず64bitでもabiはそう決められてるわけ
お前の興味のない低いレイヤーではそういうのを最大限活用して効率的にcpu回してんだよ

2018/09/06(木) 14:06:16.01

>>258
> だいたい呼び出し側も含めて反論されてんのになにぼけたレスしてんだよ

それは >>254 のことだろ？
それは特定の命令セットや ABI でないと成り立たないから、
そうでない一般論としてはどうともなりうると私は言っているので論点が違うし、
私はそっちの論点は気にしてなかったという話じゃないか。

2018/09/06(木) 14:09:29.47

>>259
現実のはなししようぜ
成り立たないシステムあげてみなよ

2018/09/06(木) 14:11:05.68

>>255
知らんな。
関心は無い。

2018/09/06(木) 14:27:25.26

>>255
前者については & の脱字だと仮定して答えるけど、
その脱字が無ければ、前者でも後者でも最終的な結果に差はないと思う。
特にメモリリークにつながりそうな要素もない。

ただ、単純に、局所的に考えるならば後者の方が効率的と言えると思う。
前者だと呼出し側では結果を受け取るための cv::Mat 型の変数を用意しなければならないが、
そのときにデフォルトコンストラクタが走ってから結果は operator= で格納するという形になる。
後者だとコピーコンストラクタ一発で済むので簡単。場合によっては RVO が適用されるかもしれない。

一度作った変数を何度も結果格納用に使いまわすのならば、
前者の方がメモリアロケーションの回数を抑制できる (効率的になる) 可能性も有るけど、
Mat の実装次第ではそうならないかもしれないし、
そこらへんは実際にやってみないとわからない。

ところでメモリリークが起きていると判断したのは何かツールを使って検証したの？

2018/09/06(木) 14:31:00.99

あっ、 >>261 で >>255 にアンカーを付けちゃったけど、これは >>260 の間違いね。

現実の話というなら、インライン化や最適化が入れば ABI もクソもねぇし、
そんなの考えたらキリがないやろ。

2018/09/06(木) 18:25:26.14

>>263
関数内の最適化のみで考えればいいだけなんだからきりはあるだろ
つまりインライン展開なし、LOTなし

ABIを意識するのは全然特殊じゃない
言語間のよびだしはざらだし、
クラッシュダンプにスタックトレース残すためにあえてインライン抑制したりする
お前が経験不足なだけだよ

2018/09/06(木) 18:41:01.02

>>264
そっちの脳内でどんな前提を置いてるかなんて知らんがな。

2018/09/06(木) 19:48:52.61

>>265
コテハンの割に薄いやつだ

もとの質問は関数から値の返し方についてどちらが速いかという質問なんだから、
関数のインライン展開がないと仮定すれば、定性的に答えられる問いだ
かつその仮定は別に現実ばなれしてるわけでもない

それをお前はその知識が有用であることも知らずに考えるだけ無駄とかぶったぎってるわけだ

このスレは相談室
無駄なのはそういうお前の存在ではとおれは思うわけ

2018/09/06(木) 20:12:24.70

malloc()したﾋｰﾌﾟはfree()解放するのは当然
ｳﾝｺしたあと水で流さないぐらい行儀が悪い

2018/09/06(木) 20:23:27.14

メモリーリークは基本的に自分でNEWすることで起こる。
最近のC++では基本的に自分でNEWすることはほとんどない。
動的なメモリが欲しければvectorを使う。
後は、ポインタにインスタンスを確保しないで関数に投げるとかもやってはいけない。メモリを破壊することになる。
あと、どうしてもnewが必要だったりGCが必要な時はスマポを使う。

そういう作法でやると、ユーザーコードでnewすることはほぼない。

2018/09/06(木) 20:47:20.81

えーっと、関数にポインタを投げる時はその関数の仕様を精査して扱わないとほんとやばい。

2018/09/06(木) 21:04:04.33

newとdeleteを使いこなせない補助輪付C++グラマってのも問題だけど

2018/09/06(木) 21:10:02.71

スマポはGCじゃねえよぼけ

2018/09/06(木) 21:14:09.31

shared_pointerは参照カウントっていうGC機構ですよ？

2018/09/06(木) 21:17:21.85

>>270

2018/09/06(木) 21:18:00.66

おっと。
>>270
補助輪があろうがバグ出すよりマシだと思うよ。それと保険的な意味もあるし。

2018/09/06(木) 21:18:22.90

CGってそもそも何だ？
アプリが「今、解放しろ」というタイミングで動くのをGCというならfreeもGCだぞ

2018/09/06(木) 21:20:24.16

いつ解放されるか分からないとか
そもそもｵﾌﾞｼﾞｪｸﾄの外部でﾎﾟｲﾝﾀの生存期間を制御できてないｺｰﾄﾞがﾔﾊﾞｲわ

2018/09/06(木) 21:24:58.09

>>275
そういう、広義解釈は話題が滅茶苦茶になるのでやめましょう。
GCはガベージコレクションだよ。freeは解放関数だよ。
シェアードポインターの解放タイミングは普通コントールしないのでGCだと思ってます。
というか、開放タイミングが未定だからシェアードポインタ使うんじゃないですか？

2018/09/06(木) 21:27:59.96

それは全能でないとバグが出ちゃうのでこういう機構が発明されました。
書くときは大まかには寿命は把握しているとは思うのですが、細部までは精査しないことが多いんじゃないでしょうか。
自分のクローンに共有オブジェクトを持たせるときとか普通に書くと滅茶苦茶大変ですよ？

2018/09/06(木) 21:37:24.49

>>277
広義解釈してるのはおまえだよ
シェアードポインタの解放タイミングはデストラクタだろうがよ
freeと何がどこが違うんだよ
おまえどこまでオレオレ空想してるんだ？

2018/09/06(木) 21:38:17.39

>>276
それはある程度アクセス権の範囲を考えれば何とかなりそうな予感。
それと開放した後のメモリ叩かれた時とどっちがいいか相談ってことで。

2018/09/06(木) 21:41:02.92

>>279
複数の共有がある場合、一個のデストラクタが走った程度では解放されませんよ？
freeは別にデストラクタに仕込む必要ないじゃないですか。
それと、複数の共有がある場合適切にfreeできますか？

2018/09/06(木) 21:42:45.15

コレクションしてないのになんでgcなんだよ。アホすぎる

2018/09/06(木) 21:43:23.10

シェアードはマルチタスクには不向きだし

2018/09/06(木) 21:49:40.12

コレクションサイズが1のコンテナはないのですね。まぁ、冗談は置いといて。
物事を知ってるなら後は任せました。無知でごめんなさい。

2018/09/06(木) 21:51:04.10

>>283
マルチスレッドならアトミックにできた気がしますけど、どうでしたっけ。
マルチプロセスならそもそもメモリ空間が違うのでお門違いですね。

◆QZaw55cn4c (ﾜｯﾁｮｲ da60-Mhaf) · 2018/09/06(木) 22:00:46.00

>>272
参照カウンタは普通GCに含めないのでは？

2018/09/06(木) 22:02:22.60

https://ja.wikipedia.org/wiki/参照カウント
こういう記事を見つけました。

2018/09/06(木) 22:04:19.65

ホントお前ら人殺すことばっか考えてるよな。
そういうのは良いから初心者殺すのマジやめて。

2018/09/06(木) 22:04:41.28

gcの一実装として参照カウンタ方式があるだけで、スマポはgcじゃない。

2018/09/06(木) 22:06:33.66

それならそれでいいです。

2018/09/06(木) 23:18:28.17

>>288
横からでスマンが、他の初心者に偉そうに大嘘教えてるやつを初心者とは普通呼ばない
都合のいいときだけ初心者ヅラはだめよ

2018/09/06(木) 23:34:23.61

>>262
ありがとうございます
forの中で何回も関数呼び出すので前者が良さそうですね

2018/09/06(木) 23:34:43.07

>>291
嘘の範囲を限定しないと俺大罪人じゃないですか。
まぁ、いいや。

メモリーエラーで落ちろ。

◆QZaw55cn4c (ﾜｯﾁｮｲ da60-Mhaf) · 2018/09/06(木) 23:34:53.93

>>289
スマートポインターのうち std::shared_ptr は参照カウンタを内蔵しているのだから
①参照カウンタが GC、故に、std::shared_ptr も GC
②参照カウンタが GC でない、故に、std::shared_ptr は GC でない
①②のどちらかしかない
参照カウンタが GC なのにスマートポインタが GC でない、というのは矛盾しているのでは？

私は「参照カウンタは GC じゃない」と思う

2018/09/06(木) 23:48:27.91

>>293
>>251
もちろんインライン展開される場合は除く（展開されたら多分同じコードになると思うが

あと
>>255の質問に対して>>268は不適切、>>268から話が変な方向に行ってる
OpenCV使ってるって言ってるし、間違った使い方してリーク（>>255がnewしたのではない部分）
の可能性の方が高いと思うけどね

2018/09/06(木) 23:52:47.61

>>294
なにも矛盾してないよ。

GCの一実装として参照カウント方式を使ったものがある。
スマホの中に参照カウントを使ったものがある。
だからといってGC=スマポじゃない。

エンジンで走る車があって、エンジンで飛ぶ飛行機があっても、車は飛行機じゃないのと一緒

◆QZaw55cn4c (ﾜｯﾁｮｲ da60-Mhaf) · 2018/09/07(金) 00:04:30.19

>>296
＞エンジンで走る車があって、エンジンで飛ぶ飛行機があっても、車は飛行機じゃないのと一緒
is-a の話の例えに has-a の話を使うのは論理的ではありませんね
「車 has エンジン、飛行機 has エンジン」の話と「参照カウンタ is GC、スマポ is ＧＣ」の話は別ですよ

2018/09/07(金) 00:12:24.59

>>297
いやgc=参照カウンタなんて言ってないんだけど。
gcに参照カウント方式を使っているものがあるといってるの。はじめからhas_a関係しか言及してない。

◆QZaw55cn4c (ﾜｯﾁｮｲ da60-Mhaf) · 2018/09/07(金) 00:15:18.97

>>298
＞いやgc=参照カウンタなんて言ってないんだけど。
そこに「＝」記号を使うのがおかしいのでは？
真偽は別として、記号を使うのなら ⊂ とか ∈ じゃないですか？

2018/09/07(金) 00:17:33.32

参照カウンタは GC だろ。

2018/09/07(金) 00:22:54.57

>>266
元々の質問はどちらが速いかではない。

◆QZaw55cn4c (ﾜｯﾁｮｲ da60-Mhaf) · 2018/09/07(金) 00:53:47.67

>>300
では std::shared_ptr も GC でしょうか？

2018/09/07(金) 01:28:57.33

>>302
私は std::shared_ptr を GC だと思ってるよ。
解放のタイミングがコンパイル時に確定しないようなのは GC だろってくらいのカジュアルな認識だけど。
基準の妥当性はともかくとして、とにかく私はそういう基準で考えてる。

QZ 氏の中で std::shared_ptr と GC を隔てるのは何だと思ってるの？

2018/09/07(金) 02:17:04.39

Qt5触ってみてるけど生ポインタばっか使ってて気持ち悪い、これでいいのか？

2018/09/07(金) 07:52:15.03

GC ⊇ shared_ptr

2018/09/07(金) 08:31:14.42

>>304
生は触って気持ちいいものしかないよ

**デフォルトの名無しさん** (JP 0He6-O+me) · 2018/09/07(金) 11:18:53.99

parentクラスがあってそれを継承したchildクラスがあります。
vector<parent*> getParentlist(){//省略}でこんな感じでparentクラスのポインタのリストを返す関数があります。
それでここからが質問なのですが、
vector<child*> childList = (vector<child*>)getparentlist();
こういうコードがあってびっくりしています。
機能はしているみたいですがこれ作法的にオッケーなんでしょうか。
ダウンキャストは良くないと聞いていたりそもそもこれダウンキャストなのかとかちょっと分からないんです。
よろしくおねがいします。

2018/09/07(金) 11:20:41.99

>>281
話が通じてないなあ。。。
デストラクタでuse_count見てるのは当たり前だろ
シェアードポインタの話だぜ？

解放のタイミングがアプリのロジックに従属してるかどうかって話なのに
何を言い出すかと思えば

2018/09/07(金) 12:35:44.17

>>307
試せる限りのコンパイラではそもそもコンパイルエラーだったけどなぁ
vector<parent *> &getParentlist();
じゃなくて？？
その上で
(vector<child *> &)getParentlist();
なら通るよ、通るし普通に使えるはず

**デフォルトの名無しさん** (JP 0He6-O+me) · 2018/09/07(金) 13:23:59.20

>>309
失礼しました。ポインタ抜けてました
vector<parent*>* getParentlist(){//省略}
で
vector<child*>* childList = (vector<child*>*)getparentlist();
こんな感じです

2018/09/07(金) 13:38:44.48

おいおい・・・ｗ

ポインタでも同じことだ、そのキャストをreinterpret_castだと考えたらわかるはず
それでわからないならC++の継承の仕組みを勉強すべき

2018/09/07(金) 16:38:51.51

基底方向へのキャストの実態は
サブオブジェクトまでのオフセット分だけアドレスをずらす操作なので、
>>310 のような場合にはそれは実現できない。
単に無理やり型を合わせているだけになってしまっている。
C++ 的にはあかんやつ。

ただ、実際に動いている理由をあえて考察するなら、
child が parent を単一継承した場合などには parent が child の先頭に配置されるようなメモリレイアウトにコンパイルされる可能性が高く、
アドレスをずらす量が 0 で済んでしまうので
型を読み替えるだけでも不整合が顕在化せずに動作してしまうということは有りうる。
あくまでも、処理系がやってることが偶然に組み合わさって動いているというだけなので、やめといた方がよい。

2018/09/07(金) 17:46:14.93

そこまでご丁寧に説明してやるのなら、「Cスタイルのキャストは使うな」、を教えるべきじゃねーの？

2018/09/07(金) 18:34:49.58

parent * が child * なのかも分からないのに強引にキャストするのか
そこまで型無視するなら void * でいいんじゃない知らんけど

2018/09/07(金) 20:57:02.69

>>313
せやな。

2018/09/07(金) 20:57:32.70

C++ スタイルのキャストを、特に入門者の内は static_cast だけ使っておけばまあまあ大丈夫。
static_cast でエラーになるような変換は C++ 的にはだいたいイケてないやつ。

2018/09/07(金) 20:59:50.93

アホか
dynamic_castが使えないくせに初心者皆伝なんぞやれん

◆QZaw55cn4c (ﾜｯﾁｮｲ da60-Mhaf) · 2018/09/07(金) 22:12:33.50

>>303
＞私は std::shared_ptr を GC だと思ってるよ。
…GC発祥の地 lisp の使い手のはちみつさんがそうおっしゃるのなら、私の中の定義も書き換えないといけませんね
mark and sweep GC って、プログラム本体とは関係のないところで、それこそメモリの死にビットをも使ったりして、ごそごそやる、というイメージがあります

＞解放のタイミングがコンパイル時に確定しないようなのは GC だろってくらいのカジュアルな認識
＞std::shared_ptr と GC を隔てるのは何

「解放のタイミングを図る機構が表のプログラムとは独立している」
くらいでしょうか？表のプログラムからの参照が途切れることと free() されることに直接の関係性がない mark and sweep とその発展型のみを GC とみなしています
といって、GC の本は一冊しか持っていません

2018/09/07(金) 22:36:10.40

は○ち○餃子はLisperか

言語選びは慎重にな！
ttps://postd.cc/lisping-at-jpl/

2018/09/07(金) 22:37:40.84

>>318
定義がひとつでなきゃならないとは思ってないよ。
だから自分なりに一貫した考え方があるのなら、それはそれでいいんじゃないかな。

ただ、「表の機構と分離されているか」という考え方だと、それは抽象化の仕方であって、メカニズム (アルゴリズム) の基準ではないね。
その基準だと std::shared_ptr が GC ではないとは言えても参照カウンタが GC ではないとは言えない。

2018/09/07(金) 22:45:54.86

お返事遅れました>>213です
Overlappedの設定をCreateNamedPipe時点に引数として渡す構造体ことで同期制御を実現できました
ありがとうございました

メモリリーク探しきつい....

2018/09/07(金) 22:58:55.32

すみません質問があります

メインスレッドと通信スレッドがいて、
通信スレッドはメインスレッドのオブジェクトポインタ持ってます
メインスレッドはクラス化されており、スレッド用のstatic関数以外にもメンバ関数を持っています

通信スレッドがデータ受信して、メインスレッドの別のメンバ関数を呼び出した時、
メインスレッドで実行していた処理はどうなるのでしょうか？

メインスレッドで実行していた処理はあくまでもstaticな関数の処理で、staticでない他のメンバ関数は別に処理されるのでしょうか？

2018/09/07(金) 23:04:25.63

>>322
説明が分かり難いなぁ。

通信スレッドとやらから呼び出した関数は通信スレッド上で走っているし、
メインスレッドはメインスレッドで走っている。