C++相談室 part157

**デフォルトの名無しさん** · 2021/08/09(月) 10:57:31.60

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

**はちみつ餃子** ◆8X2XSCHEME · 2021/10/08(金) 23:18:07.74

>>509
そのメッセージは「関数テンプレートはここで特殊化 (テンプレート引数を当てはめて具体的な型に展開) されたやで」
というメッセージで、普通は他の警告やエラーの補足として出てくる。なんか警告が一緒に出てない？

func が定義されとるけど使ってないという警告は出てくるけど無視して問題ない警告なのでコンパイルできないってことはない。
警告をエラー扱いにするオプションを付けてたりしない？

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

C+pod
https://toyota.jp/cpod/images/sec1-sld-img2.jpg

**はちみつ餃子** ◆8X2XSCHEME · 2021/10/08(金) 23:28:30.45

>>511
C++20 では std::is_pod や POD の概念自体が非推奨になってるぞ。
次あたりでは廃止されるんとちゃうか。

**デフォルトの名無しさん** · 2021/10/09(土) 21:11:49.30

あるラムダ式が他のラムダ式をコピーするとき、参照キャプチャにするかコピーキャプチャにするか迷うんですが、皆さんはどういう基準で決められてますか

**デフォルトの名無しさん** · 2021/10/09(土) 21:14:22.61

https://ideone.com/wq0CY8
やたーセマフォできたよ。

これバグってるかな?

**デフォルトの名無しさん** · 2021/10/09(土) 21:17:39.52

>>513
コピーキャプチャはコピーなので、それ相応のリソースを食う。
基本は参照キャプチャにしている。

**デフォルトの名無しさん** · 2021/10/10(日) 01:44:21.88

破壊的代入の余地が無いようする
つまりコピーを第一の選択肢として考えるする

**デフォルトの名無しさん** · 2021/10/10(日) 01:50:32.12

*thisはさすがに参照にすることが多いが（だいたいコピコンがあるとも限らないし、
とはいえ参照コピーしてパラメータに対する破壊的代入を許すと思想的に重箱読みになって気持ち悪い気がするし、
参照渡ししたオブジェクトは一般にスレッドローカルとは言い切れなくなることから
スレッドセーフと断言しにくくなるというのは実害に数えて良いと思う
入れ子になったラムダ式の奥深くでそれをやられると、いつ排他制御すべきなのかが全くﾜｹﾜｶﾒになりかねない

**デフォルトの名無しさん** · 2021/10/10(日) 04:41:44.62

>>516
だとすると一番効果的なのは
C++でコード書くこと自体をやめることだな
あんたの場合は

**デフォルトの名無しさん** · 2021/10/10(日) 07:01:43.04

>>516
コピーキャプチャが第一選択肢という結論は分かるが
それ以外の説明が完全に意味不明

**デフォルトの名無しさん** · 2021/10/10(日) 09:28:13.64

意図しない破壊を防ぐにはキャプチャしなきゃいいだけ
それを参照のせいにするゴミはプログラマの資質がない

**デフォルトの名無しさん** · 2021/10/10(日) 09:31:55.66

とりあえずで[&]で書いてるな
丁寧にやりたければ変数ごとに考えて明示する

**デフォルトの名無しさん** · 2021/10/10(日) 09:34:15.67

コピーのコストに無頓着なやつは11以後のC++に向かないな

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

スレッド立ち上げるとかファイル書くとかクソ重い操作が伴う時にコピーコスト気にしてもしょうがない
場合によるとしか

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

どこでも使う汎用性高いものなら問題が起きる前に[=]にしてる
逆に[&]はよほど安全だと思わない限り使わない

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

>>522
スレッドセーフをどう保証するかに無頓着な香具師はマルチスレッドプログラミングに向かんわ

>>518、>>519
低レベルなレスどうも
ラムダ式の成り立ちを知らなかったり
どのように使われるか想像できなかったり
使ったこと無いんじゃね；；；

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

>>525
スレッドがどうたらはおまえさんが勝手に言い出したことで元質問にはない
まさかとは思うがコピーしてりゃスレッドセーフなんて主張はしてないよな

**デフォルトの名無しさん** · 2021/10/10(日) 11:13:11.28

