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/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

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

2024/08/04(日) 19:21:38.37

仕組みを追求することをせずにどっかから完成した㌬をﾄﾞｯｷﾝｸﾞするだけの作業は情報収集力さえあれば組み込み系の作業員でもできるし己のﾁｶﾗにはならんのよな
で、いろんなもの付け合わせていった結果、とんでもない容量のものが出来上がる上におまえそれﾒﾝﾃとかどうするんだよって方向に走ってって…あとは想像のとおりに

2024/08/04(日) 19:54:18.08

オブジェクト指向オワコン論からの風潮

2024/08/04(日) 21:00:47.00

なんでオワコンなの？

2024/08/06(火) 01:29:43.68

全然関係ないよな
取って貼っ付ける行為とオブジェクト指向は
全体の概要設計を把握してﾒﾝﾃ出来ていれば何の問題もない

**青木康善** (ﾜｯﾁｮｲ 59d4-ANSA) · 2024/08/07(水) 04:36:25.01

素晴らしいなあみなさん。早すぎる！C plus plusは！

2024/08/07(水) 09:54:05.95

JavaはCの20倍速いを知らん人か

2024/08/07(水) 17:07:58.21

>>391-392
チェンジニアをチェンジ
>>395
オブジェクト指向でもクラスライブラリを造る側とただ使う側では理解度に雲泥の差がある

**青木康善** (ﾜｯﾁｮｲ 0bc8-ANSA) · 2024/08/08(木) 00:15:58.93

マジっすか？Cの20倍？しかし、専門学校の先生に、青木！バカもん！プログラミング言語Cが一冊で事足りる、と言われても、高校数学でつまづいて大鬱病になったんで、問題が解けない。。。有隣堂本店さんで、リッチーの本置いているから、いつか買います！

2024/08/08(木) 04:05:43.03

今のANSI対応版は易しくなってると思うけどな。
不安ならアンサーブックとセットで買えば良いベ

2024/08/08(木) 16:07:46.41

VMのオーバーヘッドがあるのに20倍って?
あるいは20倍時間が掛かる?

**青木康善** (ﾜｯﾁｮｲ 31e4-ANSA) · 2024/08/09(金) 13:02:28.92

いや、プログミング言語は、駿台電子は、国語の倒置法なんです。夜間の一年で、javaからで、二年でCなんです。いや、アンサーブックは、池袋ジュンク堂本店さんには、置いてなかったような。。。。。ありがたいというか、ビックリ。。。。マジか。。。機械語を仕事でプログラミングしていた先生が、喫煙所で、青木、お前、一つのことを本当に深く考えたことがあるか？と質問してくれた恩師なんです。

2024/08/10(土) 12:16:45.89

スカイネットの誕生日

**デフォルトの名無しさん** (ｽﾌｯ Sd33-QylA) · 2024/08/10(土) 23:52:09.93

御巣鷹山ノボレ

2024/08/24(土) 08:35:54.88

すみません。教えて下さい。
template<class T, class U>void (T& x, const U& y)
{
x=y;
...
}
double ←complex<double> の代入がコンパイルエラーとなるconceptの書き方あるんでしょうか？
complex<double> ← doubleの代入ではエラーが出てほしくないです。

2024/08/24(土) 09:05:25.59

あ、上では関数名fが抜けてましたね．concept使わずとも
template<class T> void f(complex<T>& x, const T& y)とすればいいでしょうけど、
y=xのときはどうかとか、あるいは complex<double>←float　の代入はokにしたいとか、
いろいろ考えているとテンプレート関数なのに関数のオーバーロードが増えてしまって面倒だなと思ったものですから。

2024/08/24(土) 09:23:02.26

y=xのときは忘れてください。(ｆ(complex<T>& y, const T& ｘ)とすればいいだけ)。どういう状況のためにconceptが必要なのか要点がまとまっていませんね。失礼しました。

2024/08/24(土) 09:53:34.49

conceptで無理やりくくるよりか、static_assertのほうが楽そう
template<class T, class U>void f(T& x, const U& y)
{
static_assert(std::is_same<double,T>::value&&std::is_same<complex<T>,U>::value,"絶対にゆるさない！絶対ﾆﾀﾞ!!");
x=y;
...
}

