C++相談室 part165

2023/10/31(火) 07:37:38.52

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
↑同じ内容を3行貼り付けること

次スレは>>980が立てること
無理なら細かく安価指定

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

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2024/02/18(日) 14:01:41.78

私が20代の頃に見かけた論争が今も繰り返されてるのかわいい🩷

2024/02/18(日) 15:55:07.22

>>291
それを思いついたお前のセンスがないと言うことになるが…
俺は確認しろと言っただけだし確認には様々な方法がある

2024/02/18(日) 16:26:47.97

>>291
まさか、何も言わずにいきなり落とす方が良いとか言うわけじゃあるまい。

2024/02/18(日) 17:54:38.27

>>289
もちょカワイイよね

2024/02/18(日) 18:17:37.55

>>280
実生活のあれと似てますよね。「引っ越すことになりました。新住所はXXです」と早めに
連絡したら、気の早い知人がそこに押しかけてきて「なんやまだ引越しとらんやんけ」となる
やはり引越し作業完了を待ってからの方がいいのか。ってちがうか

2024/03/02(土) 23:41:07.84

>>282
>相変わらずずれてるな。 catch する == 原因を調査しない　じゃないわけ
>249に賛同いただけていないということは、発生してもいない例外について予防的にtry { } catch () を入れようとしていることは
確定的に明らか

で、例外というﾌﾞﾂは「例外なく」悪い知らせなので（∵仮に良い知らせを例外で寄越すライブラリがあったらそれ自体悪い知らせである
普通の人は悪い知らせが来る前に処置しようとする。すわなち例外が来ないように（可能な限り）修正する。
try { } catch ( ) でひっかけて原因調査兼確実な修正でざい、それが一番効率が良い方法論である、などと主張するのはおかしい人だけ……

2024/03/02(土) 23:49:37.41

>>284
例外安全というもののスコープに対して考察が足りていない

1.
例外安全なオブジェクト foo のデストラクトが他の例外によって引き起こされるケースでは
foo の安全な終了は（メモリかファイルステムか何かが物理的にぶち壊れてOSがパニックになったとかでない限り
ほぼほぼ保たれるから>>284のような言い方はできるっていやーできるが、
システム全体については>>283の通りであって全然安全ではない

2.
fooの中の例外処理が本当に完璧かはfooのコードに書かれている全てのtry { } catch () について
全ての例外発生条件についてテストか厳格めのコードレビューでも行わないことには安全性が担保されない。
（つまり例外安全にした実装したと主張するだけでは話がただちには簡単にはならない

2024/03/02(土) 23:57:46.67

それはそうとして、予防的なtry{ } catch () の何が一番駄目かというと、設計上のトレードオフをわけわかんなくすることが確実な点

例外発生後の状況というのはたいてい>>283の通りのわけなので、何かを捨てて何かを取る
（例えばシステムは最悪落ちても構わないが、例外安全なオブジェクトfooでリソースAの整合性は死守する等）
のトレードオフが発生するがそういうのこそ慎重な設計と考慮が必要な事項であることは確定的にあきらか
プログラムの全階層にtry { } catch ()入れたら完璧などというｱﾌｫはやっぱtry { } catch () しないのが正しい

2024/03/03(日) 21:57:15.41

>>298
自分が呼び出す関数が例外安全にできているかどうかと自分の処理が例外安全かどうかをごっちゃにしてるだろ。
しかも、呼び出す関数からドキュメント化されていない想定外の例外が発生するなら例外安全に作られていないだろうという
変な決めつけが混じってる。
例外安全なコードは例外の種類に依存しない。知ってる冷害に対しては安全だけど知らない例外が飛んできたら安全じゃない
なんてのはそもそも例外安全とは言わない。

2024/03/03(日) 22:08:48.84

>>300
お前さ、すべてのnoexcept関数呼び出しの例外テスト書いてんのか？
それが出来もしない理想論だって言ってんの

2024/03/03(日) 22:31:19.01

>>301
自分でnoexcept指定した関数のことなら投げないことを確認するテストくらい書けよ当たり前だろ

2024/03/04(月) 00:08:35.31

>お前さ、すべてのnoexcept関数呼び出しの例外テスト書いてんのか？

悪魔の証明をテストすんのか

2024/03/04(月) 07:57:02.63

>>302
100%自分で書いてるコードなら未知の例外なんて起こらんだろ
話の筋理解してからレスつけろや三流

2024/03/04(月) 07:58:21.27