ラムダ式は一般にラムダ式を定義したスコープの外に持ち出され、予見できないタイミングで使われうる
参照キャプチャだと
(1) ラムダ式が使われるタイミングで参照xの参照先が存在することが保証されていなければならない
(2) ラムダ式が使われるタイミングで参照xの参照先へのアクセスが他のスレッドと競合しないことが保証されていなければならない
とゆー2条件をクリアする必要がある。
コピーキャプチャだと（オブジェクトがディープコピーなら）どっちの配慮も不要
参照キャプチャして(1)、(2)を満たして安心できるのは、イミュータブルなオブジェクトだけ……！

**デフォルトの名無しさん** · 2021/10/10(日) 11:14:48.07

>>526
ラムダ式、が含意する事柄について不十分な理解なレスktkr、
危険プログラマー認定のレベル3ぐらいやな；；；

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

>>527
ラムダ式をスコープ外に持ち出すなんてレアケースを「一般に」とか言われましても

**デフォルトの名無しさん** · 2021/10/10(日) 11:28:18.85

遅延評価されるものはよくコンテナに入れて後でぶん回されるから・・・

**デフォルトの名無しさん** · 2021/10/10(日) 11:28:30.83

>>529
定義するのと使う（評価する）のを同じスコープ内でやるならラムダ式使うまでもないじゃん？
ていうか使うまでもないんですよ
>>529はｱﾚな人？

**デフォルトの名無しさん** · 2021/10/10(日) 11:38:17.37

スコープ内の変数をキャプチャする処理をスレッドで動かす場合は普通にラムダ式を使うと思うが。

**デフォルトの名無しさん** · 2021/10/10(日) 11:39:34.18

>>531
はぁ？お前これしないの？ラムダ式のユースケースって9割方この類だろ
std::functionに突っ込んではるか遠くにぶん投げたりコンテナに詰め込んだりするのだけがラムダ式の使い道だと思ってるの？
std::sort(v.begin(), v.end(), [](int a, int b){/*...*/});

**デフォルトの名無しさん** · 2021/10/10(日) 11:57:37.17

みなさんスレッドセーフにしたいときはスレッドセーフになる様に書きましょう

**ハノン** ◆QZaw55cn4c · 2021/10/10(日) 12:13:39.02

>>522
11以前でも

**デフォルトの名無しさん** · 2021/10/10(日) 12:21:43.80

任意のスレッド安全性を実現するのはゼロコストでは不可能だから
必ずシングルスレッドで実行される保障がある場合などはあえてスレッド安全性を捨てることもある

**デフォルトの名無しさん** · 2021/10/10(日) 12:31:34.49

std::conj() に double を渡したら std::complex<double> にキャストされるのが嫌なので、double を渡したら何もしないで double を返し、std::complex<double> を渡したら std::conj() と同じ動作をするオーバーロード関数 conj() を作ろうかと思うのですがアリですか？

なぜ std::conj() がそういう動作じゃないのか不思議で、何か見落としてたら教えてください

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

こここ・・こういうこと？

(A)キャプチャが必要でスコープ内で実行までされるケース
(B)キャプチャが必要でスコープ外まで実行が遅延されるケース
(B-1)ラムダ式生成時と実行スレッドが同じケース
(B-2)ラムダ式生成時と実行スレッドが違うケース

(A)なら全員「[&]で問題があるケースはない」と考えている
(B-1)は好みが別れているところ
(B-2)は好みが別れているところで、さらにキャプチャされる変数側をスレッドセーフにするかどうも好み

[&]と[=]がよく分からない人はコチラ
https://ideone.com/OQS113

以下個人的意見
スレッドセーフにするコストは結構高い(開発・実行・保守全てで)ので、競合させずに遅延可能ならそれに越したことはないと考えている
ようはコピーするコストをそれほど高くは見積もっていない

**デフォルトの名無しさん** · 2021/10/10(日) 14:46:42.08

>>528
日本語でおｋ

**デフォルトの名無しさん** · 2021/10/10(日) 16:03:29.39

>>538
おまえさんの論法では同時並行はすべて別プロセスにすべきってことだな

