C++相談室 part138

**デフォルトの名無しさん** (ｽﾌｯ Sd9f-fGne) · 2018/08/05(日) 18:02:36.57

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part137
http://mevius.5ch.net/test/read.cgi/tech/1531558382/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1530384293/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2019/09/25(水) 00:41:02.91

Ruby は、デザインパターン・疎結合の宝庫！

is-a/has-a, Duck Typing, Page Object, Test Double(依存性の注入), TDD/BDD(RSpec)など

2019/09/25(水) 08:48:48.39

ruby書いてる奴、言うほどまともにテストしてねーじゃん。

2019/09/25(水) 10:44:33.62

>>396
>なおC++はクラス単位でしか継承出来なくてその辺不便だが、
>JavaScriptは関数単位で継承出来る。
具体的に詳しく紹介してもらえませんか。

2019/09/25(水) 12:00:37.34

プロトタイプのことだろう
継承とは言わない

2019/09/25(水) 12:37:26.12

あれ？　こいつインターフェイス知らねえの？ｗ

2019/09/25(水) 13:48:34.57

あーでもこれあれだな
長文はキモイな、やっぱ
OOは整理整頓術ってのはその通りだけど、長々と書かずにそれだけ書き込めばよい
あとは、プログラムにはデータ構造と制御構造の二つがあるんだけど
この別々のものを一纏めにするのがOOの悲劇の始まり、ってのを教えといてあげればよい
この辺ベテランでも割とモゴモゴする

2019/09/25(水) 14:02:26.76

データ構造と制御構造を対応づけようなんて話は
ジャクソン法やワーニエ法、つまり構造化プログラミングの時代に
もう出てきてた話なんだが

2019/09/25(水) 14:32:32.56

それを構文で取り入れたのがOO

2019/09/25(水) 14:43:06.95

結局、「作る側（実装）」と「使う側（関数を呼び出す側）」を分けて、
前者を後者から隠すという事が class の概念の最も重要な部分で、
それによってさまざまなメリットを受けられる。
「オブジェクト指向」という概念は、実は、それとはかなり違うもので、
参考にするのはいいがそっちを重視しすぎるとそれはそれで問題を来たす
気がする。

2019/09/25(水) 14:57:19.16

メッセージングがどうとかの話だと思うけど
あれは確かにC++では忘れた方がいいだろうね(そういう風にわざと実装する場合はともかく)
Objective-Cなんかだと言語レベルでメッセージ送る形になってるけど

2019/09/25(水) 15:06:40.03

メッセージと名が付いてるから送り合ってるように見えるだけ
スレッド分けすらされてないシロモノ

2019/09/25(水) 16:57:24.56

>>406
ん？
>>405 は、「カプセル化」と呼ばれる考え方で、メッセージとは
直接関係ない。

2019/09/25(水) 17:01:27.68

classが入って便利になったもう1つのことと言えば、同じ種類のオブジェクトを
簡単にいくつでも作れるようになったこと。pure Cのグローバル変数と
ローカル変数だけを使ってそのようなことをしようとするとなかなか大変だったが、
C++ の場合、new CMissile のようにするだけで、ミサイルがいくつでも
追加できて、しかも、それぞれの位置や速度などがオブジェクト・インスタンス
の中にきっちり分けて入ってくれるのでとても便利。

2019/09/25(水) 17:04:42.69

いやすまん、C++のクラスがいわゆる本来のオブジェクト指向には沿ってないって話だと思って
メッセージングなんかには全く沿ってないよねと言いたかっただけw
他にも色々あるんだろうけど、C++のクラスと本来のOOとは切り分けた方がいいのは同意

2019/09/25(水) 20:02:30.30

オブジェクト指向にこだわるよりかはSOLIDにこだわる方がまだまともだわ。
あんな用語にこだわらなくてもできてるやつはできてるし、
理解しないでこだわる奴は糞押し付け始めるし害悪でしかない。

2019/09/25(水) 20:20:38.86

SOLIDよりYAGNIだな
オブジェクト脳のやつはありもしない拡張性を考えて無駄に複雑にする
それif分岐で十分だから

2019/09/25(水) 20:54:49.21