なんか予想外に低ﾚなレスポンスを寄越した>>299……
さすがに>>283の後に>>284のような楽天的なことを言えるだけのことはあるということか……

例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば
その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える
が、例外安全なオブジェクトだけかをもれなく機械的に確認する方法は無い上に、
中断したら別物になる（処理の順序が命）というアルゴリズムというものの本質的特性により、
>>183 のような try { } catch () が必要なケースは隙あらば混ざり込んでくるから（※1）
>>284が空想するようなシステム全体の例外安全化などは現実には不可能。
せいぜいある程度の規模のオブジェクトであれば、十分テストすれば
（自分が呼び出す関数が例外安全にできているかどうかと自分の処理が例外安全かどうかを慎重に確認せねばならない）
ほぼほぼの信頼度で実現できるというぐらい。

2024/03/04(月) 07:59:55.02

（※1） >>183 の関数そのものは、例外安全なスレッドオブジェクトでも使ったらtry { } catch () 無しの例外安全な関数うに書き直すことはできうる

2024/03/04(月) 08:09:49.95

あと寝てて思ったがプロセスが死んでもサービスが継続したらお客様には迷惑を掛けずに済むので
（直接そういうのをやってちるわけではないので強くは言わんが
　ウォッチドッグタイマー的な死活監視で異常あらばプロセス再起動とかマシンを切り替えるとか方法はいくつもあって、
　十分テストされたプログラムならクラッシュ頻度をポアソン分布とみなして信頼度も出せる
やっぱ「お客様の前で落ちたら恥ずかしいから」というつまらないプライドを基本的動機とする
try {
　　....
} catch (std::exception& e) {
　　log_e("std::exceptionがスローされました");
};
みたいなコードをリリースコードに含めましょうという>>282の調査のスタンスは全く正当化されない
100日に一回しか再現しないバグの修正を3日でやれと言われて手元にあるのがメモリダンプの代わりに上の23文字のログメッセージだけだったりしたら
>>282は自○が真剣に考慮すべき選択肢に……

2024/03/04(月) 08:50:22.67

> なんか予想外に低ﾚなレスポンスを寄越した>>299……

299はお前自身じゃないのか、と俺は思う

2024/03/04(月) 08:53:34.53

>例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば
>その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える

例外安全だからといってcatchが不要になるわけないだろ。
根本的なところで勘違いしてるから頓珍漢が主張を続けてるわけだな。

2024/03/04(月) 10:20:12.57

例外安全には基本保証・強い保証・no-fail保証がある
例外がスローされない関数を作ればno-fail保証がある
基本保証や強い保証は例外発生後も不整合が発生しないもの

たとえば例外が発生した関数をもう一度呼び出すと「すでに実行中です」とエラーを返すようなものは例外安全ではない（おそらく実行中フラグ変数が立ったままになっている）

2024/03/04(月) 10:23:14.03

10行のデータをファイルに出力するとき、例外が発生して5行だけデータが出力されてしまうのは強い保証があるとはいえない
例外が発生した際にデータを書き込む前のファイル状態に戻れば強い保証がある（例外安全である）といえる

2024/03/04(月) 12:10:26.04

誤解のないように念のため補足。
この場合の「強い」という用語は性質の分類であって強いことがより良いというわけではないという話をしてる。(んだよね？)
例外を出さずに済むならそれに越したことはないよ。
でも、ひとつの部品の中では問題を解決できないことがあるからこそ例外を用いて他の部品と連携しての解決を試みるわけ。
連携するには保証の強力さよりも保証範囲の明瞭さ (明瞭でもカバーしようがない設計はあかんが) が大事で、プログラム全体で整合性が保たれていれば例外安全と言える。
仕様が不明瞭なライブラリもあるのが現実だってのはそりゃそうだけど、出来が悪い部品とつじつま合わせをしきらないってのは例外のせいでも C++ のせいでもない。

2024/04/08(月) 15:38:53.52

std::initializer_listについて質問です
下の例ですがコンストラクタの引数に配列リテラルを指定した場合、リストがコピーされてしまいますよね？
これは無駄なので回避したいのですが良い方法はありますか？

https://cpprefjp.github.io/reference/initializer_list/initializer_list.html

2024/04/09(火) 12:13:11.96

どこのコピー?

2024/04/09(火) 12:52:21.68

リテラルのコピーを気にするならconstexprじゃねーの？
ほんとにコンパイル時に定数になるかは知らんけど

2024/04/09(火) 15:22:07.81