**デフォルトの名無しさん** · 2021/10/10(日) 16:49:17.57

>>540
う～ん、伝わらないですね・・・
共有リソースに競合するアクセスがなければ排他制御の必要がなく、スレッドセーフにする必要がないってことです
そもそもコピーして共有しないことで排他制御が必要なくなれば、スレッドセーフにしなくていいという考え方ですよ

**デフォルトの名無しさん** · 2021/10/10(日) 16:51:53.70

だから共有＝リスクなんだろ？
もうマシンも別の実機にすれば最強防御じゃん

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

>>542
残念ですが理解してもらうことは諦めます

**デフォルトの名無しさん** · 2021/10/10(日) 17:32:07.51

>>533
頭の中がgdgdな人が話をgdgdにしようとしていまつね……
std::sort()の呼び出しと同じスコープが終わった後に
[](int a, int b)が呼び出されないということは、単にstd::sort()がreturnするまでにラムダ式を忘れてくれる作りだから（たまたま）担保されているだけであって、
[](int a, int b)のスコープが限定されるために担保されているわけではないし、
[](int a, int b)がラムダ式だから担保されているわけでもないの。

つまり、>>533は
>ラムダ式をスコープ外に持ち出すなんてレアケース（>>529）
の根拠に全くなっていないワケ

**はちみつ餃子** ◆8X2XSCHEME · 2021/10/10(日) 17:47:25.28

レアケースがどうこういったところでレアケースなら考えなくていいってわけでもない。
そんなの個別の事例ごとに考えるしかしょうがないだろう。

**デフォルトの名無しさん** · 2021/10/10(日) 17:56:25.23

>>543
無理筋の主張ってことがわかってもらえたならいいよ

**デフォルトの名無しさん** · 2021/10/10(日) 18:04:09.07

>>546
無理筋ではありませんよ
スレッド以前から並列処理で共有される実行コンテキストを分けることは大昔からやられてきました
今更その手法自体を想像できない人に、こんなところで説明するのは困難なだけです

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

おまえさんの言う「大昔」がどのくらいか知らんが
俺が若手の頃はRENT,REUSなんてやってたよ

**デフォルトの名無しさん** · 2021/10/10(日) 18:25:30.38

ラムダ式によって作られたオブジェクトがキャプチャされたオブジェクトより長生きする可能性があるならコピーキャプチャ
そうでなくともレジスタに乗ると思われるならコピーキャプチャ
そうでない場合に初めて参照キャプチャ

排他に関してはshared_ptr<mutex>とshared_ptr<なかみ>をメンバに持たせてコピー可能にしつつ、メンバ関数経由で排他制御するのが筋だと思う
RustのArc<Mutex<T>>パターンに影響されすぎかもしれないが……
いずれにせよキャプチャと排他制御の問題とは切り離して考えることができるし、そうすべき

**デフォルトの名無しさん** · 2021/10/10(日) 21:19:12.50

ラムダ式関連でいうと参照とかコピーをデフォルトだけで指定したときも実際に使ったものの分しかクロージャオブジェクトのサイズに乗ってこないと思ってるんだけどヤバい？

**デフォルトの名無しさん** · 2021/10/10(日) 23:42:34.57

>>550
むしろ他に何が乗ると思っているのか？
気になるなら生成コード見て確認すればいいだろうとも思うし。

**デフォルトの名無しさん** · 2021/10/10(日) 23:58:18.57

>>548
大昔とは1990年頃の話です
COBOLなのか知りませんが、reentrantとreusableは今回の話と直接関係ありません

**デフォルトの名無しさん** · 2021/10/11(月) 02:51:41.68

>>551
cppref見たらクロージャオブジェクトのサイズは未規定とあって気になった

**デフォルトの名無しさん** · 2021/10/11(月) 05:43:06.87

>>552
関係大ありだよ
あの当時はアセンブラでC++は使ってなかったというだけだ
わかってないのおまえさんだな

**デフォルトの名無しさん** · 2021/10/11(月) 07:43:50.36

>>554
説明するべきでないのが残念ですが、その頃からあなたが分かってなかっただけですよ

**デフォルトの名無しさん** · 2021/10/11(月) 07:52:27.26