>>404
で、ベテランがモゴモゴって何のことだ？

2019/09/25(水) 22:33:49.67

OOPにおけるSOLIDという言葉は初めて聞いたけど、何を言ってるのかよく分から
ない部分が多くて、すぐには理解できそうに無い。

2019/09/26(木) 06:40:00.74

>>398
言語設計者が一時期ソースコード＝仕様書、という思想を公言していた記憶
ソースコードにはバグも含めて全てか書かれている（のだからその存在自体が正しいい
、みたいな

2019/09/26(木) 06:41:14.19

OOは継承と多態性のしくみに夢を抱きすぎた
継承は当初差分プログラミングによる省力化がやたらと喧伝されたが、
多くの人がやったら効果など無く混沌が広がるだけだったので
結局>>402な見解に戦線が縮小して現代に至る

データ構造と制御構造（振る舞い）を(オブジェクトの名前).(メソッドの名前)という
単純な表記で呼び出せるように一緒くたにあえてまとめたために、
テンプレートによるメタプログラミングの道が開けた
結果さらなる破壊と混乱がもたらされた

2019/09/26(木) 07:10:46.20

バカが使うと混乱して仕組みが良くないとわめき出す
って言ういつもの流れw

2019/09/26(木) 08:46:10.69

何回言っても言い過ぎでないくらいまた馬鹿が出てくるからな。

2019/09/26(木) 11:18:51.43

OOの根本的な思想的な問題点は凝り固まったカプセル化の考え方にあるかもしれない
カプセル化って自分の仕事しかしない頭の悪いアスペみたいな存在で
そんなのだけが寄せ集まっても集団として何もできないという
人間でも同じでアスペだけの会社なんて無理だろうに
電気回路でも電子部品はコンポーネントかもしれないけど回路が無いと動かない
回路はどこに書くんだっていうね
だからC++はマルチパラダイム言語になってて
無論OOもあるが、非OOな部分が存在することも許容している
1+1は1に"+1"というメッセージを送る、とか解釈するどこかのアホの言語とは違う

2019/09/26(木) 11:21:52.79

これはあくまで思想的な話で、ものすごく大まかに言えばOOは左翼的な思想に属してて
本当にこれでよいのか？という疑問は常に付きまとう
こんなものを使っていると頭がおかしくなるんじゃないかという
実際プログラマは精神病になりやすいイメージがあるし
OOに染まったプログラマの言うことは回りくどくて聞いてられない
実際頭おかしいでしょ

2019/09/26(木) 12:51:41.19

すっこんでろ

2019/09/26(木) 14:06:22.33

https://ideone.com/pMPcFp
これはOOといえるか？
ベースコード80行も書いてるのに、メインロジック一つもないわ。

2019/09/26(木) 17:00:36.25

まぁ部品作るのには向いてると思うよOOは
ただ、部品なんてものは会社で言えば非正社員みたいなもので
そんなところに注力してもな
大事なのはそこじゃないからな
簡単なことをより簡単に出来るようにして
それ以外の難しいことに集中できるのがOOの利点か

2019/09/26(木) 18:55:11.69

>>423
カプセル化してユーティリティ作るにはクラス構造はかなり良い。

2019/09/26(木) 21:06:32.34

クラス分けはやっぱりデザインパターン見とけって感じなのね
どういうときに使えば便利かってのがいまだによくわからんのよなぁ

2019/09/26(木) 22:35:47.43

>>425
デザインパターンはゴミ。
ところでお前は何万行のコードを書いていてクラス分けが分からないの？

知りもしないのに嘘情報を垂れ流すのは止めろ。何の得にもならない。
お前はデザインパターンの有効性を判定出来るレベルではないだろ。
なら、その点については黙っておけ。
結果的に、お前らが知ったかぶりで嘘情報を流すからお前ら自身が迷惑を被るループになってる。
いい加減これに気づいてわきまえろ。

2019/09/27(金) 11:53:00.94

>>デザインパターンはゴミ。
同意はするが

>知りもしないのに嘘情報を垂れ流すのは止めろ。何の得にもならない。
>お前はデザインパターンの有効性を判定出来るレベルではないだろ。
>なら、その点については黙っておけ。
>結果的に、お前らが知ったかぶりで嘘