>>313
C++ に配列リテラルはない。
その書き方で出てくる波括弧はリスト初期化の構文の一部で、
波括弧の部分単体は配列リテラルではない。

実行時にオブジェクトの構築を避けるならコンパイル時に構築することになるが
それはそれで色々と制約があるんでほんまにそれが必要なんか？
というのはよく考えないといけない。

あえてやるならこんな感じかな……。
https://wandbox.org/permlink/HStrLq8ddyC3tby2

2024/04/09(火) 20:10:25.18

とあるtemplateの関数を実装しているのですが、
const指定の振る舞いがよくわからなくなったので
質問させてください。

以下の(だいぶ簡略化した)コードで、
f_without_const<const int*>(const int* a)
はコンパイルが通るのですが
f_with_const<int*>(const int* a)
がコンパイルが通らないのは何故でしょうか。

https://wandbox.org/permlink/OIgKM2DTqvpGduRV

2024/04/09(火) 20:30:45.76

>>316
なるほど
ここまでやるメリットはなさそうなので大人しくデフォルトの書き方にしておきます

2024/04/09(火) 21:45:08.71

>>317
templateは型が違うと全くの別物として処理するからだと思う

2024/04/09(火) 22:00:45.26

>>317
template <class T> void f_with_const (const T t);
これに対応させるなら f_with_const<int*>(int *const a)

2024/04/10(水) 08:39:45.44

const T t に対して const int* a が来たら
字句の順序としては T に int* が対応してるように見えちゃうもんな……。

2024/04/11(木) 21:42:31.84

317です、返信遅くなってすみません
確かに言われてみればconstが修飾してるのはint*なので、意味的にint *constが正しいですね…
ありがとうございました

2024/04/14(日) 14:49:11.63

先月東京で標準化委員会の会議あったらしいけどなんか情報ないの？

2024/04/14(日) 15:03:51.38

あるよ。 https://github.com/cplusplus/papers/issues?q=sort%3Aupdated-desc

2024/04/16(火) 00:50:18.09

>>323
https://www.reddit.com/r/cpp/comments/1bloatw/202403_tokyo_iso_c_committee_trip_report_third/

2024/05/01(水) 21:36:46.68

python みたいに何でも格納できる辞書型ってC++には無いよね？

2024/05/01(水) 22:29:05.62

>>326
要素を std::any にすればだいたいどんな型の値でも入れられる。
いろんな型を入れたところで使うときには元の型として取り出さないといけないから
処理は煩雑になってあまり良いことはないけど。

2024/05/09(木) 20:23:09.67

https://cpprefjp.github.io/lang/cpp23/add_support_for_preprocessing_directives_elifdef_and_elifndef.html
#elifって今まで非標準だったのかよ…

2024/05/09(木) 21:19:14.71

何いってんだ

2024/05/10(金) 11:53:06.45

#elifは大昔からあるぞ

2024/05/11(土) 09:12:25.64

cpprefjpが間違ってるだけ？
それともずっと規格から欠落してたけど誰も気付いてなかったパターン？

2024/05/11(土) 11:19:25.57

規格が読めないならC++やめろ

2024/05/11(土) 19:02:18.20

elifを逆から読んだらfile
ラリーはこれを嫌ってPerlではelsifにした（適当

2024/05/11(土) 22:20:47.67

シェルが変だからな
case ～ esac
if ～ fi

警備員[Lv.23] (ﾜｯﾁｮｲ 1563-WQ8n) · 2024/06/06(木) 07:08:30.09

てｓｔ

警備員[Lv.23] (ﾜｯﾁｮｲ 1563-WQ8n) · 2024/06/06(木) 07:55:41.85

質問なのですが
Q1. std::fstreamでファイルを開くときのフラグの指定の仕方は次のどれが正義？
　std::fstream ofs("foo.txt", std::ios::out | std::ios::binary); // (1)
　std::fstream ofs("foo.txt", std::basic_ios::out | std::basic_ios::binary); // (2)
　std::fstream ofs("foo.txt", std::fstream::out | std::fstream::binary); // (3)

2024/06/06(木) 15:53:22.90

フル手書き前提がくそださい

2024/06/06(木) 19:13:19.37

fstreamなんだったらfstreamのメンバで書くのがいいんじゃない

警備員[Lv.23] (ﾜｯﾁｮｲ 1563-WQ8n) · 2024/06/06(木) 23:36:07.51