>>555
おまえさんがどう思おうと勝手だが
センターオウンコーディングとかやってたよ
マウント取られる気が全くしねえぜ

**デフォルトの名無しさん** · 2021/10/11(月) 08:08:27.81

>>556
マウント取る取らないとかどうでもいいです
あなたが理解できないのをどうにもできないだけなんです

**デフォルトの名無しさん** · 2021/10/11(月) 08:46:34.77

と言うことにしたいのですね

**デフォルトの名無しさん** · 2021/10/11(月) 09:17:45.21

リエントラント目指してもいいじゃないの

**デフォルトの名無しさん** · 2021/10/11(月) 09:58:01.98

クラスの型を自動変換して関数に入れるにはどうすればいいですか？例えば、

class A {
public:
double hoge;
};
class B {
public:
int hogehoge;
};

int function(A aaa);

があった時に、functionにB型を入れても動くようにしたいです。
クラスAのソースに、Bから生成するコンストラクタ書ければいいのかもしれませんが、
実際はAはライブラリのクラスで触れなくて、Bが自作のクラスになります。

**デフォルトの名無しさん** · 2021/10/11(月) 10:22:18.86

>>560
Bを受け付けるfunctionを書くんや

**デフォルトの名無しさん** · 2021/10/11(月) 10:50:11.05

B extends A
としたら
function
の引数をキャスト？で動かない？

**デフォルトの名無しさん** · 2021/10/11(月) 10:54:01.94

簡単や
template<class A>
int function(A aaa);

**デフォルトの名無しさん** · 2021/10/11(月) 12:11:05.48

できました。ありがとうございます。

また、ポインタのvectorを実体として使うにはどうすればよいでしょうか？

std::vector<A*>
で定義されてるものを、
std::vector<A>として使いたいです。
別のvectorにポインタ値を詰め直せばいけると思うのですが、元のポインタの場所のまま実体で使いたいです。無理でしょうか。

**デフォルトの名無しさん** · 2021/10/11(月) 12:31:51.97

参照を使うんや

**デフォルトの名無しさん** · 2021/10/11(月) 13:03:47.84

参照のvectorなんて作れたっけ？

**デフォルトの名無しさん** · 2021/10/11(月) 13:16:00.26

reference_wrapper使うんや
まあ下らんこと考えんほうがええ

**デフォルトの名無しさん** · 2021/10/11(月) 17:28:01.69

>>564
ややこしい所有権・所有責任問題が発生するから、ソースコードを見直したほうがいい。
具体的にはstd::vector<*A>を
std::vector<std::shared_ptr<A>>
にして、shared_ptr<A>をやり取りするようにすべきだな。

性能問題とか互換問題とかでも無ければvector<*A>なんて使うもんじゃない。

**デフォルトの名無しさん** · 2021/10/11(月) 20:43:04.76

言ってることは同意だが、ポインタの型もまともに書けないような人に言われても説得力がない

**デフォルトの名無しさん** · 2021/10/11(月) 20:47:36.58

Rustと間違えたんじゃね

**デフォルトの名無しさん** · 2021/10/11(月) 22:25:40.15

簡単や
std::vector<std::shared_ptr<A>>

**デフォルトの名無しさん** · 2021/10/11(月) 23:13:38.91

ドラクエ３のバージョン違いの謎に迫る！
https://www.youtube.com/watch?v=sh5GXYs6T1c
2021/10/01に公開済み

FC版DQ3には、ＡバージョンとＢバージョンが存在する
今回はROM内のプログラムを徹底比較！
どこが違うのか白黒ハッキリさせると息巻いた内藤プロ
当時自分が作ったのに全て忘れてて大変なことに・・

**デフォルトの名無しさん** · 2021/10/12(火) 04:13:48.50

ぶっちゃけ継承とかポリモフィズムはオワコンでテンプレート最強？

**はちみつ餃子** ◆8X2XSCHEME · 2021/10/12(火) 04:25:26.30

>>573
過去の C++ の流行においては継承が強調されすぎたこともあって
継承の害悪な面も見えて大幅な揺り戻しは有った。