2024/08/24(土) 11:11:32.60

&& は右辺値参照ではなくてandの意味なんですね。std::is_same<double,T>はdouble型とT型が一致するかどうかを調べるヘルパー変数テンプレート、::value は trueかfalseのいずれかの値をとる定数ですか。static_assertは自分でエラーメッセージを作れるのがいいですね。完全にわかっていないですが、勉強します。ヒントありがとうございました。

2024/08/24(土) 11:44:22.45

最近、初心者にいきなり右辺値参照とかテンプレート教える風潮は良くないと思うんだよなぁ・・・論理andとごっちゃになってるやんけ

ともあれis_same自体は構造体で、中にあるvalueは定数値やで
変数テンプレートはis_same_vの方。利便性(::value書くのがめんどい)のために用意されてるだけ
static_assertの第一引数(bool)に条件式を与えてるんだが、間違ってる

static_assert(!(std::is_same<double,T>::value&&std::is_same<complex<T>,U>::value),"絶対にゆるさない！絶対ﾆﾀﾞ!!");

2024/08/24(土) 12:20:38.61

！抜けてたわ
ｽﾏｿ

2024/08/24(土) 12:40:45.95

// こういう書き方もある
if const_expr ( std::is_same<double,T>::value && std::is_same<complex<T>,U>::value ) {
//許されない処理
static_assert(false,"許さんぞ!!");
}else {
//正常処理
}

2024/08/24(土) 12:43:11.34

また間違えたw
× const_expr
● constexpr

2024/08/24(土) 14:40:14.03