ここまで言うならお前がクソ言う理由も書くべき

2019/09/27(金) 18:46:28.25

>>427
何についてだ？
425についてなら、糞だと自明でないお前も糞でしかないだろ。
むしろお前が425みたいなゴミを擁護する価値があると認めた理由を先に聞こうか。
それが妥当と判断したら、俺が425がゴミな理由を述べてやる。それでフェアだろ。

2019/09/27(金) 21:02:00.04

>クラス分けはやっぱりデザインパターン見とけって感じなのね
>どういうときに使えば便利かってのがいまだによくわからんのよなぁ
さすがにこれだけ読んでこいつがデザインパターンを過剰に持ち上げてるとは
ふつう思わんだろ。
普通に考えればよくわからんやつがよくわからんがやってみるかって言ってるだけの文章だろ。

2019/09/27(金) 21:35:59.08

>>429
そもそもデザインパターンはクラス分けについての話ではない。
よって425は知らない癖にそれがさも「クラス分けに役立つ」と取れるような嘘情報を述べている。
もっとも、本人が積極的に嘘をついていると言うよりは、
過去誰かが425と同じようなことを書いたのを読んでいて、それを再度垂れ流しただけだと思うが、
それが425自身も既に嘘情報の垂れ流しループに組み込まれている証明となっている。
そして結果、自身も勘違いさせられ、また、勘違いした馬鹿を再生産して行っているわけだ。
そんなことは止めろ、と言っている。

過剰に持ち上げている事を咎めているのではない。
（というよりそもそも俺は過剰に持ち上げているとは捉えていない）
（結果的であれ、回避出来る）嘘情報を垂れ流すな、と言っている。

クラス分けについては、分からないのではなく、クラス分けが必要になる規模のコードを書いたことがないだけだ。
初心者は全員これだ。だから何度も規模を聞いている。
10行しか書けないのにクラス分けなんて分かるわけがない。全く必要ないからだ。
逆に、10,000行フラットに転がしてみろ。いやでもクラス分けが分かるようになる。

ただ最近の傾向として、425みたいな奴は増えている。
これは単純に、「ネットに書く」ということに関して前世代よりは若者世代の方が抵抗がないからだ。
だから知りもしないことをボソッとつぶやいたりしてしまう。そして本人に悪気があるわけでもない。
ただ、それでも間違った情報が拡散され、結果、それを読んだ奴が被害被るのもまた事実だ。
だから、知りもしない事柄についてはもうちょっと慎重に書け、ということでしかない。
同じ事はDeNAのキュレーションサイトでも起こったろ。
医者がうんちくや意見を（それなりに注意しながら）語るのはいいが、
医療知識が全くない奴がそれをコピペして適当に編集するからおかしな事になる。だから禁止された。
https://www.itmedia.co.jp/news/articles/1703/13/news114.html
同様に、プログラミングについての知識がない/まだまだ初心者の奴が知ったかぶって書くな、ということだ。
そして結果的にお前ら自身が被害を被っていることにも気づけ、ということ。

2019/09/27(金) 21:36:17.08

何度も言っているが、OOPは初心者が分かるものではないし、分かるべき物でもない。
それは単に、大規模コードを扱ったことがないからだ。
だから、その程度の奴らがOOPに対して何か書くこと自体が不適切なんだよ。
>>402みたいな糞も含めてな。理解出来てないのなら語るな、でしかない。

2019/09/27(金) 22:25:57.89

>10行しか書けないのにクラス分けなんて分かるわけがない。全く必要ないからだ。
>逆に、10,000行フラットに転がしてみろ。いやでもクラス分けが分かるようになる。
これはまったくその通りだとは思うが、しかしその機会のない連中が
とりあえずデザインパターンやってみっかってのがそんな悪いこととも思わんがな。
過剰な反応に思う。
医療問題のような致命的な問題がデザインパターンやることで生じるとは思わん。
確かにデザインパターン魔がシングルトン振り回してグダグダにしてったという歴史はあるが
そういうアンチパターンも最近は紹介されとる。
それでもカスな知識を振り回す輩は結局何やってもカスなことをやる。