しかしそれぞれに役割があるのでどれかが廃れるとかいう話ではない。
バランスとしては継承が控えめになったけれど、だからといって継承のない C++ はありえない。
結局のところそれぞれを適切に使えというだけのこと。

**デフォルトの名無しさん** · 2021/10/12(火) 06:45:14.85

継承が有効に使われている事例をひとつも知らないヒヨっ子丸出しな質問だな
テンプレートの何がいいのかもわかってなさそう

**デフォルトの名無しさん** · 2021/10/12(火) 07:03:36.18

CRTPとか見たら脳を壊しそう

**デフォルトの名無しさん** · 2021/10/12(火) 07:24:36.11

>>576
virtual使えないor使わない処理系で、使ってみたけど確かに頭にスッキリ入らんパターンだわｗ
あれはあれでポイントで使うと便利だし、反対にやっぱvirtualも便利でいいよねーとか。

**デフォルトの名無しさん** · 2021/10/12(火) 08:16:42.08

>>573
メソッド共通化を実現するための継承はオワコン。
プレースホルダーを用意するための継承は現役。

総称型が実装されれば継承自体をオワコンにできそうな気がするけど、総称型風スマートポインタて無かったっけ？

**デフォルトの名無しさん** · 2021/10/12(火) 08:20:36.96

耳が腐る

**デフォルトの名無しさん** · 2021/10/12(火) 09:51:23.11

何でこんな荒れてんの？

**デフォルトの名無しさん** · 2021/10/12(火) 10:09:23.54

いつものこと

**デフォルトの名無しさん** · 2021/10/12(火) 10:40:17.54

単発荒らしか

**デフォルトの名無しさん** · 2021/10/13(水) 04:27:45.44

void * の生ポが最強

**デフォルトの名無しさん** · 2021/10/13(水) 07:29:48.53

○○なんていらねーよ害悪だけだ
まだ使ってるやつは全員バカ
これからは△△を使うべきだ
なーんて言っちゃってマウント取った気になってるおめでたいやつ
メガトン級にアホにされてることに気付かねえよな

**デフォルトの名無しさん** · 2021/10/13(水) 09:41:39.46

vector を shuffle する場合について質問です(gcc/windows10でテスト)

vector<int> vec(50, 0);
for(int i = 0; i < 10; ++i) vec[i] = 1;
random_device dev_seed;
mt19937_64 mt(dev_seed());
shuffle(vec.begin(), vec.end(), mt);

で確かに shuffle されているのですが疑問点がいくつかあります
1.dev_seed()が毎回同じ値を返してる？
(random_deviceの使い方を間違えてる？)
2.先頭の値が1に偏ってる？
(shuffle() を数回繰り返す解決方法もあるようですがあまり気持ち良くないです)
3.そもそもforで先頭の方に1を入れる発想が良くない？
(shuffleされてるならこれは関係無いと思いたい)

**デフォルトの名無しさん** · 2021/10/13(水) 09:47:25.08

ああこれか
https://cpprefjp.github.io/reference/random/random_device.html
>GCC (MinGW): GCC 9.1までは擬似乱数生成器 mt19937 を用いるため使用を推奨しない。詳細は備考欄を参照。GCC 9.2からは暗号論的な乱数である rand_s を使用する。

**デフォルトの名無しさん** · 2021/10/13(水) 10:51:16.02

偏りを判断する目が偏ってるのでは

**デフォルトの名無しさん** · 2021/10/13(水) 12:39:29.13

random_deviceがダメな環境でrdtsc命令使ったことあるな
良いやり方かは知らん

**デフォルトの名無しさん** · 2021/10/13(水) 16:09:05.50

https://cpprefjp.github.io/ って
https://ja.cppreference.com/ があるのになんで使われてるの？

**はちみつ餃子** ◆8X2XSCHEME · 2021/10/13(水) 16:23:55.69

>>589
前者は編集者による解説なども含んでいて仕様の意図や習慣がわかりやすい。実装の現実みたいな補足もあるし。
後者は仕様書の再編を指向してるから正確だけど規則の羅列を読むのがしんどいこともある。

適宜使い分けて。

**デフォルトの名無しさん** · 2021/10/13(水) 16:49:55.63

>>590
ありがとう

