C++相談室 part156

**デフォルトの名無しさん** · 2021/05/19(水) 10:55:13.24

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

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/14(月) 17:34:14.74

前後の命令の依存関係によっては多少高コストの演算でもパイプラインに隠れて全体としては
それほど時間がかからないということも有りうる。
命令ひとつの実行コストだけでは評価できないから結局のところやってみてから計測するのが
手っ取り早いって話になる。

**デフォルトの名無しさん** · 2021/06/14(月) 18:10:27.40

>>312
現代の普通のコンパイラであれば当然最適化が行われる

コンパイル時に決定可能な部分はコンパイル時に決定するし、
ループ内で変化がない部分はループの外で計算する
のが普通

a[i][j][k] で一番ループの内側がkであれば
a[i][j]まではループの外で行うし
a[1][2][k] のような固定値であればa[1][2]まではコンパイル時に計算する

メモリアクセス順は非常にパフォーマンス的には重要で
a[i][j][k] を3重ループでアクセスする場合
ループの外側からi,j,kとするべき

言語上のいわゆる配列は最適化されやすいので普通は気にしなくていいが、
vectorやMatなど、外部定義の [] は基本的には遅いと思っていい

コストが小さいとはいっても確実にコストは発生する
速度が非常に重要な場合では
SIMD化、キャッシュ化、ループアンロールなどで最適化すべき
その場合も、データ構造、アクセス順、アルゴリズムなど上位層の最適化が終わってから

**デフォルトの名無しさん** · 2021/06/14(月) 22:36:37.28

vectorの[]だって配列へのアクセスしかしてないけどな。
インライン展開されるし範囲チェックもしてない

**デフォルトの名無しさん** · 2021/06/14(月) 23:49:54.30