2019/09/27(金) 22:28:30.87

>>427
> >>デザインパターンはゴミ。
> 同意はするが
同意するならその理由を書けって言われてるだけ
まあ書けないからグダグダ中身のない長文でごまかそうと必死なんだろうけどw

2019/09/27(金) 23:03:44.15

>>432
> しかしその機会のない連中が
だからこれがナンセンスだと言ってるんだよ。

OOPは大規模コードの整理術なのだから、
コードが大規模になったときにやればいいのであって、
逆に、大規模になったら、やる以外の選択肢はないんだよ。
(OOP文法を使うかどうかは別だが、「分割」はやるしかない。だからみんなやってる)

逆に、コードが精々500行程度、
つまり一般的なスクリプトの用途なら、OOPなんて一生必要ない。
だから知る必要もないし、また、この規模で適切に学ぶ方法もない。
つまり初心者レベルだとどうあがいても空回りする。

だから俺はグダグダ言わずにコードを書け、と言っている。
それがOOPが有効に機能する規模になれば、
余程馬鹿でない限り、自然に分かるようになる。それだけだ。

それはさておき、お前がサポートしたいのなら勝手にやればいい。
お前がデザインパターンを極めているつもりなら、422に講評つけてやれよ。
俺はお前らとは違う評価を付けている自信があるから、後出ししてやる。
もし俺と同じ評価をしている奴がいて、俺が何も言うことが無くなれば、俺の負けでいい。
（なお一応言っておくが、俺が賢いからではなく、
お前らが馬鹿（＝下手)だから俺と同じ評価を付けられないだろう、と見ている。
つまり俺はお前らを技術的には数段下だと見ている。それを「負け」たら見直す、ということ。）
我こそは、と思う奴は422に講評付けてみろ。
俺を伸したがっている馬鹿共もかかって来いよ。チャンスだぜ。

2019/09/27(金) 23:55:19.48

72行程度の長文でさえしどろもどろなアホが
何がOOPの必要性だｗ

2019/09/28(土) 00:07:57.26

デザインパターンは掃き溜めの鶴ではないか
何を言っているんだ

2019/09/28(土) 00:19:01.32

>>419
左様アスペを組織するにはタイピング量が半端無いことになりがち
アランケイが豪語したようなステップ数の削減は常人がOOPしたらまるで逆になる

>>417>>419
バカでも安全にプログラミングができるようにする、というのがソフトウェアー工学の主要なお題目
だっ
たはず

2019/09/28(土) 00:21:20.58

目的が不明なコードに講評だってさ

2019/09/28(土) 00:51:32.95

一応言っておくと、24時間は待つ。
状況によってはこの土日全部＝48時間待ってもいい。
イキってるだけの馬鹿共はいい機会だから講評付けてみろ。
匿名なんだから失う物はないだろ。それが匿名掲示板の良さだ。

イキるだけだからお前らは馬鹿なままなんだよ。
イキる元気さをちゃんとプラスの方向に転化しろ。
イキっているのにここで参戦しないのはチキン過ぎるぜ。

デザインパターンを「言葉で」擁護するのではなく、「コードで」擁護してみせろ。
つまり、デザインパターンを極めたお前だからこそ書ける素晴らしいコードを提示し、
俺みたいにデザインパターンを馬鹿にしている奴との差を見せつけてみせろ。

>>438
ぼくはあのこーどがなにをするのかさっぱりわかりません、か。
はい、お前は負け決定。
そのレベルでイキってるからお前は馬鹿のままなんだよ。少しは自覚しろ。

2019/09/28(土) 01:24:50.38

422ってメッセージパッシングをやりたいような気がするけど
それってOO設計じゃなくてOO自身の設計じゃん
スレの流れ的にそういう趣旨でいいんだっけ？w
とにかく >>439 の講評が楽しみだわ

2019/09/28(土) 01:28:35.64

イキってるって言いたいだけやん…
てか本人が一番イキってるしw

2019/09/28(土) 05:58:28.49

>>439
匿名掲示板で失うものと言えば、時間だな。
持論垂れ流して気持ち良くなってるだけの相手に議論しても、得るものはない。

2019/09/28(土) 07:59:27.08

