C++相談室 part161

**デフォルトの名無しさん** · 2022/05/21(土) 21:23:29.59

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

**デフォルトの名無しさん** · 2022/06/25(土) 11:54:25.28

private踏んだりしたらエラーメッセージ見れば済む話だと思うが
class継承のときのpublicつけ忘れでprivate扱いになるのはやらかしてそう

class C{
public: static void f(){}
};
class D : public C{};

int main(){D::f();}

**デフォルトの名無しさん** · 2022/06/25(土) 12:22:32.29

>>306
エラーにならんが、何が言いたい？

**デフォルトの名無しさん** · 2022/06/25(土) 13:43:07.60

>>307
class継承のpublic忘れるとエラーになるよと言う話
2箇所あるpublicのどっちか消してみなよ

**デフォルトの名無しさん** · 2022/06/25(土) 13:45:13.45

static関係なくね？

**デフォルトの名無しさん** · 2022/06/25(土) 13:48:22.71

publicつけ忘れで

**デフォルトの名無しさん** · 2022/06/25(土) 13:49:20.71

>>309
staticもつけ忘れたのか
どんくさいなお前

**デフォルトの名無しさん** · 2022/06/25(土) 17:46:22.26

>>279
数論変換はしばし待たれよ卿、
NTT有名素数modとしてよく使われるのは
　998244353 = 2^23 * 119 + 1
やそうやがこれ単独では2^23桁で表せる数値までの計算しかできないことは確定的に明らか
10^5進数表記をとったとして2^(2^34)-1はで表して
　1034331189 > 2^29 桁 >> 2^23桁
なのでストレートにやるとしたら足りないのであっる

一方Six-step algorithmを導入したらば2^15桁までのFFTで済むから、NTT化が射程に入ってくる

というわけで漏れは天才の判断としてまず1の累乗根のFFT×Six-step algorithmを
OpenMPで激速化することを極めんとしているわけや；；；

**デフォルトの名無しさん** · 2022/06/25(土) 17:47:57.25

それと>>279の口ぶりでは数論変換にしたら桁違いに早くなるみたいに読めるが
double同士の掛け算2^15回分が
int64同士の掛け算2^15回分に高速化される程度であって現行のレコード145 秒が100 秒切れるようになるか
っていうとﾋﾞﾐｮｰ

はい論破、

**デフォルトの名無しさん** · 2022/06/25(土) 18:01:39.85

>>302の行間に書いてある通り、型引数意外の状況でだがtypenameキーワードが必要なケースが存在する
ていうかこれ↓
https://faithandbrave.hateblo.jp/entry/20080129/1201597743

逆に言うと
それ以外ならclassでええやん、、、

**デフォルトの名無しさん** · 2022/06/25(土) 18:04:28.52

アンカーミスったorz
誤: >>302
正: >>296

**デフォルトの名無しさん** · 2022/06/25(土) 18:25:49.29

またくっさいチラ裏ジジイが湧いたのか

**デフォルトの名無しさん** · 2022/06/25(土) 18:35:28.83

ﾊｲﾊｲここは高尚なインターネッツでつね；；；

**デフォルトの名無しさん** · 2022/06/25(土) 19:23:01.22

>>314
なんできゅうにそこのtypenameの話しだすの？
単に型パラメータんとこの話をずっとしてたんやないん今まで

**デフォルトの名無しさん** · 2022/06/25(土) 20:46:58.51

>>317
相変わらず誤字を直せねーのな

**デフォルトの名無しさん** · 2022/06/25(土) 21:53:15.48

次のセールってハロウィンなっちゃう？

**デフォルトの名無しさん** · 2022/06/25(土) 23:44:17.32

何の？

**デフォルトの名無しさん** · 2022/06/27(月) 01:22:11.44

steamかな

**デフォルトの名無しさん** · 2022/06/29(水) 12:39:09.60

>>300
>C++ってstaticメソッド継承されますっけ？
継承と言うか「可視」ではある。

>Parent.Hoge()ってChild.Hoge()としても呼べます？
staticメンバを参照したい場合は、インスタンス・メンバとは書き方が違って、
Parent::Hoge() や Child::Hoge()
と書く。

