C++相談室 part161

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

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

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

>>415
MyClass a();
MyClass & b = MyClass();
const MyClass & c = MyClass();
MyClass d = MyClass(); ← コピーコンストラクタ発動？
それともムーブ？

**デフォルトの名無しさん** · 2022/08/06(土) 14:34:58.43

explicit指定してないならムーブだ

**デフォルトの名無しさん** · 2022/08/06(土) 15:11:57.86

>>421
javascriptやelectronやphpやvb/vbaの方が判ってない人が描いてる確率は高い

**デフォルトの名無しさん** · 2022/08/06(土) 15:16:10.01

>>449
最近覚えたのは Win+G ですね判ります

**デフォルトの名無しさん** · 2022/08/06(土) 15:17:59.77

>>449-450
ああそれで
「押してみないと判らない」
って話が出て来たのか
普通の人間なら闇雲に押すんじゃなくて
押す前にマニュアルやヘルプファイル読むだろうな

**デフォルトの名無しさん** · 2022/08/06(土) 15:44:10.54

GUIでキー操作というのは矛盾も含んでいるんだけどな

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/06(土) 17:10:45.24

>>454
基本的にはムーブコンストラクタが呼ばれる場面なんだけど……。
一定の条件でコピーやムーブを省略 (Copy elision) してよい場合がある。
MyClass d = MyClass();
はその条件にあてはまるので
MyClass d();
と同じ挙動になることがある。 (コピーもムーブも起こらない。)

省略が許される場合の一部が C++17 以降では省略が必須に変更された。
また、 C++17 以降で省略が必須のときはコピーコンストラクタもムーブコンストラクタも存在しなくてよい。
故に以下↓のような例は C++14 ではエラーだが C++17 では通る。

struct MyClass {
MyClass(const MyClass &) = delete;
MyClass(void) = default;
};

int main(void){
MyClass d = MyClass();
}

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

>>459
初代macか

**デフォルトの名無しさん** · 2022/08/07(日) 09:01:37.78