酔っ払いの独り言は誰も面白いと思っていない
駅前で不特定多数を叱り飛ばしている危ないオヤジと同じだ

2019/09/28(土) 10:11:46.22

>>419
それは一理ある。実際、
自分の場合、1つのアプリの場合、ほとんどのclass メンバをpublicにしてる
場合がある。
しかし、class 分けすることで new CXxxx としただけで同じ種類のオブジェクトが
簡単に作成できる事や、似た働きを基礎に持っているが、基礎を発展させた応用的な
オブジェクトや同じ系統だが少しずつ働きの違うオブジェクトを、共通の基礎部分を
CBase クラスで書いておいて、それを継承したクラスで書ける事が便利になる。

だから、内部データにはアクセス禁止という意味でのカプセル化は達成したくても
なかなか達成できない事があるが、上記の様な意味で便利に使えてる。

2019/09/28(土) 10:16:07.55

>>435
それは思う。

2019/09/28(土) 10:22:21.06

>>444
補足しておくと、protected に出来るメンバはできるだけ protectedにしている。
例えば、ポインタで保持している何らかのデータなどは、ちょっとしたことで
間違って削除してしまう可能性があるので、そこにデータを書いたり、
ポインタが指す先を付け替えたりする関数は出来る限り protected にしてる。
そして、それはなるべく基本クラスの方にくくり出す。もし、別の関数でも
これと同じような処理が必要になったら、既にある関数を組み合わせてなんとか
ならないかを考える。そうすることで、ポインタのつけ間違いや誤ったオブジェクトの
削除を防ぐことが出来る。

ポインタ以外でも、データの整合性に関して慎重さが必要な場合は、上記と
同じようなことをやっている。

2019/09/28(土) 11:00:36.13

>>444
structで良いじゃん

2019/09/28(土) 11:38:05.06

>>447
純粋な構造体なら struct にして、名称も TXxxx にしている。
一方、メンバ関数があるものについては、原則的に必ず classにしている。
理由は、クラス定義を grep 検索する祭、必ず class CXxxx をキーワード
にすればよくなるから。これがもし、一部でも struct CXxxx というものが
混じっているなら class CXxxx では見落としてしまうことになる。
型名の頭文字が T の場合は、struct TXxxx と検索する。

2019/09/28(土) 11:40:37.11

>>448
それから、その時はたまたま public: 属性ばかりなだけで、
後から protected: 属性のメンバもできてくる可能性も有るから、
純粋なデータ構造体以外は、必ず class に統一することにしている。

2019/09/28(土) 11:50:17.24

システムハンガリアンにしがみついてる化石ｗ

2019/09/28(土) 12:22:40.96

MSVCはstructとclassの扱いが違う糞

2019/09/28(土) 14:13:38.93

>>451
どう違う？

2019/09/28(土) 14:15:56.72

宣言と定義で変えたらlink出来ない

2019/09/28(土) 14:23:25.73

んなことするやつこそ糞だと思うが

2019/09/28(土) 14:31:07.26

コンパイラによる解釈の違いを「そうきたか」と微笑みつつ解決するも楽しいものだよ。

2019/09/28(土) 14:50:38.12

>>453
デフォルトのアクセス修飾子違うんだから当たり前じゃないのそれ

2019/09/28(土) 15:09:19.89

>>456
そういえばそうだね。

2019/09/28(土) 15:18:29.76

>>456
宣言にデフォルトのアクセス修飾子関係ないだろ

2019/09/28(土) 15:27:08.75

>>458
一見そう思うかもしれないが、
class/struct の完全定義で、public: や protected: などを全く書かずにいきなり最初の
部分に書いたメンバに対しては関係ある。
本来の設計では class Aaaa だったのに、使う人が struct Aaaa で宣言してしまうと
Aaaa の完全定義の最初の部分に書いたメンバは、本来は private 属性で禁止されていた
はずなのに、使う側ではアクセスできてしまうことになる。

2019/09/28(土) 15:35:18.31

>>453が言っているのは異なるコンパイル単位で別の定義を使うという話じゃなくて宣言と定義だろ？

2019/09/28(土) 16:05:06.02