いろいろとありがとうございます。参考になりました。
template<class T, class U> void f(T& x, U& y)
{
if constexpr ( !(std::is_same<T,double>::value &&
std::is_same<U, std::complex<T>>::value) ) static_assert(false,"ワシャ許さんぞ!!");
y=x;
}
template <class T, class U> void g(T& x, U& y)
{
static_assert( (std::is_same<T,double>::value && std::is_same<U, std::complex<T>>::v
alue),"ワシャ許さんぞ!!" );
y=x;
}
int main()
{
using namespace std;
double x=3.14159265358979;
complex<double> z;
f(x,z);
g(z,x); //　順番変えたり、ｘをfloatにするとエラー
cout<<z<<endl;
しかし、コンパイル時にifがつかえるんですねえ。凄いな、constexpr

2024/08/24(土) 15:09:12.28

std::is_same<T,double>::valueの代わりにstd::same_as<T,double>でも良いみたいですね．

2024/08/24(土) 16:42:04.52

#ifdef NDEBUG
　　/*pass*/
#else
class dbg_complex {
　　std::complex<double> m_complex;
public:
　　// std::complex<double> のメソッドのうち使うやつ同じシグネチャのメソッドを書き並べ、m_complexに移譲
　　...
private:
　　dbg_complex(doble);　　// 禁止
};
#define complex dbg_compled
#endif
※ 個人の感想です。

2024/08/24(土) 16:48:40.66

いちいち移譲せねばならないのはstd::complex<T>の継承が禁止されているためorz
実際デストラクタが十中八九virtualではないし、

>>416の最後の
#define complex dbg_complex
みたいな穴だらけの置換手段が嫌ならもうstd::complex<double> を普段からcomplexdbl という別名にすると決めてまう
すると
#ifdef NDEBUG
using complexdbl = std::complex<double>;
#else
using complexdbl = dbg_complex;
#endif
で済む
　

2024/08/24(土) 18:35:31.16

>>412
これかなり新しめのコンパイラじゃないと動かないので注意

2024/08/24(土) 19:16:42.78

行うべき解放処理が無い上ポリモーフィズムも不要なら、別にデストラクタがvirtualである必要は無いぞ
このケースで継承すべきかどうかはまた別として

2024/08/24(土) 23:53:59.32

>>412
constexpr if が使える (= C++17以上) なら std::is_same<T, U>::value よりも std::is_same_v<T, U> を使う方がシンプルだと思う

2024/08/25(日) 00:16:13.89

ま、お好きなの使えいいんじゃないんすか～
こちとら例文示しているだけで極めているﾜｹじゃないからぬ

2024/08/25(日) 01:15:32.96

>>414
テンプレート型引数に require 節などで制約を付けた場合に制約に合致しなければオーバーロード解決候補から除外されるが、 static_assert や if constexpr での判定は解決が終わってテンプレートが実体化されるときに判定される。
つまり、より優先順位の低い候補に当てはめたいかもしれない場合は static_assert や if constexpr での判定をすべきではない。
状況によって使い分けがある。

それと >>418 が注意しているのは、テンプレートはテンプレート引数に依存しない部分は実体化されなくても検証されるルールだから。
(Two phase name lookup について調べてみて。)
つまり static_assert(false, ほにゃらら) と書いてあったらそのテンプレートが使われるかどうかに関係なく問答無用でエラーとして報告されていた。
新しい仕様では static_assert は実体化のときまで検証しないように挙動が改められたのだが、これは欠陥報告の形で問題提起されて過去の仕様に遡って修正されるので C++11 からこの仕様だったことになった。
新しいコンパイラでは C++11 を指定したときでも新しい挙動になる。

2024/08/25(日) 01:34:45.73

まあ、そんな小難しいこと言われても。C++が嫌われる理由だわ

2024/08/25(日) 02:05:31.18

実体化ってどっちみちコンパイルするときにエラー発生するんだから結果かわらねぇだろﾊﾞｶがよう

2024/08/25(日) 06:41:14.01

static_assert(false, "")は何かしらダミーの値入れて回避してたけど修正されてたんだ、知らんかった

2024/08/26(月) 00:27:52.82

false効かないﾊﾞｶｺﾝﾊﾟｲﾗはどうしようもないからどうにもならんか
//requires を使った方法
template<class T, class U>
requires(!(std::is_same_v<double,T>&&std::is_same_v<complex<T>,U>))
void f(T& x, const U& y)
{
x=y;
...
}

2024/08/27(火) 07:16:06.25

特定の引数型についてテンプレート展開を阻止したいんなら
特殊化してその中にstatic_assert(false, "*** ERR ***")書いても昔は駄目だったんか恐ろしい……

2024/08/27(火) 07:35:09.57

しかしまあ特殊化してテンプレート引数の型Tについて
態と存在しないメソッドを呼ぶように書いたらその特殊化ケースについて展開を阻止できうる（適当
クラス内でint型定数が欲しかったら古き良き enum { ONE, TWO, THREE } で十分やし
同じことをやる手段を増やせば良いってもんじゃないぞPerlじゃあるまいし……

2024/08/27(火) 14:55:30.59

perlの面白仕様

2024/08/27(火) 17:14:33.06

まぁ普通にSFINAEなり=delete指定なりコンセプトなりでオーバーロード候補から外す方が利用者視点でいえば自然だな

2024/08/27(火) 17:33:30.75

#include <iostream>
#include <complex>

template <class T> decltype(auto) f(T x)
{
decltype(abs(std::declval<T>())) w;
w=abs(x);
return w;
}

int main()
{
using namespace std;

cout<<f(-1) << endl;
cout<<f(2.f)<< endl;

complex<double> z=complex<double>(1.0,1.0);
cout<<f(z)<<endl;

cin.get();
return 0;
}
いちかばちかでやったら、通りました。abs！ Who are you？ sizeof演算子と同じくコンパイル時に評価されるんですか？というか、地味だけど declval が凄い。

2024/08/27(火) 18:27:19.33

>>431
sizeof や decltype のオペランドは評価されないということになってる。
だからその文脈で関数を使う場合でもその関数が定義されている必要はない。 (宣言だけあればよい。)
評価されないけど実体化は起こるのでそのへんの理屈は複雑でよくわからん。

ころころ (ﾜｯﾁｮｲ 0202-3rb6) · 2024/08/30(金) 02:40:03.60

decval使ったコード始めてみたかも

2024/08/30(金) 05:15:18.21

相互参照わっかんねぇ

2024/09/02(月) 12:36:59.33

相互参照は必要ない
最近はウェブプログラマのほうが賢くなった
すそ野が広がると質が良くなるらしい

2024/09/02(月) 13:00:06.45

必要ない理由ぐらい言ったら？