(1)は#include <ios>が要るし、
(2)は「basic_」の6文字×フラグの数だけ長いし、
(3)も同様でありなおかつ>>337に従ったとき
　use binary = std::fstream::binary;
　use ibinary = std::ifstream::binary;
　use obinary = std::ofstream::binary;
となってしまい、
どれもこれもコード量最小化原則的にﾋﾞﾐｮｰなことに……

ていうかなんで同じことをするのに複数の書き方があるのかっていうか、
Perlじゃあるまいし……

2024/06/06(木) 23:54:13.70

iostreamはまあしゃーない…

2024/06/07(金) 02:20:24.96

C++の悪評の4割くらいはiostreamのせいだからな

2024/06/07(金) 04:24:11.05

ここでCmakeとNinjaについて聞くのダメ?
どーも関係がよくわからなくて?

2024/06/07(金) 05:26:04.94

>>342
そういう雑多な話題のちょうどよいスレは見当たらんし、単発で終わる質問程度なら許容されると思うが……。
質問の内容が漠然としているなら丁寧な回答は得られないと思う。
「よくわからない」という状況になるときってのは大抵の場合に関連する前提知識が足りてないので
質問が連鎖的に発生してダラダラ続いたりするから。

2024/06/07(金) 05:36:24.41

>>336
第四の選択肢
std::fstream ofs("foo.txt", ofs.out | ofs.binary);

2024/06/07(金) 13:37:29.47

copilotで補完でok

2024/06/07(金) 17:07:58.06

バカの解決策

2024/06/07(金) 21:12:45.28

また時代に取り残されるじじい

2024/06/07(金) 21:48:19.45

>>344
ofsのスコープの隙間を突きなおかつ静的メンバをドット演算子で参照する等
テクニカルですばらっし

2024/06/08(土) 01:03:51.86

静的解析で文句言われる可能性あるからやめときな
頻発するならスニペット作ればいいだけ
そういう表面的なことにこだわる奴は三流

2024/06/09(日) 04:26:59.39

lldb v14.0.0 で正しくプロセスを実行できません
apt insrall でインストールしたもので, 環境はwsl 1 です
具体的には下のサイトのIssue Encountered:と全く同じ症状です
https://stackoverflow.com/questions/78275920/troubleshoot-lldb-on-ubuntu-wsl

改めて書きますと Hello World 表示だけのソースを clang でコンパイルし,
lldb で読み込み run させると

Process 20784 launched: '/home/Hustler/c++/move/move' (x86_64)

と表示されたまま応答がなくなり放置すると(サイトでは強制終了させてるようですが)

Process 20784 exited with status = -1 (0xffffffff) lost connection
となってコマンド入力待ち状態となります

ちなみにプログラムはそのまま実行して正しく動作しますし gdb でも何の問題もありません
これに関して何か情報をお持ちの方いますか?

2024/06/09(日) 05:11:57.08

今やってみたのですが
lldb-14をuninstall(remove)し lldb-15をインストールしてみましたが
状況は改善しませんでした

2024/06/09(日) 15:07:14.43

WSL1 は (ある程度) Linux 互換のシステムコールを windows 内に実装することで実現していて Linux カーネルそのものではないので色々と不足がある。
(そのかわり Windows と親和性がある部分もある。)
WSL1 で用意してない Linux の機能に依存したアプリケーションは動かない。
まともな互換性が必要ならWSL2 を使いなさいという話なので手間をかけて WSL1 を積極的にはサポートしないと思う。

2024/06/09(日) 20:56:05.63

>>352
wsl2 ではlldbは問題なく動いてるんですか?
古いCPUなのでwsl2がインスコできないもんで
上のサイトはwslのバージョンは書いてなかったようですし

2024/06/09(日) 21:14:14.41

WSLはlldbが使うシステムコールが足りてないって昔から言われていたかと

ターゲット機を別にするとかWSL2にするとかじゃね？

2024/06/09(日) 21:36:35.88

>>354
>WSLはlldbが使うシステムコールが足りてないって昔から言われていたかと

なるほどTHXです
clang使ってなかったので全然わかりませんでした
動かないlldbもさんざんggったんだけど system call未実装にはたどり着けませんでした
ようやくすっきりしました

2024/06/09(日) 22:04:05.34

ざっとググってみた感じたと wsl1 では procfs が提供する情報が少ないのが lldb が動かない直接の原因みたいな数年前の情報は見つかる。
内部構造がまるで違うはずなのに表面的なインターフェースは互換にするなんてのは無理のある話なので互換性が「ある程度」にとどまるのは仕方ない。