こういうケースの話だとは思うけど
struct A;
class A
{
int a;
};

コンパイラがどう解釈するかは決まってるのかなこれ

2019/09/28(土) 16:07:59.85

エラー出すんじゃないの？

2019/09/28(土) 16:38:02.11

c++17のfilesystemで、windowsの「マイドキュメント」とか展開するときってどうやるん？
自分は、日和ってWindowsの関数使ったんだけど。

2019/09/28(土) 17:06:13.76

>>459
リンクって何やる処理かご存知？

2019/09/28(土) 18:27:19.82

C++のclassとstructの違いはデフォルトのアクセス権が、
class : private
struct : public
ということでしかなくて、アクセス権を追加するのは両方できる。
さらに継承もできる。

2019/09/28(土) 18:44:36.11

継承の時デフォルトがpublicかprivateかもあったような？

2019/09/28(土) 18:50:19.34

>>466
それは、クラスはprivateで、構造体はpublicで継承されたと思う。基本値として。

2019/09/28(土) 18:53:35.09

>>461
決まっている
規格上は宣言時structだろうがclassだろうが完全に同じ扱い

msvcは同一コンパイル単位では警告出してくるし、別れているとマングリングが変わるせいで引数にポインタや参照が含まれる関数などがある場合、linkが出来なくなる

2019/09/28(土) 19:44:13.97

classで宣言したものを、
わざわざstructで定義する必要性って
どんな時に出てくるんだ？

関数の仮引数を[]で宣言して
わざわざ*で定義する必要性なら
まあ出てくることもあるが

2019/09/28(土) 19:51:09.64

>>469
規格知ってる俺スゲーしたいときだろ。
話聞く限りVCの方がまともで、C++の仕様もそちらに合わせるべきだと思うが。

2019/09/28(土) 20:23:29.91

アンチMSにとっては挙動が他と少しでも違えば気に入らないんだろうさ

2019/09/28(土) 21:37:11.39

>>464
「>>459」のようなことが間違って起きないようにするためにリンク段階でリンカ
が気付くように、わざと *.obj, *.lib ファイルレベルでのマングリング名
を struct と class で変えてるのではないか。

2019/09/28(土) 21:47:31.84

>>472
そんなことが起こるわけ無いだろ
宣言だけで出来るのは中身関係ないポインタや参照の受け渡し

まあstd::hashやstd::allocatorの特殊化してみればいい

2019/09/28(土) 22:00:22.50

>>473
そういう問題ではなくて、
静的言語のメリットは、プログラマの明確な間違い＝タイポや型違いをコンパイル時に落とせる事でもあるだろ。
structとclassを間違えているのならコンパイルエラーにすべき、というのがお前以外の他全員だと思うが。

そういうどうでもいいところにこだわりすぎてるから上達してないのだと思うぞ。

2019/09/28(土) 22:02:55.72

勝手に総意を語らないでください。

structとclassは同じ文脈で使われることもそれなりにあるので、
どう判断したら文脈的に正しいと思いますか？

2019/09/28(土) 22:12:35.78

>>475
まあお前の意見が違うのは分かった。
普通の人は、VCの動作で全く問題ないと思うが。
実際誰も擁護もしないし、必要性もないだろ。
逆にstructとclassを混ぜてる糞ソースでドヤア出来る感覚は頭おかしいと思うが。

2019/09/28(土) 22:23:14.45

間違いで起きるかそれ？
それが起きるとしたら、同名だけど中身が全く違うものをincludeしてる状態だろ
class/sturctの違いだけ気づけてもありがたみない

2019/09/28(土) 22:34:45.68

>>477
間違いではなくて、
書いてる本人が同じ物にstructとclassを混ぜて使っており、
その本人がそれでいいと思っているケースだろ。
少なくとも ID:X/zAGzhO0 と ID:E6lKnilk0 はそうなんだろ。

> 同名だけど中身が全く違うものをincludeしてる状態
これはほぼ間違いなくコンパイルエラーで落ちるから、それで問題ないと思うが。

2019/09/28(土) 22:44:30.75

警告出されないほうが困る事のが多そうだけどな
どっちで定義するつもりだったのかわからんもん

2019/09/28(土) 22:49:07.22