素人質問ですみません
クラスのメンバ関数は常に外で実装しますか？それとも、短いものはクラス宣言内に書きますか？
混在させて良いものかと迷っています(クラス宣言内に書くとinline指定になる事は知っています

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/15(火) 00:02:19.94

>>341
どっちでもいいようになっているんだからどっちにするかは個別の判断による。
具体的条件を示してくれたらどちらが好ましいかの意見は言えるよ。

**デフォルトの名無しさん** · 2021/06/15(火) 05:05:22.97

template<class T, size_t N> using myarray = std::array<T, 2*N>;
としたときに、関数 hoge を
template<class T, size_t N> void hoge(myarray<T, N>);
と
template<class T, size_t N> void hoge(array<T, N>);
でオーバーロードすることってできますか？

**デフォルトの名無しさん** · 2021/06/15(火) 05:32:07.52

>>338
高コストという文言の意味がよくわからんが
レイテンシが大きい命令はパイプラインを乱すぞ

**デフォルトの名無しさん** · 2021/06/15(火) 05:35:15.36

>>343
２番目のオーバーロード関数はarrayにstd::を付け忘れてるのか？
だとすると無理だと思うな

std::array<int, 1> a;
hoge(a);
と呼び出したとき、N==2となるべきかN==1となるべきかの根拠がないから

やってみてないけど
つーか、おまえさんはやってみたのか？

**デフォルトの名無しさん** · 2021/06/15(火) 05:40:17.26

>>345
> ２番目のオーバーロード関数はarrayにstd::を付け忘れてるのか？
すみません。そうです

まだ試してないです
無理そうだなって思うんですが、昔「オーバーロード関数は機械にとってはそれぞれ別名関数だ」って話を聞いて、じゃあもしかしたら行けるかもと思った次第です

**デフォルトの名無しさん** · 2021/06/15(火) 07:12:05.86

すぐ試せることを自分で試さずに5chで聞くの良くないよ

**デフォルトの名無しさん** · 2021/06/15(火) 07:54:52.19

>>341
templateのクラス書いてると、長くても中に入れちゃうから、でかいのバーンって
そのままヘッダに入れても抵抗はないけど、templateでない場合でかい関数は普通に外に書くな。

**デフォルトの名無しさん** · 2021/06/15(火) 08:01:18.68

>>341
外

templateやstaticのように実装をヘッダファイルに書く場合も
ヘッダファイルの中でプロトタイプと実装に分ける
さらに実装は別ファイルにしてヘッダファイル内で#includeする

宣言だけからなるアウトラインを残したいから

**デフォルトの名無しさん** · 2021/06/15(火) 08:19:37.29

>>343,345-347
試して無理でした
言い方合ってるかわかりませんが、>>343のやり方ではオーバーロードと関数テンプレートの差がないからでしょうか

コンパイラに myarray を array と別の型だと思ってもらって、hoge をオーバーロードするテクってありますでしょうか

**デフォルトの名無しさん** · 2021/06/15(火) 09:04:05.70

>>350
継承でいけるんじゃね

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/15(火) 09:47:07.09

>>350
using で作った別名と元の型を区別する方法があるかという意味でなら方法は無い。
using は「別名」を作っているだけであくまでも同じ存在。

オーバーロードできるように型を分ける方法があるかという意味でなら >>351 が提案しているように継承を使うのが簡単な方法。
template<class T, std::size_t N> class myarray : public std::array<T, 2*N> {};
みたいに書いて継承しつつ特になにも付け加えなければ事実上の別名でありつつ異なる型でもある。

**デフォルトの名無しさん** · 2021/06/15(火) 10:24:24.93

template<class T, std::size_t N> class myarray : public std::array<T, 2*N> { using std::array::aray; };
コンストラクタも継承しとかないと使いにくくて困るぞ

**デフォルトの名無しさん** · 2021/06/15(火) 10:25:47.44

std::array<T, 2*N>::arrayか
この件のみ動作確認しないポリシーなんでやりづれえ

**デフォルトの名無しさん** · 2021/06/15(火) 15:04:54.99

>>349
迷惑なやつだな

**デフォルトの名無しさん** · 2021/06/15(火) 15:40:54.02

>>351,353-354
なるほど
ありがとうございます

> この件のみ動作確認しないポリシー
てどういういみでしたっけ？

**デフォルトの名無しさん** · 2021/06/15(火) 15:43:28.83

コンストラクタさえ継承しとけば、元のクラスとほぼ同じ使用感で使えるんですかね？
試しきれないので未知の困難に直面しそうで結構不安です

**デフォルトの名無しさん** · 2021/06/15(火) 15:44:46.76

>>355
何が？

**デフォルトの名無しさん** · 2021/06/15(火) 16:21:53.57

>>356
多分、自分で確認もせず書き込むようなやつには同じく動作確認なんかしてやらねーよ、ってことだろ

**デフォルトの名無しさん** · 2021/06/15(火) 18:25:24.86

どうでもいいけど変数テンプレートの四則演算って推論の邪魔するような

**デフォルトの名無しさん** · 2021/06/15(火) 20:42:15.88

>さらに実装は別ファイルにしてヘッダファイル内で#includeする
これはやりすぎだろ
#include先に何書いてるかわからんから結局読まなきゃならん
空行とコメントで上下に分ける方がマシ

**デフォルトの名無しさん** · 2021/06/15(火) 21:00:10.82

それは非テンプレートなクラスでも一緒だと思うけど

**デフォルトの名無しさん** · 2021/06/16(水) 06:00:46.73

>>361
その論法はヘッダファイルそのものを否定する考えだな

**361** · 2021/06/16(水) 21:17:19.71

結局読まなきゃならないのは一緒だよ、当たり前
それでも、何か所にも同じのを書くのが嫌だから#includeなんじゃないの？
俺は一か所からのみ#includeするのを否定してる

**デフォルトの名無しさん** · 2021/06/17(木) 05:36:20.94

何か所にも同じのを書くのが嫌なら
テンプレートでない関数をプロトタイプと実装に分けただけで難癖つけるのか？

**デフォルトの名無しさん** · 2021/06/17(木) 10:01:25.56

まぁヘッダのインクルードの仕方はそれぞれだからなぁ
自作ヘッダ内では一切インクルードしない(それの前に必要なヘッダをすでにインクルードしてる前提)ってのもある

ただその戦略なら、テンプレートがインスタンス化される直前にその実装が書かれたやつインクルードすればいいだけなんだが

**デフォルトの名無しさん** · 2021/06/17(木) 10:28:32.50

多分同じ奴だと思うが、数スレ前から多次元配列を自力でどうこうしようとしてる奴、悪いこと言わんから外部ライブラリ使うとけ
今の時代、行列とかテンソルの計算は並の人間が書いた C/C++ じゃ絶対に Python (NumPy) その他に敵わんと思う

まあ C/C++ の多次元配列ライブラリも群雄割拠で何が何だか全く分からないんだが
STL に多次元配列が中々入らない理由もこれかな

**デフォルトの名無しさん** · 2021/06/17(木) 10:29:56.26

つーか入ったところで大したもんにはなり得ないか
行列の分解とか掛け算を STL が担うのはあり得んしな

**デフォルトの名無しさん** · 2021/06/17(木) 10:31:47.16

>>365
難癖もクソも普通にC/C++の欠点でしょ
フロッピーディスクの時代の遺物よ

**デフォルトの名無しさん** · 2021/06/17(木) 10:34:24.84

>>369
別におまえさんにC/C++を使ってくれなんて頼んでない
嫌いなら出てってもらって構わない

**デフォルトの名無しさん** · 2021/06/17(木) 10:36:52.42

>>370
誰が嫌いなんて言った？
欠点を差し引いてもメリットがあるから使ってるんだし、欠点は欠点として認めないと進歩しないよ

**デフォルトの名無しさん** · 2021/06/17(木) 10:48:03.95

質問です
#define A L"xyz"
#define B L"www"
を結合するとき
#define C AB
じゃだめなんですか？
#define D A(B)
ですか？
それとも
#define E A"www"
ですか？

**デフォルトの名無しさん** · 2021/06/17(木) 10:51:16.93

#define C A B
じゃね

**デフォルトの名無しさん** · 2021/06/17(木) 10:52:13.35

>>371
欠点は欠点として認めるって具体的にどうしてるんだ？
プロトタイプを一切しない、のような公害か？

**デフォルトの名無しさん** · 2021/06/17(木) 11:09:25.36

>>374
いや昔の貧弱な環境でもビルドできるように、って制約が無きゃもうちょっと違う形だったんじゃないの
今みたいにヘッダが肥大化しがちで各ソースごとに同じ解析しなきゃならないのは不自然ではある
IDEやコンパイラが賢いおかげでそこまでビルド時間酷くはならんようだけど

>>367
行列とかに関しては特に、C++のみで限界までチューニングしたってSIMD使ったコードにはまず勝てない(さらに言えばGPGPU使った方が、大きい行列ではもっと速い
それらを汎用化して使いやすくするのは可能だろうけど、そんなハード依存が激しいものを標準に入れるのか、それともハード依存は無いがめっちゃ半端なものを作るかの二択になるからでしょ

**デフォルトの名無しさん** · 2021/06/17(木) 11:16:45.59

>>372
#define C A##B

**デフォルトの名無しさん** · 2021/06/17(木) 11:31:03.61

>>375
具体的にどうしてるんだ？　と聞いてるんだが
答えたくないならいいよ

**デフォルトの名無しさん** · 2021/06/17(木) 11:38:23.32

IDも知らんのかこいつは

**デフォルトの名無しさん** · 2021/06/17(木) 11:48:01.35

日本語でおｋ

**デフォルトの名無しさん** · 2021/06/17(木) 12:15:01.57

>>375
はい
そう申しております

**デフォルトの名無しさん** · 2021/06/17(木) 12:21:37.22

>>379
375「俺は371じゃないから質問に答えろと言われても知らない」

**デフォルトの名無しさん** · 2021/06/17(木) 12:33:13.95

横レスにしても頓珍漢すぎるだろ
今、横レスとして読み直したが俺にアンカー振られている意味がわからない

**デフォルトの名無しさん** · 2021/06/17(木) 12:36:53.30

>>369に噛み付いてるんだから欠点じゃないと言いたいんだろ？
頓珍漢はお前だ(>>374でも相当おかしな事言ってるが

>>380
すまん直後の書き込み読んでなかった

**デフォルトの名無しさん** · 2021/06/17(木) 12:43:39.21

>>383
また例のオウム返し野郎か
何がおかしいのか説明できないやつがハッタリかますんじゃねえ

**361** · 2021/06/17(木) 20:43:21.47

>>365
俺の>361,364の一体どこをどう読めばそんな解釈ができるのか教えてくれよ
俺が否定してるのはこれ↓
>さらに実装は別ファイルにしてヘッダファイル内で#includeする
これは全然「テンプレートでない関数をプロトタイプと実装に分けただけ」じゃないよ
（藁人形論法ってやつか？これ）

**デフォルトの名無しさん** · 2021/06/18(金) 00:22:44.11

ポインタはchar * const p = q; とでも書かないとpがconstにならないが
char& c = *q; と書いたらそんなリスクを回避できる
革命的前進

**デフォルトの名無しさん** · 2021/06/18(金) 00:25:25.92

>>376
ﾊｱ？
#define C(A, B) A##B
にしないと駄目なんじゃ……

もっともK&Rの頃のCなら
#define C A/**/B
と書くことはできたっぽい

**デフォルトの名無しさん** · 2021/06/18(金) 08:34:36.86

>>372のAとBを連結するなら>>373でいいだろ。括弧でくくった方がいいかもしれんが。
##は用途が違う。

**デフォルトの名無しさん** · 2021/06/18(金) 09:49:26.06

実装も書いてあるヘッダファイルって src に置くの？ include に置くの？

**デフォルトの名無しさん** · 2021/06/18(金) 09:57:10.61

boost のライブラリって、一度入ったら時代遅れになっても取り除かれないんですか？
それとも boost の全貌を把握してる委員会みたいのがあって、ちゃんと選別みたいなことをしてるんですか？

今どきムーブセマンティックに対応してないデカいコンテナクラスを見つけて、そういう疑問を持ちました

**デフォルトの名無しさん** · 2021/06/18(金) 10:08:12.10

>>385
俺は
> 何か所にも同じのを書くのが嫌なら
> テンプレートでない関数をプロトタイプと実装に分けただけで難癖つけるのか？
と言ったんだ

二行目だけ切り取ってきて人のこと藁人形とは藁わせてくれるやつだな

**デフォルトの名無しさん** · 2021/06/18(金) 10:17:41.61

>>385
純粋に気になるんだけど、例えば俺が>>366で書いたようにテンプレートの実体化が起きる前に関数、メンバ関数の実装を分けてインクルードすることは出来るけど
実体化が起きる翻訳単位では必ず実装が必要になるよね？(テンプレートの分離コンパイルは出来ないという問題から)

クラステンプレートのポインタや参照しか使わない翻訳単位では、例えばiosfwdみたいに前方宣言しか書いてないヘッダを使うことで、ビルド時間減らせるかもしれんけど

そういう意味ではクラステンプレートの定義書いてるヘッダで、メンバ関数の実装を書いたヘッダをインクルードするのは別におかしくはないと思うんだが

**デフォルトの名無しさん** · 2021/06/18(金) 12:27:14.41

>>389
src に .hpp が置いてあるプロジェクト観たことあるけど
かっこ悪いと思った

**デフォルトの名無しさん** · 2021/06/18(金) 12:47:25.93

include に置いてあるファイルに実装めっちゃ書いてあってももちろん嫌じゃないですか？

**デフォルトの名無しさん** · 2021/06/18(金) 12:54:04.57

いやも何も、テンプレートは明示的実体化して使えるテンプレートパラメータを制限でもしない限り、ヘッダに実装するしかないんだよ
可読性の問題を気にしてるなら拡張子変えればいい
ヘッダだからって.hや.hppじゃなきゃいけないなんて決まりは無いしinclude(フォルダかグループか知らんけど)直下に置かなきゃいかんわけでもない
そのくらい自分で工夫しろ

**デフォルトの名無しさん** · 2021/06/18(金) 13:18:46.12

.obj で分割するメリットって .exe が巨大化しないためってのもあるけど
テンプレ使うと各 .obj 全部に同じバイナリーが増殖しない？

**デフォルトの名無しさん** · 2021/06/18(金) 13:51:38.82

多分だけど、今時の環境だと一度他の翻訳単位で実体化されたものは再利用するんじゃなかったかな

**デフォルトの名無しさん** · 2021/06/18(金) 14:28:08.43

リンク前に判るの？
リンク時に同じ名前で同じ引数ならまとめるの？
怖くない？

**デフォルトの名無しさん** · 2021/06/18(金) 14:31:16.93

lexical phase 9だな

**デフォルトの名無しさん** · 2021/06/18(金) 20:05:16.88

>>391
論旨変わってないだろ、何が切り取りだか
で、お前のその変な疑問がどこから出たのか聞いてるんだけど

>>392
「そういう意味」がどういう意味なのかよくわからない
.hに宣言しか書いてないからコンパイル時間が減るんであって、
.hで定義をincludeしたら減らないよ？

**デフォルトの名無しさん** · 2021/06/18(金) 20:29:54.81

>>400
テンプレートの話やろ？
翻訳単位のどこかに定義(実装)が必ず要るんだぞ
あるソース(翻訳単位)においては不完全型でいいんなら、そこで使うヘッダは前方宣言だけでいい(クラス定義は要らん)って書いたじゃん
クラス定義が要るんならそれは実体化を伴うんだからメンバ関数の実装ヘッダに書いてなきゃリンカエラー出るぞ

**デフォルトの名無しさん** · 2021/06/19(土) 06:14:13.07

>>400
だから１行目を読め
読みたくないなら逃げるのはおまえさんの勝手だが
逃げた事実は消えないぞ

**デフォルトの名無しさん** · 2021/06/19(土) 06:30:02.69

>>390
だめなboostライブラリというのは、そりゃ山ほどある
メンテナという概念は一応あろうが

**デフォルトの名無しさん** · 2021/06/19(土) 07:50:07.39

>>398
YES実際恐ろしい
"a.cpp"に
class Foo { void some_method() const { return 3.0; } };

"b.cpp"に
class Foo { void some_method() const { return 4.5; } };
int main() { Foo x; printf("%f\n", x.some_method()); }

とか書いてリンクして実行したら3.0と表示されることがある
ビルド中に警告とかは無し（於VC++ 2010

というわけでクラス定義は極力ヘッダファイルに書くのが正しいい
二つのFooクラスの定義を同時にincludeしたら確実にビルドエラーになってﾜｶﾙ

どうしても.cppファイル側にクラスの定義を書くときは無名namespaceで囲うべきや
（名前付きnamespaceは名前の重複についてクラス定義ほど検査が厳しくないのであまり解決策にならない

**デフォルトの名無しさん** · 2021/06/19(土) 08:09:04.24

今ｼﾞｯｹｿしたがVC++ 2019でも同じだぬ、
"a.cpp"
#include <stdio.h>
class Foo { public: double some_method() const { return 3.0; } };
double get_Foo() { Foo y; return y.some_method(); }

"b.cpp"
#include <stdio.h>
extern double get_Foo();
class Foo { public: double some_method() const { return 4.5; } };
int main() { printf("%f\n", get_Foo()); Foo x; printf("%f\n", x.some_method()); }

実行結果:
3.000000
3.000000

4.5どこ行った；；；

**デフォルトの名無しさん** · 2021/06/19(土) 08:55:28.76

初歩的なことかもしれませんが質問させてください。
以下の3ファイルがあるとして、src.cpp をコンパイルしようとすると失敗します。
hoge の myclass に対する特殊化を file2.hpp でしてるだけだから OK だと思ったのですが、無理でした。
一方で、file1.hpp の中身を file2.hpp の下の方にコピペしたらコンパイルできます。
この、hoge の特殊化を file2.hpp でしてるという考え方はどう間違ってるのでしょうか。

// file1.hpp
template<class T> void hoge(T);
template<class T> void fuga(T x){
　hoge(x);
}

// file2.hpp
#include"file1.hpp"
#include"myclass.hpp"
template<class T, int N> void hoge(myclass<T, N> x){
　...
}

// src.cpp
#include"file2.hpp"
int main(){
　myclass<int, 10> x;
　fuga(x);
}

**デフォルトの名無しさん** · 2021/06/19(土) 09:03:50.50

>>406
無理でしたとは？コンパイルエラー？エラーメッセージは？

**デフォルトの名無しさん** · 2021/06/19(土) 11:19:08.00

それ多分特殊化じゃなくてオーバーロード？(違ってたらすまん
hogeの<T>を受け取る奴で実体化した後にmyclass受け取る奴が出てくることになる

myclass版の前方宣言をfile1.hpp(fugaより前)に書くか、fugaの実装をfile2.hppのインクルードより後にすればいける、と思う

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/19(土) 14:35:39.56

>>406
それは >>408 が指摘する通りオーバーロードになってる。
オーバーロードの解決方法は複雑なんで私もちょっと自信はないんだけど、
オーバーロードの候補の内で実引数の型と完全に同一 (または実引数の型に cv 修飾したもの) のものがあれば、
それの優先度はテンプレート引数のマッチより高いので曖昧さは生じずに解決できるのが正しい。

そんで >>408 がいう

> hogeの<T>を受け取る奴で実体化した後にmyclass受け取る奴が出てくることになる

というのはたぶん関係ないと思う。
Two phase name lookup のルールが適用されるはずだから fuga 内での hoge の呼出しは
その時点では解決を試みられず、 main 内での fuga の呼出しが有った時に
fuga の実体化が起こってそのときに hoge も実体化されるので
宣言の順序にかかわらずどちらの hoge も候補になるはず。

なので include がどうこうというのとは関係なく
file2.hpp のほうの hoge が問題なく呼び出されるべきで、 >>406 に間違いはないと思う。

手元に入れてないから動作確認できないんだけど古い MSVC は Two phase lookup の実装が
おかしかったとか聞くからそのへんで何か問題が起こってるんじゃないか？
GCC や Clang だとかなり古いバージョンでも特に問題なくコンパイルできてる。

**デフォルトの名無しさん** · 2021/06/19(土) 15:55:55.01

>>405
リンクする順番変えたら 4.5 になったり 3.0 になったりするかもしれないししないかもしれない

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/19(土) 16:47:38.21

>>396
古典的なツールチェインでは同一のものがそれぞれの翻訳単位に作られる。
その上でリンク時に同じものは同じに統合される。

それが嫌だという場合にはテンプレートには明示的実体化という仕組みがあって、
暗黙的な実体化を抑制する仕組み (extern template) とセットで使うことで
テンプレートの実体をひとつの翻訳単位にまとめることは出来る。

当然だが個別に指定するのはめんどいし、
いまどきの処理系は賢いので、あまり使われてないと思う。

**デフォルトの名無しさん** · 2021/06/19(土) 18:01:09.17

>>406,>>408
うろ覚えだったのでスマンコ
というか自分がその手の順序依存を経験したのはVC2008-2015あたりまでだった気がする
最近のだとC++標準への準拠の設定(コンパイルオプション/Zc:twoPhaseとか)も影響するはず

**デフォルトの名無しさん** · 2021/06/19(土) 18:07:00.49

間違えた、>>406,>>409
2017あたりまで標準への準拠のオプション(名前不明)は指定しないと有効にならなかった気がする、2019では既定

**デフォルトの名無しさん** · 2021/06/19(土) 18:48:12.63

/permissive-
やった(VS2017
2015以前なら>>408のような対策するしかないと思う

**デフォルトの名無しさん** · 2021/06/20(日) 04:37:05.08

>>407
失礼しました
短縮して書くと
undefined reference to 'void hoge<myclass<int, 10>>(myclass<int, 10>)'
というメッセージが出ます

コンパイラは g++ 11.1.0 です

用語の使い方が正しいか自信がありませんが、
file1.hpp 内で hoge の宣言と hoge を呼ぶためのユーティリティ関数 fuga の実装をしておいて、後から必要に応じて具体的な型について hoge の実装を書ける、という方がすわりが良いのですが、こういう考え方は間違っていますか
fuga は型によらず hoge を呼ぶための関数なのでその実装を後に回したくない、という思いもあります

**デフォルトの名無しさん** · 2021/06/20(日) 07:43:07.12

C言語の double _Complex と C++ の std::complex<double> って実部虚部の並び方とか一緒ですよね？
ヘッダファイル aaa.h で宣言されてる double _Complex * をとる関数に std::complex<double> * を渡したいのですが、やり方がわかりません。

#define 〇〇 std::complex<double>
#include<aaa.h>
みたいにできると想像してるのですが、合っているでしょうか？

**デフォルトの名無しさん** · 2021/06/20(日) 08:46:26.25

>>416
_Complexはただのdouble型変数なのでstd::complex<double>と互換性なし

**デフォルトの名無しさん** · 2021/06/20(日) 08:59:29.33

>>417
メモリレイアウトから違うのですか？
では、double _Complex * をとる関数に std::complex<double> * を渡すことはできないということですか？

**デフォルトの名無しさん** · 2021/06/20(日) 09:04:23.23

はい

**デフォルトの名無しさん** · 2021/06/20(日) 09:11:24.89

エ！？
_Complex って std::complex の後にできたんじゃありませんでしたか
なぜ、実部と虚部がメモリ上に連続で置かれているという設計にしなかったのでしょうか……

**デフォルトの名無しさん** · 2021/06/20(日) 09:29:15.86

作りが似ている、ということと
互換性が保証されている、ということは同じじゃないぞ

保証があるか否かは規格票で確認することで主観が入る余地はない
俺が見た範囲では保証するとは書いてなかった

**デフォルトの名無しさん** · 2021/06/20(日) 09:29:35.37

_Comolex変数の実部と虚部をそれぞれcreal(), cimag()で取得してstd::complex<double>変数にセットするしかない

**デフォルトの名無しさん** · 2021/06/20(日) 09:35:42.79

_ComplexがC99でstd::complex<T>がC++03

**デフォルトの名無しさん** · 2021/06/20(日) 09:53:39.49

>>415
>>406に嘘書いてないか？

**デフォルトの名無しさん** · 2021/06/20(日) 10:06:25.46

std::complex<double> *hoge;
double _Complex *p = (double _Complex *)&hoge[0];

**デフォルトの名無しさん** · 2021/06/20(日) 10:06:45.88

>>424
すみません
どこか矛盾しますでしょうか
手元でコンパイルしてみて、そうなりました

**デフォルトの名無しさん** · 2021/06/20(日) 10:22:51.51

>>408は試してみた？

**デフォルトの名無しさん** · 2021/06/20(日) 10:33:37.36

>>427
はい
>>408様の仰る「fuga の実装を後に書く」というのが、>>406に書いた「下の方にコピペしたら」というのです
そして、それらのことを踏まえて、>>415に書いたような疑問を持ちました

ところで嘘というのはどういうものでしょうか
なにか矛盾しますでしょうか

**デフォルトの名無しさん** · 2021/06/20(日) 11:18:41.97

hogeの実装(関数の中身)を実際は書いてなかったとか、何か事実と違うことがあるんじゃないかと思った
だけ

>>415に書いてある理由なら、同じコンパイラであればどこか妥協するしかない気が
fugaの前方宣言だけはfile1に残して、実装を別のヘッダにして後からインクルードするとかは？(>>408で言ったのはそういうことなんだけど

**デフォルトの名無しさん** · 2021/06/20(日) 14:29:11.44

>>421-422
今調べたら、C側は実部虚部というメモリレイアウトを保証していて、std::complex 側は C の複素数と同じメモリレイアウトを保証してるようですね

>>423
すみませんCの方が早かったんですね

>>425
ありがとうございます
暗黙のキャストがなぜ許されないのかはまだよく分かっていませんが、キャスト自体は可能なようで、double _Complex (あるいはそのポインタ) をとる C 言語関数に std::complex<double> (あるいはそのポインタ) を適切にキャストして渡すのは問題ないようになってると理解しました

**デフォルトの名無しさん** · 2021/06/20(日) 15:33:53.67

>>430
その件について
ISO/IEC 9899でC++という文言に言及するか
ISO/IEC 14882でCという文言に言及しているか？
430に書かれている限りでは「似ている」だけだが

それからC++03は2003年にC++98のバグ修正をしただけだから
C99より古いぞ

**デフォルトの名無しさん** · 2021/06/20(日) 15:42:44.16

良スレ気体age

**デフォルトの名無しさん** · 2021/06/20(日) 16:06:01.76

>>431
いや、すみません。逆に「似ている」とはどういう意味でしょうか

例えば std::complex については
http://eel.is/c++draft/complex.numbers
の記述からしてメモリレイアウトは実部虚部と決まってるわけですが、これはソースとは見なせないんでしたっけ？

**デフォルトの名無しさん** · 2021/06/20(日) 16:11:41.02

>>431
> それからC++03は2003年にC++98のバグ修正をしただけだから
> C99より古いぞ
ですから、
>>430
> Cの方が早かった
のでは？

あと>>433は「std::complex は C の複素数型と同じことを保証する」という記述は含みませんね
ただ、この場合メモリレイアウトが同じであることの他に要請するべきことってありますっけ？

**デフォルトの名無しさん** · 2021/06/20(日) 16:13:04.04

>>431,434
> ですから、
> >>430
> > Cの方が早かった
> のでは？

すみません
間違えました
ごっちゃになってました
これは取り消します

**デフォルトの名無しさん** · 2021/06/20(日) 17:28:56.50

https://stackoverflow.com/questions/55563217/do-complex-types-in-c99-behave-like-stdcomplex-in-c
ここを読むとメモリレイアウトは同一みたいなんだよね。むりやりキャストしても問題なさそうな気がするけど

**デフォルトの名無しさん** · 2021/06/20(日) 17:50:06.69

本質的なデータはdouble2つ組だし、順序も普通は実部→虚部だろうし、わざわざパディングや別の変なメンバ混ぜることも考えにくいし
たまたまレイアウト一致する可能性は現実的に高いだろうけど
規格が保証してるかどうかはまた別の話かな

◆QZaw55cn4c · 2021/06/20(日) 17:59:57.69

もう C は C89 で止めれ
C++ は　C89 だけ受け付け可能であれば、あとは好きに変えてもらってもかまわない