**デフォルトの名無しさん** · 2021/10/14(木) 00:25:54.44

逆にjaはほぼ見ないな
cpprefjpかen

**デフォルトの名無しさん** · 2021/10/14(木) 17:38:44.33

みんなで広げよう友達の輪
https://github.com/cpprefjp/cpprefjp.github.io

**デフォルトの名無しさん** · 2021/10/14(木) 19:08:30.88

今までJavaでやってきたけどC++もやってみたいんだよね
すぐ出来るようになると思う？

**デフォルトの名無しさん** · 2021/10/14(木) 19:10:28.43

>>594
ならない
C言語のポインタや文字列について勉強したほうがいい

**デフォルトの名無しさん** · 2021/10/14(木) 19:12:47.65

>>594
c++でちょっとした文字列パースして内容に応じたオブジェクト構築する処理書いてたの、
ほぼ使ったことないJavaに移植したらスゲー早く出来てワロタ。C#もサクサクできたな～
逆は色々イラッとするんじゃねぇかな?

**デフォルトの名無しさん** · 2021/10/15(金) 01:29:52.42

元々C++はその辺の文字列処理を毎回1からゴリゴリ書くような言語じゃなくて何らかのライブラリを利用するものだと思うけど、
クロスプラットフォームで各種文字コードが自由に扱えて、c++11以降の仕様に対応してて、かつかゆいところに手の届くライブラリって意外とないんだよね
いや、俺が知らないだけかもしらんけどw

**デフォルトの名無しさん** · 2021/10/15(金) 05:56:29.15

実質的な標準と呼べるものは今もないよ

**デフォルトの名無しさん** · 2021/10/15(金) 09:26:39.59

>>596
std::regex使ってようやっと、かね。

c++はいつまでたっても文字列処理苦手なままだわ。

**デフォルトの名無しさん** · 2021/10/15(金) 10:21:28.25

Javaから入ると不能(陰ポ)になる
もう手遅れ

**デフォルトの名無しさん** · 2021/10/15(金) 10:22:26.59

>>597
wxWidgets

**デフォルトの名無しさん** · 2021/10/15(金) 10:26:50.27

あれ出来上がるバイナリ重すぎなんだけど、今は違ったりするのかね

**デフォルトの名無しさん** · 2021/10/15(金) 11:49:16.16

Debugだとバカデカくなるけど
Releaseは気にならないレベル
(DLL除く)

**デフォルトの名無しさん** · 2021/10/15(金) 11:53:45.11

std::regexと等価なインターフェースを各々の正規表現ベンダーが用意してくれればいいんだが、それすら実現されていないお寒い状況

**デフォルトの名無しさん** · 2021/10/15(金) 12:03:59.88

>>599
その辺も無いわけじゃないんだけど、クラスの構造どうしようかとか、メモリ管理どうするかとか、
変態trmplateでパズルしてみようかとか、選択肢多い分考えることも多い部分で時間かけることが
多い所はあるなーって。それがC++使いたい動機の裏返しでもあるんだけど。
あと本人の問題120%だが、ボケて油断してると、エラー直すのにやたら時間かかったりで。
Javaとか詳しく知らん状態だから言えるのかもしれんけど、もうこうするしかネェってレールが
最初からあるような印象でした。つかオラクルのライセンス問題のほうがムズいｗ

**デフォルトの名無しさん** · 2021/10/15(金) 12:19:11.94

等価って図々しいだろ

**デフォルトの名無しさん** · 2021/10/15(金) 12:34:03.36

std::regexみたいな文字コードというものがあることを知らない人間が作ってそうなものを標準だと思ってつかうのはやめたほうがいいと思います

**デフォルトの名無しさん** · 2021/10/15(金) 12:53:35.21

char8_tが導入されたんだからutf-8しばりでいいじゃない

**デフォルトの名無しさん** · 2021/10/15(金) 13:14:36.67

なんか最近曖昧な上に突っ込む点多すぎる内容的にはどうでもいい話題が多くない？

**デフォルトの名無しさん** · 2021/10/15(金) 13:33:42.62

>>607
utf8限定ならそこそこ。
もうutf8がデファクトだから、内部処理はutf8に統一した方がいいよ。