むかしまだMacOSが漢字TalkだったころにMacキチガイの知りあいが
「Windowsなんて駄目だよ、だいたいマウスにボタンが2つあるみたいなシンプルさを欠く設計な上に
なにかとキーボードを併用しないといけない、GUIとして未完成といわざるをえない(キリッ」とかいいながら
Macでマウスボタンとコマンドキーやらシフトキーのコンビネーションをものすごい熟練の手付きで操作していたのが印象的だった

**デフォルトの名無しさん** · 2022/08/10(水) 19:17:19.29

windows10でスタートメニューを非表示にしたいのですが良い方法ないですかね？
スタートメニューのHandleを取れれば良いのですが、、。
ネットでいろいろ調べましたが見つけたサンプルコードは、windows10では動きませんでした。

**デフォルトの名無しさん** · 2022/08/10(水) 19:51:18.63

何をしたいのかいまいちわからんけどシェル差し替えればいいんじゃね？
https://docs.microsoft.com/ja-jp/windows/configuration/kiosk-shelllauncher

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

以下のプログラムを実行したとき、変数xとyが初期化されるのはどういう理屈ですか？

class myClass
{
public:
int x;
int y;
};

int main()
{
myClass c{ 100, 200 };
}

暗黙のコンストラクタで代入されているのかと思いましたが、
xとyをprivateにするとコンパイルエラーになるので違うようです。
インスタンス生成の{}を()に変えるとコンパイルできなくなるのでそれもどうしてか知りたいです。

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

struct myClass
{
int x;
int y;
};

int main()
{
struct myClass c = { 100, 200 };
}
と同じ理屈じゃね？

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

publicだけならcの構造体と同じだからね

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

C言語からやってないと構造体の初期化は理解出来んだろうな

**デフォルトの名無しさん** · 2022/08/11(木) 08:18:14.02

trivial ctorじゃ説明つかないからなaggregateは

**デフォルトの名無しさん** · 2022/08/11(木) 09:13:13.76

建増しでやってきた言語だからしょうがないけど初期化の方法がやたらいっぱいあって混乱する

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/11(木) 10:28:32.68

>>465
集成体初期化 (Aggregate Initilization) に該当する。
クラスが一定の条件を満たしたときに集成体の扱いになる。
文法表記を似せているだけの別物と思った方がいいかも。

ちなみに C++20 からは丸括弧でも集成体初期化が出来るようになってるよ。

**デフォルトの名無しさん** · 2022/08/11(木) 16:39:22.98

>>466-467, >>471
ありがとうございます
C言語の構造体の初期化と同じですね
後方互換を保つために残してるような気がしました
コンストラクタ定義が無いときしか使えないんですね

**デフォルトの名無しさん** · 2022/08/15(月) 03:58:18.08

皆さんにお聞きしたいんですけど
inline展開しまくることによる弊害って主になんでしょうか？

**デフォルトの名無しさん** · 2022/08/15(月) 04:01:03.39

コードがでかくなる

**デフォルトの名無しさん** · 2022/08/15(月) 04:48:08.80

コンパイルが遅くなる

**デフォルトの名無しさん** · 2022/08/15(月) 06:06:45.25

もうデメリットはなくなって来たな
実際のコンパイラもデフォでinlineぽい動きするし
ただの開いたサブルーチンというだけでなく定義の統合がありがたい

**デフォルトの名無しさん** · 2022/08/16(火) 10:58:28.11

デバッグが面倒臭くならない？
そうだあれか
リバエンし難くする効果があるとか

**デフォルトの名無しさん** · 2022/08/16(火) 11:14:28.05

インライン展開するとスタックトレースで関数名が出なくなりますか？

**デフォルトの名無しさん** · 2022/08/16(火) 14:07:30.89

>>478
コンパイラにもよると思うけど
おそらく出なくなると思います!

**デフォルトの名無しさん** · 2022/08/16(火) 14:11:45.62

>>474-475-476-477
なるほど…

**デフォルトの名無しさん** · 2022/08/16(火) 14:16:34.26

c++ってまだまだ需要あると思いますか？
私はあるかなと思うんですけど...意見ください。

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/16(火) 14:22:21.76

何年も前だがインライン展開の基準を指定する GCC のオプションで
めちゃクソに緩めの数値を指定 (つまりインライン展開されまくる) して
ベンチマークをとった記事が話題になったような覚えがある。

結論を覚えてないし、どこで見たのかも覚えていないので役に立たん話ですまぬ。

**デフォルトの名無しさん** · 2022/08/16(火) 14:48:39.55

>>481
C++は需要が減り衰退していく
昔はともかく現代の視点からは、設計が悪くそこへ建て増しを繰り返しているため、言語として劣っていて使いにくい
そのため次第に既存システムの保守がメインの言語となっていっているが、それさえGoogleの発表したCarbonのような言語の方がプログラマーにとってもありがたい
もちろんそのCarbonでさえそのFAQにこれはあくまでも既存の保守用の言語でと書かれている

**デフォルトの名無しさん** · 2022/08/16(火) 14:52:39.64

設計思想のないバカがさわるとえらいことになる言語だからな

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

>設計が悪くそこへ建て増しを繰り返している

言語仕様がそうなっていることは認めるが
設計が悪い部分は無理して使わず良い部分だけ使えば良い話でもある

**デフォルトの名無しさん** · 2022/08/16(火) 15:17:41.42

皆が皆そうしてくれないから自然に淘汰されていく訳だが

**デフォルトの名無しさん** · 2022/08/16(火) 15:24:11.24

>>481
需要で言えばCOBOLでさえ無くなっていないからなぁ。

c++の完全置き替えはRustがようやっとスタート地点に立てたくらい。でもRustは初心者お断りだから無理なんじゃない？

個人的にはRustを参考にした初心者向けのサブセットC++か、Rustの複雑さをマイルドにしたスタックフレーム指向の新言語が出てくると思う。

**デフォルトの名無しさん** · 2022/08/16(火) 15:54:40.98

msvcはインライン展開あんましてくれないな

**デフォルトの名無しさん** · 2022/08/16(火) 15:57:43.55

>>487
誰が見てもC++よりRustの方が言語仕様も小さいしシンプルで洗練されていて学習しやすいよ
これは両方を使っている人なら必ず分かるから>>487は知らないものを妄想で語っている？
ちなみにRustはコンパイラによるアドバイスが非常に親切でプログラミング言語の中でもトップクラスな点でもC++との差異が大きいね

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/16(火) 16:21:45.34

どうだろうなぁ。
C を学んでいる人が多かったというところから実務に使いながら少しづつ C++ に習熟していくという動線があったわけで、
C という前提が崩れたら Rust のほうが合理的に設計されていて楽かもしれないとは思う。
ただ、その一方で C++ が消えてなくなるほど劣勢になる気はしないんだよな。

**デフォルトの名無しさん** · 2022/08/16(火) 16:38:57.39

c++とかcやってからじゃないと到底無理
ってよく聞くんですけど
どういうことですかね？

**デフォルトの名無しさん** · 2022/08/16(火) 16:39:15.94

class b:a{};
class a{};
このコードはコンパイルできませんが、aを前方宣言せずにコンパイルを通す方法ってありますかね?

**デフォルトの名無しさん** · 2022/08/16(火) 17:52:12.39

1.
class a;
class b:a{};
class a{};

2.
class a{};
class b:a{};

**はちみつ餃子** ◆8X2XSCHEME · 2022/08/16(火) 17:53:02.94

>>491
個々のルールを頭に詰め込むだけってのはしんどい。
思想に沿うように個々のルールが制定されているので思想が分かればある程度はルールの想像がつく。
低レイヤで何が起こるかある程度は認識していると思想が把握しやすい。

C++ の駄目な部分を見た後に Rust を見ると「こういうのが真っ当な仕組みだよな！」という納得もしやすいし。

ただ、 C++ の「汚くていいんだ」というのもそれはそれで優しい世界なので私は好きだよ。

**デフォルトの名無しさん** · 2022/08/16(火) 19:22:32.37

>>489
初心者からすればC++とRustの差なんて無いに等しい。コード１行書くのにいくつのルールを守る必要があるんだよ。
シンプルで洗練されている言語が初心者に良いというなら、RustよりFORTH(とその末裔)の方が初心者にふさわしいと思うわ。

**デフォルトの名無しさん** · 2022/08/16(火) 21:48:30.73

母国語みたいなもんなんでCの覇権は変わらない

**デフォルトの名無しさん** · 2022/08/16(火) 22:17:19.28

>>495
FORTHはCと同等の速さを出せないし問題のすり替えはみっともない
RustはCと同等の速さを出しつつ現代的なプログラミングしやすい様々なパラダイムを洗練してシンプルにまとめている
FORTHを入れてC/C++/Rustの四者で比較してもRustがプログラミング効率も良いと同意できるだろ

**デフォルトの名無しさん** · 2022/08/17(水) 02:44:27.88

夏厨って夏に湧いて出る厨房の事を指す言葉だったはずだけど
その厨房も今じゃ中年おじさんなんだよな

**デフォルトの名無しさん** · 2022/08/17(水) 04:51:00.22

>>497
Rustは初心者が学習しやすい言語ではないし問題のすり替えはみっともない

**デフォルトの名無しさん** · 2022/08/17(水) 05:49:59.92

>>499
そうかな
C++(スマポ必須で所有権)よりはRustがシンプルではっきりと初心者向けだよ
自動解放で安全が前提でないと困るからその二つが比較対象で合っているよね

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

皆さんのオブジェクト指向に対する考え方
おください!

**デフォルトの名無しさん** · 2022/08/17(水) 08:26:24.61

>>500
C++との比較なんてしていない。よく読め。
C++が駄目なのと同じくらいRustも初心者の学習コストはダメ。
C++はまだ部分的に汚く使う柔軟性を持つから、better c くらいのところから段階的に使う余地はある。しかしRustはいきなり複数の概念(所有権とか参照とかmoveとか)を使わないとプログラムが書けない絶壁の学習コストをしているから、「とりあえず使う」という選択肢が無い。初心者の選ぶ言語にはならんよ。

**デフォルトの名無しさん** · 2022/08/17(水) 08:34:18.80

>>501
オブジェクト指向のオブジェクトは主体/客体のサブジェクト/オブジェクト。
プログラマー(主体)が操作・命令する対象(客体)をまとめて整理する考え方＆手法がオブジェクト指向。

**デフォルトの名無しさん** · 2022/08/17(水) 08:40:13.74

>>502
C++のスレで「C++と比較していない！」と言い出すそなたの頭のネジが飛んでるとしか

**デフォルトの名無しさん** · 2022/08/17(水) 08:43:38.31

C++のスレでRustの話をする人の頭のネジは緩んではいないのか

**デフォルトの名無しさん** · 2022/08/17(水) 08:50:31.11

他の言語との類似や相違など色んな話題が出てもええんちゃう
特にRustはC++後継言語の一つでもあるし

**デフォルトの名無しさん** · 2022/08/17(水) 08:54:01.88

勝手に決めんな

**デフォルトの名無しさん** · 2022/08/17(水) 09:18:05.65

GAFAMがRustをC++の後継言語の1つとして位置付けてRust Foundationを共同で設立したりしてますもんね
ただしGoogleは既存コードのメンテ用としてはCarbonもC++の後継言語の1つとして実験していますね
Rustはシステム更新時や分離できる新たな部分に対してC++の後継言語となるのでしょう

**デフォルトの名無しさん** · 2022/08/17(水) 09:43:49.92

>>504
C++関連としては>>487。
あとは「Rustは初心者向けじゃないからC++後継できるところまでは行かん」という主張に対する話。C++だって学習障壁から初心者取り込みできずにユーザー規模が縮小しつつあるのに、もっと絶壁のRustが普及するとは思えん。
C++後継としてはRust以外の初心者に配慮した言語が来るんじゃない？

**デフォルトの名無しさん** · 2022/08/17(水) 10:06:28.08

スマポすなわち所有権を使ってるC++プログラマーならRustは簡単で楽勝
まともな案件ならばスマポ使っているし、急にではないけど、より安全なRustへ徐々に少しずつ移っていくんだと思うよ

**デフォルトの名無しさん** · 2022/08/17(水) 10:18:24.59

>>506
それなら類似や相違など語り合うスレのほうがいいのでは？
無いなら立てれば良いし
C++の相談に来ているスレで今はRustだよなんて言われてもね

**デフォルトの名無しさん** · 2022/08/17(水) 10:27:35.49

学習障壁でユーザー規模が縮小って
なんかCOBOL臭えな

アホフィルタを外すより待遇を改善すべきだろ
マ板でやるべき内容だな

**デフォルトの名無しさん** · 2022/08/17(水) 10:30:15.50

rustはアホでも書ける言語ではないよな
良いか悪いかはさておき

**デフォルトの名無しさん** · 2022/08/17(水) 10:41:14.61

は？「C++が使える」アホは俺でも知ってるが
それがこの話と何か関係あるのか？

**デフォルトの名無しさん** · 2022/08/17(水) 10:45:01.06

お前が知ってるかどうかなんか知るかよ
荒らしたいだけなら少し黙ってろ

**デフォルトの名無しさん** · 2022/08/17(水) 11:20:40.84

きみらはなぜ些細なことですぐ喧嘩するのか・・・

**デフォルトの名無しさん** · 2022/08/17(水) 12:01:52.68

>>509
Rust++ですね判ります

**デフォルトの名無しさん** · 2022/08/17(水) 12:03:04.79

都合が悪くなると荒らしたいだけとか全く
C++相談室でRustを連呼するやつに言われたかねえな

**デフォルトの名無しさん** · 2022/08/17(水) 12:06:02.53

相談者はチームで突然、Rustに変えようと言い出せば
解決につながるとでも言うのか
そんな力のあるやつが相談に来るとでも？

**デフォルトの名無しさん** · 2022/08/17(水) 12:31:04.58

シンプルで現代的なZig言語、RustやC++が複雑すぎると嘆く人の福音となるか
https://news.mynavi.jp/techplus/article/programinglanguageoftheworld-44/

**デフォルトの名無しさん** · 2022/08/17(水) 12:50:49.80

手動メモリ管理のZigでは無理だよ
手動メモリ管理で複雑化したときにどうしても発生している穴を防ぐことがどのIT企業でも課題となっている

**デフォルトの名無しさん** · 2022/08/17(水) 13:33:15.30

自動にしてもjavaみたいにメモリバカ食いしてるのも大概だけどな

**デフォルトの名無しさん** · 2022/08/17(水) 13:46:04.27

shared_ptrやunique_ptrで特に問題ないと思うが?
手動メモリ管理ってパフォーマンスでも気にしてるの?

**デフォルトの名無しさん** · 2022/08/17(水) 14:31:54.15

shared_ptrはほんとに良いものなのかちょっと疑問だわ

**デフォルトの名無しさん** · 2022/08/17(水) 15:14:20.93

>>522
それはJavaがGC言語だからしょうがない
非GC言語でプログラマーによるコードに依存せず自動メモリ解放して欲しいならば現状Rustしかない

**デフォルトの名無しさん** · 2022/08/17(水) 15:36:27.49

shared_ptrやunique_ptrで何か問題があるかな?

**デフォルトの名無しさん** · 2022/08/17(水) 15:37:16.76

いらんわ
まさかそんなくだらん話だったとは
買い被らせやがって

**デフォルトの名無しさん** · 2022/08/17(水) 15:53:30.62

>>523
正確にはスタックフレームに積む or スマートポインタを使ってヒープに置く、だな。

shared ptrは関数呼び出し時の値渡しのインクリメントデクリメントコストが気になるところ。
スタックフレームに存在するかどうかで参照渡しか値渡しかを自動で切り替えると便利そうだけど、最適化で上手く処理してくれたっけ？

**デフォルトの名無しさん** · 2022/08/17(水) 15:54:04.11

>>526
使い忘れと使い方ミスを常に完全にゼロにできるならばunique_ptrとshared_ptrでOK
しかし複雑化した時にミスを常にゼロにすることは不可能だと判明している

一方でC++からRustにすると以下のようなメリットが山のようにある
・Rustでは使い忘れや使い方ミスをするとコンパイラが必ず指摘してエラーとしてくれる
・Rustでは何も指定しない標準状態でC++のunique_ptrより高機能であるため記述がスッキリそして分かりやすい
・複数の参照があるとC++では参照カウントコストのかかるshared_ptrを使う必要があるがRustではそのコストを必要としない
などなど

**デフォルトの名無しさん** · 2022/08/17(水) 16:16:02.25

殺虫剤のパラドックスてやつ

**デフォルトの名無しさん** · 2022/08/17(水) 16:31:22.99

こんなとこで Rustの宣伝されてもな・・・

**デフォルトの名無しさん** · 2022/08/17(水) 17:56:04.99

この手の議論って「全てのプログラマがポインタを直に操作する必要に迫られている」という詭弁に基いていて辟易するんだよな

**デフォルトの名無しさん** · 2022/08/17(水) 18:05:51.06

RustなんかやめてDelphiにしようぜ

**デフォルトの名無しさん** · 2022/08/17(水) 18:34:02.81

最近ポインタ使わんよね

**デフォルトの名無しさん** · 2022/08/17(水) 18:40:18.95

>>532
ある程度の大きなデータは抽象的な意味でcall by reference (pointer) により受け渡しすることになり実装的にはポインタを使わざるをえない気もする

**デフォルトの名無しさん** · 2022/08/17(水) 19:39:41.85

>>529
Rustの変数をunique ptrと比較している時点でRustの利点を理解出来ていない。
Rustの変数に対応するのはあくまで自動変数で、unique ptr に対応するのはBox<T>。

Rustは「高速化と自動化のためにできるだけスタックフレームを活用する」という基本的な考え方があって、そのためにあの窮屈なルールで自動変数を高機能化している。
Rustの変数がデフォルトムーブだからといって、Rustの変数はunique ptr みたいなものとするのは理解の足りない粗忽者のやることだわ。

**デフォルトの名無しさん** · 2022/08/17(水) 19:59:51.79

>>536
ある意味それも正しいが現実問題じゃないな
例えばi32を10個返す関数を作るとして
その型を[i32; 10]、Box<[i32; 10]>、Vec<i32>のそれぞれにした場合に生成コードはどうなりどれを選ぶべきか考えるとBoxの意義がなああ
結局Rustではもっと最適なものを選ぶからunique_ptr相当すら使うことがレアだよな

**デフォルトの名無しさん** · 2022/08/17(水) 20:32:26.88

>>491
C++ちょっと分かったなーって気持ちになれるまでの遠い道のりを考えると、Cができるなんて入口にすら立ってない感じ。
だからC知ってたくらいではアドバンテージないよ。個人の感想です。

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

>>529
>・複数の参照があるとC++では参照カウントコストのかかるshared_ptrを使う必要があるが
>Rustではそのコストを必要としない
本当にコストは必要ないのかな?
本当に参照カウントしないのかな?

**デフォルトの名無しさん** · 2022/08/17(水) 21:11:48.18

>>536
unique_ptrはmemory allocationとは全く関係ありません

**デフォルトの名無しさん** · 2022/08/17(水) 21:31:24.12

unique_ptrなんて自動変数と変わらんじゃろ

**デフォルトの名無しさん** · 2022/08/17(水) 21:37:14.43

>>539
Rustは借用(とライフタイム)があるから、
複数の参照が同時に必要となっても、
所有者は一人のまま何も変わらず、
複数の借用を普通に使うだけで済んでしまい、
付加コストの発生は無し。

一方でC++は、
複数の参照が同時に必要となる場合、
unique_ptrではもちろんダメなので、
shared_ptrを使わざるを得ず、
参照カウンタ増減という付加コストが発生。

**デフォルトの名無しさん** · 2022/08/17(水) 21:39:05.15

>>540
デフォルトはヒープを想定しているだろ。
Rustの変数はデフォルトスタックを想定している。

**デフォルトの名無しさん** · 2022/08/17(水) 21:40:11.05

そんなん設計でどうにでもなる
ありきたりの道具使ってばっかいるからアタマが退化してんだろ

**デフォルトの名無しさん** · 2022/08/17(水) 21:41:54.05

>shared_ptrを使わざるを得ず
おまえがそう決め付けているだけで、ここら辺は設計でどうにでもなる

**デフォルトの名無しさん** · 2022/08/17(水) 21:46:20.33

>>545
unique_ptrはコピーできないから複数の参照を用意できない
shared_ptrを使うことになる

**デフォルトの名無しさん** · 2022/08/17(水) 21:51:11.86

同じクラスが重複して定義されたとき、
そのクラスに変数が定義されていてもコンパイルエラーにならないのはなぜですか？
関数が定義されている場合、インライン展開されないとコンパイルエラーになると思います
変数にはそのような指定が無いと思いますが、なぜエラーにならないのでしょうか？

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

言っている意味がちょっとわからないので最小のコードを提示してもらえるとありがたい

**デフォルトの名無しさん** · 2022/08/17(水) 22:09:46.76

単純に、同じクラスを（同じ定義で）二回定義してもエラーにならんの
便利なようで不思議だよな

**デフォルトの名無しさん** · 2022/08/17(水) 22:10:56.50

>>542 「複数の参照」が借用で済むようなものなら C++ でも T& でコスト要らなくね？

**デフォルトの名無しさん** · 2022/08/17(水) 22:12:24.01

大抵インクルードガードで１回しか通らないようにしてたけど
（クラス定義だけなら）インクルードガードなしで二重に読んでも通るってことなのか…　それはしらんかった

**デフォルトの名無しさん** · 2022/08/17(水) 22:14:06.17

スレタイ読めや
だからRust信者は嫌なんだよ

**デフォルトの名無しさん** · 2022/08/17(水) 22:17:02.42

>>550
それはダングリングポインタになりうるからダメ
C++には借用とライフタイムの概念がないため先に解放されてしまう事態を避けられない

**デフォルトの名無しさん** · 2022/08/17(水) 22:35:58.47

以下のコードをヘッダに記述して複数のソースでインクルードすると、
関数fooは重複定義でコンパイルエラーになります
inline指定にすると、コンパイルは通るようになります

class myClass {
public:
void foo();
int i;
};

void myClass::foo() {
std::cout << "OK";
}

このとき変数iは何故重複定義にならないのでしょうか？
fooと同様に複数のソースで重複定義になる気がするのですが