でも微妙だな、Child::Hoge()で呼び出せるかどうか、実験の必要はある。

**デフォルトの名無しさん** · 2022/07/01(金) 12:57:20.10

インスタンスからも static メソッドは呼び出せるよ
https://ideone.com/tpA9jy

**デフォルトの名無しさん** · 2022/07/01(金) 14:54:49.17

>>323
なぜ継承を可視と言い直すんだ？

**デフォルトの名無しさん** · 2022/07/01(金) 14:57:39.83

ヴァーチャンが使えないからだろ

**デフォルトの名無しさん** · 2022/07/03(日) 05:57:55.66

C++コンパイラっていつからconst char*型引数がbool型引数に暗黙変換されるようになったんだ？
以下のような内容が警告なしでコンパイルできてしまうんだが

int foo(bool bar);

const char* ptr = "test";
foo(ptr);

**デフォルトの名無しさん** · 2022/07/03(日) 07:53:18.35

スカラ型がboolに暗黙変換できるのは太古から変わってない

int (*p)(bool) = foo;
std::cout << foo; //出力は「1」だがfooが１番地から開始ということではない

**デフォルトの名無しさん** · 2022/07/03(日) 07:54:43.51

pいらんかったな、わりいわりいｗ

**デフォルトの名無しさん** · 2022/07/04(月) 13:56:35.75

みなさまこんにちわ！
暑い日が続きますが質問させてください。

namespace hoge
{
class foo
{
public;
void set(class member_ptr* arg){ptr=arg;}
private;
class member_ptr* ptr=nullptr;
};
}
という名前空間を作成し、それをmember_ptrが定義されているソース(およびヘッダー)ファイルで使用したいです。
ところがmember_ptr*をset()に渡したとき、「hoge::member_ptr*は member_ptr*と互換性がありません」というエラーが出てしまいｓます。
名前空間をはずすorポインタ関連の記述をコメントアウトさせると普通に動作するので、大まかなコード自体は問題ないと思うのですが……
リインタプリットキャストも出来ず困り果てておりますが、名前空間内部のメンバにポインタは持たせない方がいいのでしょうか？
それとも名前空間での不完全クラスでの定義がまずいんでしょうか？

ほとほと困り果てております。
わかる方がいらっしゃいましたらお教えいただけれう゛ぁ……
先感謝！

**はちみつ餃子** ◆8X2XSCHEME · 2022/07/04(月) 14:27:48.07

>>330
問題が再現するコードを提示してください。

**デフォルトの名無しさん** · 2022/07/04(月) 14:31:47.29

へたくそ

**デフォルトの名無しさん** · 2022/07/04(月) 17:28:39.11

どっかで
namespace hoge{
class member_ptr;
}
class member_ptr;
みたいなことやってるような気がする

前方宣言(か実体定義)が別の名前空間にあって、同じclassを見てるつもりで別のclassを見ているだけじゃない？

**デフォルトの名無しさん** · 2022/07/04(月) 17:47:01.88

>>331
長文になってしまいますがお許しください。
───────────────
//ptr.h
class ptr
{
public:
ptr(int arg) { a = arg; }
int a = 0;
};
───────────────
//Test.h
namespace Test {
class innerTest
{
public:
class ptr* get_mPtr();
private:
class ptr* mPtr;
};
}
───────────────
//Test.cpp
#include "Test.h"
#include "ptr.h"
ptr* Test::innerTest::get_mPtr()
{
return nullptr;
}
//↑この定義部分で「宣言に互換性がありません」というエラーが出てしまいます

**はちみつ餃子** ◆8X2XSCHEME · 2022/07/04(月) 18:04:55.71

>>334
class キーワードを付けた場合にはクラスの宣言を同時にしたものとみなされる。
つまり class ptr* get_mPtr(); と class ptr* mPtr; は「このスコープで」 ptr を宣言したかのように扱われる。
もちろん実際には innerTest の中では ptr の定義はないので不完全型のままだが、
この ptr は Test::innerTest::ptr のつもりで解釈されてる。
グローバル空間で定義している ptr とは別物なので別物というエラーになるわけ。

**デフォルトの名無しさん** · 2022/07/04(月) 18:34:14.66