C++では、constが付いているかいないかでも、関数のmangling名が
違うので、リンク段階でエラーが出る。
こっちのエラーも余り深く考えたことが無いけれど、似たような意味で
structとclassが違っていればリンク段階でエラーになるようになっている
気がする。つまり、const属性の違いの混乱が起きていてもエラーになるが、
似たような意味でアクセス属性の違いでもエラーになるようになっている。

普通、ライブラリに対応するヘッダファイルを正しく #include していれば、
このような現象は生じないが、新しく追加された関数のプロトタイプ宣言が
無い場合に自分で、ネットにあったプロトタイプ宣言をコピーしてきたような
場合にconst属性の違いが生じることがあるかも。
それと同様に、自分で作ってるアプリの *.cpp と *.h で、勘違いして
class型の完全定義をstruct型で不完全定義してしまっているとか。
そういうのは中身まで間違っていることもあるので、リンク段階でエラーになった
方が、原因不明のエラーを防ぐのに有効だと思われる。

2019/09/28(土) 22:50:49.47

structとclassで多重定義できるべきとでも言いたいのか？

2019/09/28(土) 22:51:32.96

コードスメル的な問題はあるとしても実害は考えられないのでは？

2019/09/28(土) 22:54:02.47

で、VCの仕様で助かった経験のある人いんの？

class/structの違いは単なる表面的なsyntaxの違いでしかないと理解するのは自然
それが実はバイナリに影響してるってのはいらぬ驚き
という主張はおれはわかる

別にVCの仕様がおかしいとは言わないが何か防御に役立つとは思えない

2019/09/28(土) 22:57:28.76

>>482
>>459

2019/09/28(土) 22:59:07.82

自分のポリシーとしては、
構造体は変数のブロック用程度にしか考えないし、ユーティリティ作るときはclass使う。

だから、構造体使うときは、アラインとか気を使う。クラスはどうでもいい。

2019/09/28(土) 23:00:07.72

>>483
むしろお前は混ぜていい仕様で助かっているのか？

2019/09/28(土) 23:00:21.59

本来privateであるべきところがpublicになっててアクセスできるのは起こり得るんじゃないの

>>483
混ぜる必要がないし混ざらないほうがいいと思うけど
まず宣言と定義でごっちゃになることがないから実害食らったひとはいなさそうだけど

2019/09/28(土) 23:02:53.00

>>486
ニホンゴワカリマスカ？

2019/09/28(土) 23:03:40.64

>>459
こそ勘違いの最足るものだろうに
structとclassは定義時のデフォルトがpublicになるか否か以外言語仕様上違いが無いんだよ
struct A;
class A;
どちらもクラスAの宣言

2019/09/28(土) 23:03:45.92

>>484
だからさ、class Aaaaとstruct Aaaaの2つの別々の宣言(前方宣言じゃない)があって、
メンバのアクセス修飾子だけが違うってどういう状況なんだよ
間違いで起こるかそれ？

2019/09/28(土) 23:08:03.45

前方宣言でclassとstructを変えることによるメリットは？

2019/09/28(土) 23:08:10.20

こんな糞議論しなきゃならん時点で有害だわ

2019/09/28(土) 23:11:12.80

むしろ合わせなきゃいけない意味がわからん
他人のカスタマイズ用のtemplate classでそれがclassだったかstructだったかを正しく覚えてなきゃいけないとか

2019/09/28(土) 23:15:06.74

使うだけならclassかstructか書く必要ないし修正を加えるなら必然的にソースコード見るだろ

2019/09/28(土) 23:20:24.74

いやだから特殊化するときだって

2019/09/28(土) 23:39:09.23

Aaaa を完全定義をする前に Aaaa 型へのポインタを宣言したい場合に不完全定義として
struct Aaaa;
としておき、後から完全定義として
class Aaaa {
　　int　　　data1;　　// class なのでデフォルトのアクセス属性は private 属性。
　　・・・
};
を与えた時、struct と class の違いでエラーにするかどうかの議論ですね。
そして、完全定義したときにだけしか、デフォルトのアクセス制御の public/private の違いは
出てこないので、エラーにする必要が特に無い、という説が出てきていると。