2024/06/09(日) 22:18:48.29

んー
clangちょっと調べたかったんで
Visual Studioにclangインスコして調べますわ
できるならwslでやるのが手っ取り早いんですが
Q9550とQ9550sしか持ってないもんで
以来CPUの爆値上がりと最近の円の爆下がりで新しく組めてないんですわ
ダイサイズ変わらないのにCPU 3万ー> 10万とか購買意欲が萎える

2024/06/10(月) 18:15:47.68

>>355
github のwslのissueを漁れば出て来るかと。
結論がWSL2使えだったかと

**350** (ﾜｯﾁｮｲ f344-7AaF) · 2024/06/10(月) 21:38:00.71

自己レスです
その後 Visual Studioのインストールオプションでclangを選択し
正しく動作することは確認したのですが...

今や誰でもロハで使えるインテルコンパイラがとっくの昔にllvm化されてたんですね
clangに拘りがなければ x86/x64のwin/linux/wsl は素直にopenAPI使っとくのが幸せかも.
ちなみにwsl 1にlinux版をインストールしましたが
コンパイラicxもデバッガgdb-opwnapiも何の問題もなく動いてます(今のところは)
なので
Visual Studio はインストールオプションのclang は外してもとに戻し
wsl は
>apt remove clang clang-15
>apt remove lldb lldb-15
しときました

**350** (ﾜｯﾁｮｲ f344-7AaF) · 2024/06/11(火) 06:20:17.73

☓ openAPI
◯ oneAPI

**あぼーん** · NG

あぼーん

**あぼーん** · NG

あぼーん

2024/07/13(土) 19:06:26.39

若者のBoost離れ

2024/07/13(土) 19:56:34.01

と言いますと?

2024/07/13(土) 21:42:42.00

VS17.10.xでBoostがビルドできなくなってるのに
誰も触れない

2024/07/13(土) 21:47:29.39

MSVC143から144に変わったせいでビルドできないらしいですよ

2024/07/16(火) 12:22:56.57

>>342
CMakeとNinjaはC++の話題なのでOKです

2024/07/27(土) 17:57:44.53

C++、
型の指定が、めんどい

速いぐらいしか、利点ないよな

2024/07/27(土) 20:53:02.50

顧客目線に立てない三流の感想

2024/07/27(土) 21:03:15.66

>>368
auto使えば?

2024/07/27(土) 23:40:34.69

ランタイムに依存しない(し難い)のが最大の利点だろうに
さらに大抵のアーキテクチャには用意されてるからクロスプラットフォームの観点でもなんだかんだ最強なんだよ
むしろ最近はChatGPTが他の言語で書いたやつまで適当に書き直してくれるのもあって最強度がより高まってきてると感じるね

2024/07/28(日) 00:00:39.51

全く同意できんな
むしろ環境依存上等で使うのがC/C++だろ
パッケージシステムも標準がないしビルド環境もばらばら
どこが最強やねん
標準ライブラリで完結するようなしょぼいプログラムなら他の言語使ったほうが楽

2024/07/28(日) 00:11:55.23

型の指定のサンプル
GetProcAddressに変換をかけるマクロ
#define ENTRY_INTERFACE(api) api = (decltype(api)) GetProcAddress(hInst,"_INTERFACE_"#api)
ね？簡単でしょ？

2024/07/28(日) 12:00:20.72

>>370