class ptr;
namespace Test {
...

**デフォルトの名無しさん** · 2022/07/04(月) 18:53:01.66

Cのstructと同じ感覚でclassって書いちゃってるのかこれ

**デフォルトの名無しさん** · 2022/07/04(月) 18:59:50.67

>>335
> この ptr は Test::innerTest::ptr のつもりで解釈されてる。
Test::ptr だね。
https://timsong-cpp.github.io/cppwp/n4861/basic.scope.pdecl#7.2

**デフォルトの名無しさん** · 2022/07/04(月) 19:27:20.38

>>335!336,338
ありがとうございます！

おっしゃる通りに名前空間の外で前方宣言し、ソース部分で定義したらうまくいきました！
特に理由がない限り、名前空間内部で定義してはいけない(戒め)
ありがとうございました！

**デフォルトの名無しさん** · 2022/07/05(火) 15:17:54.21

有害だな

**蟻人間** ◆T6xkBnTXz7B0 · 2022/07/05(火) 20:29:56.62

You guy

**デフォルトの名無しさん** · 2022/07/05(火) 23:44:59.73

VB.NETからバイナリをC++(JNI)に渡して受け取ったバイナリをJavaに渡したいんですけど、C++で受け取ったBYTEをjobjectに変換する方法が分かりません。
どなたかご存知でしょうか。

**デフォルトの名無しさん** · 2022/07/06(水) 23:58:31.79

C++勉強中です。ムーブコンストラクタについて教えてください。
ムーブコンストラクタは、要はムーブ元の指すポインタをムーブ先に変更しているだけだと思います。
これはconstなしコンストラクタでも実現できると思いますが、意図を明示するためにコンストラクタが分かれていると思っていいですか？
また、ムーブコンストラクタの仮引数が右辺値参照になっている（std::moveした右辺値を渡す）理由がよく分からないのですが、これは決まり文句として覚えるしかないでしょうか？

**デフォルトの名無しさん** · 2022/07/07(木) 00:12:38.45

>>343
まさにその発想で作られたauto_ptrとかいうスマポ（廃止済み）がとんでもねえゴミカスだったから
その教訓でコピーとムーブが分けられたんだよ

**デフォルトの名無しさん** · 2022/07/07(木) 00:13:26.51

ムーブって、所有者が移転してると考えた方が
場所なんてどうでもいいでしょう

**はちみつ餃子** ◆8X2XSCHEME · 2022/07/07(木) 00:38:46.12

>>343
右辺値は大抵の場合に一時オブジェクトだからどうせすぐに破棄される。
後で別の場所で使うということがないと期待できるから内容を移動してしまっても問題にならないんだ。
だから右辺値を入力とするときは原則としてムーブ扱いにする。

**デフォルトの名無しさん** · 2022/07/07(木) 08:00:15.88

多分、右辺値参照イコールmoveと覚えてしまってるのでは？
C++11より前は一時オブジェクトとそうでないものを文法上区別することが出来なかったのよ
moveはあくまでキャストに過ぎない、一時オブジェクトでないものを一時オブジェクト扱いにしてるだけ

**343** · 2022/07/07(木) 23:27:53.10

一時オブジェクトにキャストしてすぐ破棄されるようにしたと言っても、
右辺値参照に代入しているのでヌルポインタにするまでは使い続けられますよね
そもそもstd::moveで一時オブジェクトにキャスト、これを右辺値参照で束縛して有効期間を延ばす…って
初めから普通の変数を使えばいいのでは？と思ってしまいました
ムーブを表すための仕組みとして&&とstd::moveの組み合わせが追加されたということなんでしょうかね

**デフォルトの名無しさん** · 2022/07/07(木) 23:44:43.71

>>348
結局そのあたりも含めてC++で複雑化した様々な点を全てシンプルに綺麗に整理し直して分かりやすくした言語が望まれてRustが登場したんだろうね

**はちみつ餃子** ◆8X2XSCHEME · 2022/07/08(金) 00:13:39.16

>>348
なんだかその文面からは仕組みを理解しているようには見えない。

**はちみつ餃子** ◆8X2XSCHEME · 2022/07/08(金) 00:21:33.36

>>348
何を言いたいのか全然わからない (仕組みを間違って理解しているか用語が誤っているかしている) ので
もうちょっと具体的に実例か何かで示してみて。

**デフォルトの名無しさん** · 2022/07/08(金) 06:38:25.68

教科書の言葉適当に並べて分かったふりしてる感がすごい

**デフォルトの名無しさん** · 2022/07/08(金) 08:04:48.18

ムーブは「所有権」をムーブさせるものなので、所有権という概念がないと理解できん

**デフォルトの名無しさん** · 2022/07/08(金) 08:29:23.83

>>349
引数渡しのデフォルトをmoveにしているのは失敗だと思うけどな。
性能優先でそうしたんだと思うけど、そういった技術的説明無いから設計ミスにしか見えない。

**デフォルトの名無しさん** · 2022/07/08(金) 09:59:25.74

>>354
あれは大正解
実際に色々なプログラミングをするとよくわかってくる
Rustは上手く設計されていることがわかる

**デフォルトの名無しさん** · 2022/07/08(金) 10:12:31.24

rustのご本が高くてのう

**デフォルトの名無しさん** · 2022/07/08(金) 10:20:08.07

右辺値参照って概念的に難しいよね
そもそも右辺値とはなんぞやというところから、一時オブジェクトの生成とそれが破棄されるまでのコンパイラ側の仕組みを的確に理解する必要がある
こんなのよく思いついたなと感心はするけどw

**デフォルトの名無しさん** · 2022/07/08(金) 10:47:23.92

テンプレート関数で頻繁に出現する=演算子コピーによるオーバーヘッドを減らす必要に迫られただけの話ジャマイカ？

**デフォルトの名無しさん** · 2022/07/08(金) 10:52:14.97

**デフォルトの名無しさん** · 2022/07/08(金) 12:00:52.61

>>353
「所有権」って言っちゃうと誤解を生むような気がする
実体としてはデストラクタを呼ぶ権利だよね
インスタンス自体は（通常）スタック上に確保されているので、その所有権の移動まではできない
だからこそ「参照」なんだけども

**デフォルトの名無しさん** · 2022/07/08(金) 13:38:22.19

デストラクタを呼ぶ権利だなんてお前も理解してないだろ

**デフォルトの名無しさん** · 2022/07/08(金) 15:16:55.64

>>355
移譲にした方が嬉しい例を示してくれ。
C++なら引数渡ししてもオブジェクトは手元に残るのが常識だから、Rustがわざわざ移譲デフォルトにしているのは違和感しかない。実際、Rust習得の最初の難関が移譲だし。

>>360
本当は「所有権」じゃなくて「管理責任」だからな。スマートポインタとか所有していないリソースの管理とかやらされるし。

**デフォルトの名無しさん** · 2022/07/08(金) 16:27:06.32

>>362
移譲という概念はない
C/C++もRustも同じで＆を付けて＆varnameの形で渡せば参照渡しとなる
同じ形なので全く違和感はない
所有権を手放さないで渡すには参照渡ししかないのだからその場合は＆を付ければよい

もちろんプログラミング言語によって異なる部分もあるのは当然
そんな些細なことを違和感と言うのは極少数の類似言語しか知らないと言ってるようなもの

**デフォルトの名無しさん** · 2022/07/08(金) 16:46:29.18

まあ所有権というよりは「後始末をする義務」だよな
日常的にポイ捨てしてるモラルの低い人間にはピンとこないかもしれない

**デフォルトの名無しさん** · 2022/07/08(金) 17:07:32.78

誰が持ってるかわからんよりは、絶対渡すと決めたほうが安全な気はする

**デフォルトの名無しさん** · 2022/07/08(金) 23:52:34.56

>>362
それは非常にシンプルで突き詰めれば値渡しと参照渡しの2つしかないところを『参照渡し』は結局ポインタを渡せばよくC/C++/Rust揃って「＆変数名」表記
もう一つの『値渡し』のところで少し考えるべきことが出てくる

大きく分けて二つに分かれる
(A) 数値型など値をコピーして渡しても問題なくコストも安い型の場合
(B) ヒープに確保した領域など値をコピーして渡すのはコストも高い型の場合
ここで後者(B)のケースは所有権すなわちメモリ解放責任も関わってくる
Rustでは
(A)タイプの型の場合はコピーして渡す
　　→コピー可能な型は所有権なし
(B)タイプの型の場合はムーブして渡す
　　→所有権(解放責任)が移動する

もし(B)タイプの型で所有権を保持したまま渡したいならば
　(1) 参照渡しをする
　(2) コストがかかってもよいから明示的にコピー(clone)して渡す
の2通りとなる
つまり
　(3) 所有権をムーブする
と合わせて3通りの渡し方が存在する

最初の問題に戻ると
渡し方の表記「＆変数名」と＆を付けない「変数名」の二つある表記法を
(1)(2)(3)の3通りのどれに割り当てるかという問題に帰着する
「(1)参照渡し」はC/C++と同じく「＆変数名」と記述
そして残る＆を付けない「変数名」のみの表記をコストが低い「(3)所有権ムーブ」とした
ちなみにコストが大きくかかる「(2)コピー(clone)」はcloneした時点で別物となり新たな別の所有権(解放責任)が生じているため専用の表記方法は必要ないが強いて式として書けば「変数名.clone()」となる
これはlet x = 変数名.clone(); としておいて「x」とだけ表記して渡すのと同じ
つまり新たに生まれたxをムーブするのと同じになり表記に一貫性がある

以上の理由によりRustでの引数などの渡し方の表記方法は上述のようになっている

**343** · 2022/07/09(土) 00:02:30.53

理解してから質問させてもらったつもりなんですが、まだ全然だったようです
確かに所有権という概念を理解していません
勉強してから出直します
ありがとうございました

**デフォルトの名無しさん** · 2022/07/09(土) 00:12:24.76

void君復帰したん？

**デフォルトの名無しさん** · 2022/07/09(土) 09:11:51.90

はつみみです。

**デフォルトの名無しさん** · 2022/07/09(土) 10:56:35.87

>>367
というより、コードが実際にどういう動作になるかがわかってない感じ(それこそC言語レベルの基本のところ)
もっと書いて実験した方がいいよ

**デフォルトの名無しさん** · 2022/07/09(土) 11:11:15.93

move の挙動を「C言語レベルの基本の」サンプルコードで理解できたら画期的だなあ笑

**デフォルトの名無しさん** · 2022/07/09(土) 11:26:32.90

Cにはそもそもオーバーロードがないからなあ

**デフォルトの名無しさん** · 2022/07/09(土) 12:51:52.12

エアプだろお前ら
>>348辺りから読み直せ
一時オブジェクトの破棄とか裏で何が起こるかの超基本が理解できてないから
あくまで文法上のことに過ぎないmoveと破棄をごっちゃにしてると言ってる

**デフォルトの名無しさん** · 2022/07/09(土) 12:55:08.37

所有権ってデストラクタで破棄する義務を負う、権利とは名ばかりな概念でしょ

**デフォルトの名無しさん** · 2022/07/09(土) 13:07:46.27

昔はリファレンスカウンタでやってたな

**デフォルトの名無しさん** · 2022/07/09(土) 13:45:41.58

自分から破棄しない限りはアクセスできることが保証されるから権利ではあるな

**デフォルトの名無しさん** · 2022/07/09(土) 14:00:45.40

オプーナを買う権利をやろう

**デフォルトの名無しさん** · 2022/07/09(土) 14:07:45.84

エナジーボンボンはCodeVeinに出てくる赤い玉だったんだよ

**デフォルトの名無しさん** · 2022/07/09(土) 16:17:17.24

>>376
他からアクセスできることが保証されなければバグってすべておじゃんなのだから
>>376の権利は有難がっても仕方が無い

**デフォルトの名無しさん** · 2022/07/11(月) 10:49:23.74

>>358
ほんそれ

**デフォルトの名無しさん** · 2022/07/11(月) 10:51:27.98

>>364
ほんそれ++

**デフォルトの名無しさん** · 2022/07/11(月) 21:11:34.35

=std::numeric_limits<decltype(ほんそれ)>::max()

**デフォルトの名無しさん** · 2022/07/16(土) 16:37:55.35

condition_variableってなんでわざわざmutexと一緒に定義しないといけないの面倒でしかたないんだけど。
しかもへんてこな目覚めがあるなんてバグを平然と放置してるし。
win32のSetEvent()のほうが俄然使いやすいんだけど。

**はちみつ餃子** ◆8X2XSCHEME · 2022/07/16(土) 17:49:19.54

mutex は排他の仕組みであって同期の仕組みと分離する思想なんじゃないかなぁ……。
あんまりイケてないとは思うけど。

**デフォルトの名無しさん** · 2022/07/16(土) 19:38:19.38

それはOSの問題なうえ、充分合理的な動作と認められている。

**デフォルトの名無しさん** · 2022/07/16(土) 21:13:53.10

へんてこな目覚めはなんで生じるのかは知らんなんか深い理由でもあるんじゃないのＪＫ
それはおくとして、両者にはキューイングの思想の違いがまずありき、
[1] WindowsのSetEvent()はイベント発生をキューイングし、待機中スレッドをキューイングしない
[2] 条件変数はイベント発生をキューイングせず、待機中スレッドをキューイングする

これでかなりイベント発生と待機の組み合わせの性格の違いが出る。

[1]は待機中スレッドが無くともイベントをセットでき、その後最初に待ちに入ったスレッド1個が待ち解除される
[2]は待機中スレッドが無いとイベントが無視されるが、通知方法をnotify_one()だけでなくnotify_all()も選べる

[1]はWaitForMultipleObject()により1箇所の待機で複数種類のイベントを待ち受けられる（μITRONのイベントフラグ的な使い方ができる
が、[2]でそれをやろうとするとあるイベントでスレッドを起こしたら、そのスレッドの待機中スレッドとしてのキューイングを
他のイベントついてもクリアせねばならない、みたいな余計な処理が必要で効率的に実装できない

ということは、条件変数でWaitForMultipleObject()的なことをやろうとしたら、イベント要因を別途変数にセットして
待機中スレッドに伝える必要があり、この変数の操作→イベント待ち解除→解除されたスレッドが変数を参照、
というのをatomicにやらざるおえないから、ミューテックスのブロック内でイベントの待機とセットを行わねばならない仕様に、
なったと思う

**デフォルトの名無しさん** · 2022/07/16(土) 21:20:57.63

それ隠蔽できるだろうけど、条件変数の基本要素がそれなんだからそういうもんです。

**デフォルトの名無しさん** · 2022/07/16(土) 21:25:01.45

しかしまあ普通にスレッドの中にイベント待ちを作ったら、
イベント要因は
(1) 本来のイベントの意味（複数かもしれん
(2) スレッド終了
の2種類は必ず生じるけどこのために2種類以上のイベントオブジェクトを設けてWaitForMultipleObject()で待機するのは
ｱﾌｫらしいので結局条件変数的に、イベントオブジェクトは1個、イベント要因を表す変数が1個、みたいな形になって
条件変数と同じようなしくみに落ち着く
、希ガス
（ただしイベントオブジェクトとイベントを待つスレッドの実体が完全に1対1ならミューテックスによるガードは不要

**デフォルトの名無しさん** · 2022/07/16(土) 21:52:02.32

mutexないとあっちのスレッドが条件変えちゃうのでは

**デフォルトの名無しさん** · 2022/07/16(土) 22:02:42.26

イベント要因が3種類以上とかイベント発生と待機解除が必ず1対1でなければならない、みたいなケースを含むちょう一般論で言うとそうかorz

**デフォルトの名無しさん** · 2022/07/16(土) 22:31:27.60

>>388
＞イベントオブジェクトは1個、イベント要因を表す変数が1個
その方がめんどくせえわ

**デフォルトの名無しさん** · 2022/07/17(日) 03:07:07.04

>>383
condition_variableの引数にmutexのロックがあるおかげで休眠処理を(1-1)～(1-5)のようにできる
(1-1)mutexでロックして、(1-2)起動条件を設定して、(1-3)起動条件のチェックをしてから、(1-4)休眠して、(1-5)ロックを解除

もしそういう仕組みが無いとこんな感じになるかな
(2-1)mutexでロックして、(2-2)起動条件を設定して、(2-3)ロックを解除して、(2-4)起動条件のチェックをしてから、(2-5)休眠する

休眠を起こす方は、(1)mutexでロックして、(2)起動条件を設定して、(3)起動して、(4)ロックを解除、となるわけだけど、
(2-1)～(2-5)の場合、(2-4)の後(2-5)の前に(1)～(4)が動くことができて、その場合に永遠に休眠する場合がある
(1-1)～(1-5)ならそういう問題が無い

**デフォルトの名無しさん** · 2022/07/17(日) 03:32:35.77

バトン持ってるやつが偉いというのはいいとして、バトンを途切れなく渡すための仕組みが要るんじゃ

**デフォルトの名無しさん** · 2022/07/17(日) 11:47:51.28

>>383
実際まあ面倒くさいよな。
最近は後で書き直すつもりでとりあえずスピンしてatomic_bool待つコード書いてしまってるわ

**デフォルトの名無しさん** · 2022/07/21(木) 12:23:18.60

>>388
>>392

ご回答ありがとうございます。
かなりお詳しい方とお見受けします。

ご回答いただいてから、何回も読み直してしますが
いまいち理解できていない状況です。

そういうものとして、コーディングすれば別に支支障はないのですが、御二方のように完璧に理解したいと勉強しております。

また質問させて頂くかもしれませんが、その際はよろしくお願い申し上げます。

以上

**デフォルトの名無しさん** · 2022/07/26(火) 01:16:01.56

基底クラスのprivateメンバと、private継承された基底クラスのpublicメンバって派生クラスから見たら同じじゃないんでしょうか？
前者は派生クラスからアクセス不可で、後者は派生クラスからアクセス可能なようです
というとこは意味が違うんでしょうが調べでもよく分かりませんでした
どなたか教えてください

**デフォルトの名無しさん** · 2022/07/26(火) 04:47:14.80

public/privateは、自分よりも外側からのアクセスを許可するかの指定。

class B{
private: int b1;
public: int b2;
};
class C: private B{};
int main(){
B b;
C c;
}

b.b2はアクセス可能。c.b2はアクセス不可能。
class C内からは元々publicだったthis->b2のアクセスに制限はない。

**デフォルトの名無しさん** · 2022/07/27(水) 00:07:28.21

Carbon の話はスレチ？

**デフォルトの名無しさん** · 2022/07/27(水) 00:43:24.02

>>397
class Bをprivate継承したことで、b2はclass Cのprivateメンバになるということですね
理解しました、ありがとうございました

**アリ人間** ◆T6xkBnTXz7B0 · 2022/07/27(水) 00:48:37.81

>>398
需要なさそうなC++の派生みたい。
人気が出てきたらスレを分けよう。

**デフォルトの名無しさん** · 2022/07/29(金) 01:50:30.95

通常のキャストと参照へのキャストの違いを教えてください。

#include <iostream>

class Base {};
class Derived : public Base {};

int main()
{
Derived d;
Base& b1 = static_cast<Base&>(d); //①
Base& b2 = static_cast<Base>(d); //②
}

このようなとき、①だとコンパイルOK、②だとコンパイルエラーになります。
どのような違いがあるのでしょうか？

**デフォルトの名無しさん** · 2022/07/29(金) 02:07:00.18

>>401
キャストが原因でコンパイルエラーが出てるわけではないです

簡単に言うと②の右辺は rvalue なので非 const lvalue に束縛できません

**デフォルトの名無しさん** · 2022/07/29(金) 08:15:31.60

>>401
値へのキャストは、一時オブジェクトを作り必要ならコンストラクタを実行する
参照へのキャストは、一時オブジェクトを作らない

ただしconst修飾された参照と右辺値参照の場合はこの限りでない

**はちみつ餃子** ◆8X2XSCHEME · 2022/07/29(金) 10:28:08.30

具体例で言うとこれ↓はアリってこと。

#include <iostream>

class Base {};
class Derived : public Base {};

int main()
{
Derived d;
Base&& b3 = static_cast<Base>(d);
const Base& b4 = static_cast<Base>(d);
}

注意点として、
本来なら一時オブジェクトは式の終わりに解体されるので参照が無効になりそうなもんだが
参照で受けている場合はその参照の寿命と同じ分だけ延命される特例がある。

**デフォルトの名無しさん** · 2022/07/29(金) 10:44:28.57

>>396
違うに決まってるだろ