auto
オートね
(いいこと聞いた

2024/07/28(日) 17:36:32.24

>>374
あとテンプレートを使ったダックタイプとかも便利。

2024/07/28(日) 21:14:24.07

>>375

ふむ

実践的な(アプリを作るとか)、c++、書籍かなんか、おすすめ、ありますか？

cmake、とかの、関門もあるのだが
(githubにあがってるやつを、きっちり理解したい)

2024/07/29(月) 08:53:31.23

実践に入る前に言語の入門は読んだほうが良いと思う。
基礎を積まずに実践しようとするのは無謀。

2024/07/29(月) 15:25:34.30

なんでも、まずは改造から入るんだぜ

こうですか、うんたぶんこう

2024/07/29(月) 19:25:02.89

C++ には未規定がやたらたくさんあるんだ。
実際の挙動から仕様を想像しようとすると意味不明でグダグダやねん。

2024/07/29(月) 20:07:37.15

ネットでいくらでも勉強できるだろ
書籍なんかいらん

2024/07/29(月) 20:36:26.35

結局ライブラリが重要だから、作りたいアプリで流行っているライブラリの入門をやるのがいい。

作りたいアプリそのものじゃなくても、類似アプリを作るのはやる気に繋がる。

2024/07/29(月) 22:02:41.02

>>377

github にあがってるやつを、理解しようとして、助けになる本は、結局ない希ガス

実際、実践的なものがないので、文法理解で終わってしまうという

https://github.com/TadaoYamaoka/cmajiang

これ、再利用して、アプリを作りたいのだが

2024/07/29(月) 22:18:19.65

>>382
言いたいことがわからん。
auto すら知らんかったということは文法もまだ十分に理解してないってことだろ？
文法が分かったら読めばいいだけなんだから何の本が必要なんだ？

2024/07/29(月) 23:36:56.61

>>382
立直麻雀のシミュレーターなら mjx の方がいいんじゃないかな?
マイクロソフトで麻雀 AI Suphx の開発に携わってた人が作ったシミュレーターで
動作検証も天鳳の牌譜で実施したらしい

https://github.com/mjx-project/mjx

他のシミュレーターだと
- libriichi (Rust製麻雀 AI Mortal に付属天鳳ルール準拠 AGPL)
https://github.com/Equim-chan/Mortal

- kanachan.simulation (C++製麻雀AI kanachan に付属雀魂ルール準拠 MITL)
https://github.com/Cryolite/kanachan/tree/v2

とかも参考になると思う

作りたいアプリの内容がわからないけど

ネット麻雀を作りたいなら cmajiang の元ネタの電脳麻将
https://github.com/kobalab/Majiang
https://kobalab.net/majiang/

AI 用の対戦シミュレーターなら mjai.app
https://github.com/smly/mjai.app
https://mjai.app/

が参考になりそう

2024/07/29(月) 23:43:38.11

>>382
書くのを忘れてた
cmajiang の元ネタ majiang-core は作者が解説本を出してる
実際買ってみたけど、やっぱりソースコードだけ読むより分かりやすい

https://www.shuwasystem.co.jp/book/9784798067889.html

ブログでも解説されてるけど、お目当ての記事を探すのが大変だし本の方が見やすいと思った

https://blog.kobalab.net/

2024/07/30(火) 12:23:26.36

>>379
未規定というか、C++11よりも古い規格のは、古参でないと扱いが難しいからね
そういう古い規格のものが仕事で入ってい来たりすると新人は頭悩ますかもしれんね
03~11まで結構間に空いてるしね

2024/07/30(火) 23:52:38.43

>>385

はい、
すべて、既読です

make,
pybind11

とか入ってて、
デバッグビルド、わかりませんorz

2024/08/04(日) 06:24:46.59

ラムダ式が渡された側って、キャプチャの内容をチェックしたりできないのでしょうか。

例えば以下の例で、funcA()の中でfの中のthisをチェックして挙動を変えたりとか?
そういうことをしたいなら、ラムダの引数で渡したりすべきでしょうか?

#include <iostream>
class A {
public:
　void funcA(const std::function<void(int)>& f, int a) {
　　f(a); // can I check 'this' (B class) in f?
　};
};
class B {
public:
　void print(int b) {
　　A objA;
　　objA.funcA([this](int i) { std::cout << "val = " << i << "\n"; }, b);
　}
};
int main(void) {
　B objB;
　objB.print(2);
}

2024/08/04(日) 10:12:57.69

>>388
キャプチャした変数はラムダ式の中で使う以外の方法ではアクセスできない。
どのような方法で解決すべきかはそれをしようとする意図によるのでなんとも言えない。

2024/08/04(日) 14:50:32.12

それはラムダ式を使う理由とズレてるな
A側で判定が必要なものならラムダ式の引数もしくはfuncAの引数で渡すべき

A側は受け取るものを「intをひとつ受け取ってvoidを出力する関数」として抽象化してるんだから、それ以外のことは知れないし、知るべきではない
Aは渡された関数が何であろうとintを一つ渡すだけで、その詳細 (関数がどのような値や参照をキャプチャしてるのか、渡した引数がどのように使われるのか) には触れられない
ラムダ式を使うのはこのような抽象化が目的のはずだから、キャプチャした値を知りたいというのは用途から外れるかと思う

2024/08/04(日) 18:55:04.35

なんか最近自分でで適切なインターフェースを定義して使うって発想がなくなってる気がする
ひたすらありものを繋ぐだけで作り切るみたいな