C++相談室 part133

2017/11/24(金) 16:52:50.43

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

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

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

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

■長いソースを貼るときはここへ。■
　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

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

2017/12/08(金) 23:52:39.34

そんな糞みたいなgetter書くくらいならpublic変数にしたほうがまし

2017/12/09(土) 00:00:04.12

>>360
5chは初めてか？
ちょっと肩の力抜けよ

2017/12/09(土) 00:06:55.18

プロパティー使いたいならエンバカ

2017/12/09(土) 00:30:19.70

そもそもプロパティをそのまま露出すんなって

2017/12/09(土) 00:37:11.06

hage.sizeof みたいな書き方があってもいいけど、別になくてもいいからな
話は上がっているんだろうけど、優先順位はかなり低いと思うね

2017/12/09(土) 00:48:53.78

>>366
constバージョンだけでよくない？
何で内部状態を他人に書き換え許可するのさ。

2017/12/09(土) 02:05:41.93

>>368
>>359に言え

2017/12/09(土) 08:40:17.40

夜中まで粘着 w

2017/12/09(土) 11:10:57.47

>>367
>>366のgetter/setterの中身はあくまでサンプルなのでは…

>>373
いちいちメソッド呼び出しの度に状態を引数渡しするほうが内部状態の露出として醜悪かもしれん…

つかデータメンバの書き換えはデータメンバの書き換えだからNGというものではなくて、
内部状態の整合性が保たれれば何だって良いんじゃ…
データメンバ直書き換えでなくsetterなら整合性をチェックしたり与えたりするチャンスがある
（あるいは排他制御とかやることもある…まあ慎重に考えたらsetterでやるよりロック回数が少ない方法がたいてい見つかるが、

2017/12/09(土) 11:13:16.09

アンカーミスった、
誤： >>373
正： >>372

2017/12/09(土) 12:28:24.94

>>366 の実装はサンプルにしてもありえないだろう。
一度呼ばれて参照を保存されたら、変更を制御できなくなる。

int& status = a.Status();
status = 2;

2017/12/09(土) 13:28:08.16

>>377
それな。
中身だけでなく外見(インターフェース)も糞。かつそのインターフェースなら例外なく中身も糞になる

2017/12/09(土) 13:40:30.88

ここでgetter/setter言ってるのは例外なくどうしようもない低能だから無視してあげて下さい

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdbf-n3/l) · 2017/12/09(土) 14:04:38.96

int mydata() const; // getter
void mydata(int data); // setter

こういう感じの下駄瀬田は道南？

2017/12/09(土) 14:29:29.91

>>366のgetterの&を見落としていたorz
m_dataへのmutableなポインタを返すのではm_dataのgetterとは言えぬ

2017/12/09(土) 16:16:46.64

メンバ変数hogeにgetHoge,setHogeなんて名前の下駄雪駄を
機械的に作ろうとしてる事自体が間違いの可能性を考えろ

class Window
{
　int width, height;
　...
　
　//まちがい
　int getWidth() const;
　int getHeight() const;
　void setWidth(int w);
　void setHeight(int h);

　//せいかい
　Size getCurrentFrameSize() const;
　void resize(int width, int height);
};

2017/12/09(土) 16:31:11.01

>>382
>>320は、Ｃ＃の機能があると便利ですねー。セッター/ゲッターが毎回定義するの？っていうお題じゃねーの？
どっからWindowやら、Sizeが出てきた？

2017/12/09(土) 16:38:09.40

クラス内部状態の変更は意味のある操作単位として外部に公開すべきであって
むやみに内部の変数を下駄雪駄として露出すんなっていうつもりだったんだが難しかったかな？

2017/12/09(土) 16:56:33.96

>>384
そんな分かりきったことを議論することではないだろ。
C++の規格が新しくなってsetter/getterは従来道理なの？が質問。
set/getするときは、直の変数の読み書きの代用だけではななく、何かの処理をしたりして公開/制限付き公開するものじゃねーの？

2017/12/09(土) 17:16:31.79

>>383
だからプロパティ単体で読み書きするのが常に正しい訳じゃないでしょってこと

> どっからWindowやら、Sizeが出てきた？
一例だってことわからないの？

2017/12/09(土) 17:25:01.50

>>385
従来通りだよ。
何がしたいのかはっきりさせないからこうなるんだよ。
メンバーへの代入のような記述でメンバー関数呼び出ししたいということか？

2017/12/09(土) 18:54:12.14

昔どっかで下駄雪駄をクラスにして公開する方法が書いてあったな。
面白そうだったけと使おうとした事はなかった。

2017/12/09(土) 19:16:55.95

単にデータメンバー指定したらgetter setter相当のメンバー関数を自動生成するような機能が欲しいというなら他のやつが言うように思考停止したバカしか欲しがらない機能
EなんとかとかいうIDEには付いてるらしいが

2017/12/09(土) 20:17:03.24

理想はわかるけど、ある程度の規模のコードを書けば何だかんだでsetter/getterはけっこう書くだろ

2017/12/09(土) 20:17:55.36

.netのPropertyは実際のオブジェクトがバッキングフィールドってとこに完全隠蔽されることがメリット
C++では自動実装は不可能、同じ効果を得るならばpimplパターンでオブジェクトを隠蔽は可というのが答えではないだろうか

2017/12/09(土) 20:18:50.11

>>390
getterはともかくsetterは書かない

2017/12/09(土) 20:26:30.08

setter/getter批判論者は何を批判しているのかいまいちわからん…
class SomeWidget { // GUIのパーツか何か
　Color m_FgColor; // 前景色
　Color m_BgColor; // 背景色
　...
};
とゆークラスがあったとして、
　void SomeWidget::setFgColor(Color color) { m_FgColor = color; }
　void SomeWidget::setBgColor(Color color) { m_BgColor = color; }
というのはsetterだからﾀﾞﾒで、意味的にまとまりのある
　void SomeWidget::setColor(Color fgColor, Color bgColor) { m_FgColor = color; m_BgColor = color; }
とかにしないとﾀﾞﾒだとかそーいう主張？

ｽｹﾞｰいらんお世話な気が…

2017/12/09(土) 20:43:02.98

setter/getter自体を批判してんじゃなくて
自動生成をC++に求めるのを間違いだと言ってるだけだと思うが

2017/12/09(土) 21:05:37.85

>>393
> 　void SomeWidget::setColor(Color fgColor, Color bgColor) { m_FgColor = color; m_BgColor = color; }
> とかにしないとﾀﾞﾒ
それを意味的にまとまりがあると考えるお前がおかしい
だからそんな頓珍漢なレスになるんだよ

2017/12/09(土) 21:10:02.77

クラスにメンバーがいっぱい→それぞれの下駄雪駄をいっぱい作らなきゃ！→楽な書き方ないの？

っていう発想から抜け出せてないんだろうけど
この最初の矢印がそもそも間違いだって言ってんだよ
まずはどんな操作をpublicで公開すべきなのかちゃんと設計しろ、話はそれからだ
結果的にただのgetterとsetterとして実装されるものはもちろんあるだろうし、それが悪いわけじゃないけど、
そんなのが自動生成しなきゃ追いつかないほど大量に出てくるようなら一回設計を疑うべきだ

2017/12/09(土) 21:10:22.08

内部のデータメンバーからインターフェースを作るのではなく、インターフェースから内部実装を書くという当たり前の事を言ってるだけ。

2017/12/09(土) 21:14:57.20

>>392
あんたすげーな

2017/12/09(土) 21:17:58.04

これC++に限った話じゃないからね。これが理解出来ないようだったら自分のソフトウェアの設計能力はとてつもなく低いと自覚した方がいい

2017/12/09(土) 23:03:23.79

>>393
なんでコンストラクタで初期化しないの？

**320酔っ払い** (ﾜｯﾁｮｲ b7e3-qmOZ) · 2017/12/09(土) 23:18:04.72

正直聞きたい事はそういうことじゃねーのよ
簡単に記述する方法が導入された、される予定があるか知りたいだけ

C++にC#みたいなproperty要望無いの？
const地獄解は消されたのかな？
ってこれ！

具出すなは分かる>>377の言う通り例が悪かった
APIや世界に発信するライブライ作ってる訳じゃないけど
>>382これが普通なの？俺別にpublicゆーてないけど
protectedでもこんなまわりくどい事すんの？

そもそも設計が…言う前に”そんな方法は無い！”って言ってくれたら…
つーか言えっつーのお願いマイメロディー

2017/12/09(土) 23:20:31.63

>>401
プロパティの言語サポートはない。
が、がんばればそれっぽいものをライブラリで作ることはできる。

2017/12/09(土) 23:21:13.23

>>401
VC++になら最初からpropertyはあるし使えるが。

2017/12/09(土) 23:23:36.06

>>400
mutableなオブジェクトとして書きたい（ときもある）から

2017/12/09(土) 23:26:04.82

>>403
それ、独自拡張かなんかでしょ？

2017/12/09(土) 23:27:21.61

プロパティ厨しつこい
C#使ってろよ
public変数使う言い訳探してんじゃねえよ

2017/12/09(土) 23:30:23.37

>>405
もち

**320** (ﾜｯﾁｮｲ b7e3-qmOZ) · 2017/12/09(土) 23:30:53.06

>>402
手間掛けたくないのであればなーって
自作出来ても汎用性無いでしょ。汎用性関係あるプログラムじゃないけど

>>403VC独自拡張？知らんかった
それが標準になりそうなら憶える価値あるだろうけど…

2017/12/09(土) 23:34:15.72

間違いが広がっては困るから一応言っておくけど
>>403が言っているのはC++とは全く互換性のないC++/CLIのことな

2017/12/09(土) 23:35:31.46

>>409
ウィンドーズホン御用達言語のC++CXにもあるわ；

2017/12/09(土) 23:42:11.37

>>408
覚えるも糞もあるかよ。C#のがそのままだよ。
というか、C#≒.NET≒VC++だから、C#の機能はVC++/CLIでは大概ほぼ使えるはずだが。
https://msdn.microsoft.com/ja-jp/library/2f1ec0b1.aspx

なお死ねには同意。
C#が良ければC#を使えばいいだけ、C#ライクなC++が欲しいならVC++/CLIを使えばいいだけ。

2017/12/09(土) 23:43:07.64

>>410
お前死んだやろ…

2017/12/09(土) 23:47:47.55

>>406
一時期流行ってたprivate厨さんちーす

2017/12/09(土) 23:48:58.02

>>412
ウィンドーズホンでネイティブC++を呼び出すための唯一の手段なので死んではいないﾊｽﾞ…
ttps://docs.microsoft.com/ja-jp/windows/uwp/winrt-components/creating-windows-runtime-components-in-cpp

2017/12/10(日) 00:02:10.31

C++/CLIのことをVC++っていうのやめろよ
それにC++風ですらないし

2017/12/10(日) 00:11:55.72

それは.netへの過渡期中の言語ですね

2017/12/10(日) 00:13:30.39

>>415
いや通称VC++だし、unmanagedはほぼC++11だぞ。
https://www.ruche-home.net/program/cpp/msvc

2017/12/10(日) 00:25:29.55

>>417
そっちじゃねえだろ
こっちだろ
https://ja.wikipedia.org/wiki/C%2B%2B/CLI

2017/12/10(日) 00:27:56.18

>>414
ウィンドーズホンが死んでるだろ…いい加減にしろ！
https://www.gizmodo.jp/2017/10/winodows-phone-is-dead.html

2017/12/10(日) 00:52:59.90

>>418
なるほど君は知らないんだな。VC++/CLIは混ぜられるんだよ。
君が言っているのはmanagedで、俺が言っているのはunmanaged。

まあ、どうせ君は使わないのだろうし、深く知る必要はないが。

2017/12/10(日) 00:58:12.05

ID:Rt5tAWZZ0 こいつ話噛み合わなさすぎてやべえぞ

2017/12/10(日) 06:32:52.80

>>401
protectedこそちゃんと設計しないとメタメタになるだろうが
publicもprotectedもコードの利用者が自由に使えることには変わらんから公開インターフェースには変わらんぞ
お前もしかして「protectedだしメンバ全部下駄雪駄付けて継承先に丸出しするおー(^q^)」ってやってんの？
誰がどんな派生クラス作ってどんなふうにいじくって親クラスのふりして混入させてくるかわからないのに？
世界に発信しないからどうでもいいって？同僚や1年後の自分はたまったもんじゃねえな

2017/12/10(日) 09:34:29.32

>>404
死んでどうぞ

2017/12/10(日) 10:23:51.33

>>423
ただ単にforeground colorまたはbackground colorを変更するだけのために
いちいちオブジェクトを破棄してGDIリソースを開放して再びGDIリソースを確保してオブジェクトを新規作成し直してどうぞ

>>423にとって不幸なことに、この惑星では現実のアーキテクチャーも現実の外部世界も移ろいゆくもの（mutable）なんじゃ

2017/12/10(日) 11:12:25.71

>>424
変更をstateとしてカプセル化しろという示唆だボケ
外からガチャガチャいじんな

2017/12/10(日) 12:09:09.67

>>425
setForgroundColor(Color color)がカプセル化の結論ではありえないとする根拠は？
だいたいstateにせよ（＝mutableな要素をオブジェクト内に受け入れる）というのは>>400から話が逸れているわけだが

2017/12/10(日) 12:12:47.79

背景色が暗かったら前景色を明るくして見やすくするとかそういう制御はしないのか？
最初はしないつもりでも後から必要になったりリクエストが来たりしたらどうするんだ？
前景背景以外の第3の色のパーツが増えたらどうする？
アルファチャンネルが増えて半透明時はその裏側の色にも合わせて制御する必要が出てきたらどうする？

インターフェースってのは中のデータメンバーの下駄と雪駄とかそんなレベルで決めるもんじゃないんだよ
お前の言ってることは次元が低すぎるんだよ

2017/12/10(日) 12:17:16.01

>>426
前景色をいつでも外部から独立に変えて良いオブジェクトならそれで構わないけど
それをforeColorメンバ変数があってそのsetterだから～みたいな程度の低い議論で決めたんだとしたら
後で大変な苦労をすることになるだろうな
今のお前はしなくてもお前の同僚やユーザーや1年後のお前がな

2017/12/10(日) 12:22:05.28

>>427
>背景色が暗かったら前景色を明るくして見やすくするとかそういう制御はしないのか？
>最初はしないつもりでも後から必要になったりリクエストが来たりしたらどうするんだ？
>前景背景以外の第3の色のパーツが増えたらどうする？
>アルファチャンネルが増えて半透明時はその裏側の色にも合わせて制御する必要が出てきたらどうする？
setForgroundColor()を備えた低水準なクラスを実現した上で、
ユーザーの好みや用途に合わせた高水準なクラスをかぶせる階層設計にする

なんでもかんでも詰め込んだクラス設計はアレくね？>>427の好みなのかもしれんが

2017/12/10(日) 12:28:25.79

どういう設計にするかって話じゃなくて
設計を決めるのに最初からデータメンバーと下駄雪駄ありきで考えるのをやめろって言ってるんだが
何一つ伝わってないようで残念だ

2017/12/10(日) 12:35:10.91

>>430
>設計を決めるのに最初からデータメンバーと下駄雪駄ありきで考えるのをやめろって言ってるんだが
はげどうで、それにたいするスレ内に書かれた情報を前提とする答えが階層設計(>>429
何一つ伝わってないようで残念だ

ていうか
>>427程度では可能性を列挙しているだけで何を作るべきなのか指定したことにならない
仕様提示も無しにクラスの詳細を設計せよとかどんだけ～

2017/12/10(日) 13:12:04.65

427は例えば前景背景色を変えるインターフェースを作るときに考慮しなきゃならなそうな事のほんの一例を挙げただけで
詳細設計しろなんて誰も言ってないんだが

最初に考慮すべきことはそもそも何を実現するつもりなのか、そのためにどういう操作を受け付けなきゃならないかであって、
privateのデータメンバーにbgColorがあるとかはどうでもいいし、必要ならそんなもの後から変えたっていいんだよ
それをデータメンバーありきで脳死で下駄雪駄付けてたら、そのメンバーの存在が公開外部仕様になって簡単に変えられなくなるんだよ

お前さんの例で言うと、不用意にsetFgColor()とsetBgColor()を公開したら、ずっとその2つを外部から独立に自由に変えられるようにしなきゃならなくなるの
本当にそうするべきなのかは、それこそオブジェクトの本来の目的次第で判断することでしょ？
「とにかくデータメンバーにbgColorとfgColorがあるんだからひつようなんです(^q^)」とか抜かしてたらバカで無能だと思うだろ？
お前さんは今そう見られてるんだよ

2017/12/10(日) 14:15:05.98

buttonならselectedとかdeselectとか、たぶんそんなインターフェース。
color露出とか正気の沙汰ではない。

2017/12/10(日) 15:16:20.19

setColor()なんてグラフィックコンテキストのIFならありがちだけどな。

2017/12/10(日) 15:18:46.15

世の中のたくさんの組織で使われたりするような汎用ライブラリならね

2017/12/10(日) 15:25:40.37

>>435
そういうライブラリならあり得るんだろ？
要件もわからんのに頑なに否定する ID:dE7pgqu30 がアホと言う結論でよろしいか？

2017/12/10(日) 15:48:26.65

別にset～Colorなんて普通にありだろ
変なふうに頭固いやついるね

2017/12/10(日) 16:44:14.11

正直GUI系は納期に晒されやすいということもあってコードが汚くなりがちではある
それが劣っているとか優れてるとかではなく気の毒ではある

2017/12/10(日) 18:11:24.37

>>438
設計の話してるのにいきなり実態を語るとか話をそらそうと必死
って言うことでいい？

2017/12/10(日) 18:26:16.47

>>432
>最初に考慮すべきことはそもそも何を実現するつもりなのか、そのためにどういう操作を受け付けなきゃならないかであって、
いやまさしくおっしゃるとおりで、
グラフィック部品のforeground colorとbackground colorは通常の表示ハードウェアの元では独立に変えられるﾌﾞﾂなのだから
ハードウェア寄りなwrapperレベルの実装だとそれぞれ独立に露出するのが正しいという結論に…
（独立に弄っても内部状態の不整合は起きない。これがgetter/setterを公開してもよい基準である

>お前さんの例で言うと、不用意にsetFgColor()とsetBgColor()を公開したら、ずっとその2つを外部から独立に自由に変えられるようにしなきゃならなくなるの
ならない
階層設計の意味がわかっていない？
漏れのやり方で起きることは、Foreground colorとbackground colorの2つを公開したクラスXのインスタンスをいつでも作れるというだけで、
上位水準で要求される操作のみを受け付けるべくXを利用して実現するクラスYではsetFgColor()とsetBgColor()を隠蔽することができる。
（単にYが使うXのインスタンスをprivateにすれば良い

ていうか話を進める前にID:dE7pgqu30には>>426の2行目にお答えいただいてからにしていただきたいですのう…
（>>400の話が途中から変わっていることには目をつぶって差し上げても良いので

2017/12/10(日) 21:00:01.55

そもそもセッターゲッター書きまくらなきゃいけなくなるんだけどどうすればいいの？っていう話では

2017/12/10(日) 22:12:52.74

ゲッターロボ発進！

**320** (ﾜｯﾁｮｲ b7e3-qmOZ) · 2017/12/10(日) 22:58:45.66

>>441
俺が発端だとしたら書きまくるなんて言ってない
楽に書く方法導入されたかな～って聞いただけ

されてないのは分かったからもういけど

2017/12/11(月) 01:44:26.10

>>443
残念ながら標準C++には無いねー。

俺の周りでも結構欲しがる人多いんだけど、何が良いのかいまいちわからないなー。
使うときに、変数を扱うような記法で、関数コールが出来るってだけだよね…
一文字減るだけで何が嬉しいのか…

**35歳** (ﾜｯﾁｮｲ ffb3-5E0R) · 2017/12/11(月) 02:10:24.19

Bronze取りました

2017/12/11(月) 02:22:58.14

自分は邪道なのを承知でマクロ使っちゃってるよ

2017/12/11(月) 03:18:45.90

>>444
それについては
to.setBackgroundColor(from.getTextColor());
より、
to.backgroundColor = from.textColor;
の方が読みやすいから俺は否定はしない

2017/12/11(月) 05:56:14.63

>>447
後でカラーが変更されたときに処理を追加したくなったときに面倒

2017/12/11(月) 06:39:45.71

という、そもそもの話に行き着くだけだな

2017/12/11(月) 07:14:44.24

>>448
話の流れも読めないのかよ...

2017/12/11(月) 09:57:11.02

セッターとゲッターをいちいち作るのかという単純極まる話に流れもへったくれもあるか

2017/12/11(月) 10:07:16.62

だからプロパティが欲しくなるって話なのに……

2017/12/11(月) 10:33:50.92

欲しけりゃ作れというCいやBから続くハングリー精神を忘れた主張はいくら喚いても無駄だ

2017/12/11(月) 10:49:40.94

話の流れ汲む気ねえな

2017/12/11(月) 11:08:12.08

そういうおまえさんも、ここ僅か数レスの流れから目を背けているだろうが

2017/12/11(月) 15:05:22.47

不変条件がある→カプセル化(class)
不変条件がない→露出(struct)

では駄目なの？

2017/12/11(月) 15:51:19.48

ちょっと違う

◆QZaw55cn4c (ﾜｯﾁｮｲ 9f60-T0Wg) · 2017/12/11(月) 15:57:28.19

>>306
try-with-resources/java.lang.AutoCloseable, java.io.Closeable/Java7～　ですか

2017/12/12(火) 01:07:23.70

>>448
お前は
>>444 と>>447を100回読み直して出直してこい

2017/12/12(火) 02:35:53.90

そうか。

2017/12/12(火) 02:55:44.93

>そういうおまえさんも、ここ僅か数レスの流れから目を背けているだろうが

何回読んでもこのレス最強すぎて草生える

2017/12/12(火) 05:03:27.37

>>459
何に腹立ててるのかまったくわからん

2017/12/12(火) 05:49:25.74

>>462
いいから読み返してこい。自分がどんなトンチンカンなレス返したのか自覚するまで帰ってくるな。

2017/12/12(火) 06:04:07.77

>>463
すまんマジでわからん
お手数ですが改めて解説して頂けますか？

2017/12/12(火) 07:20:11.15

>>464
プロパティっつーのは
> to.backgroundColor = from.textColor;
みたいなコードでも.backgroundColorが変更された時の処理が書ける
って話だから

2017/12/12(火) 08:10:48.13

プロパティが常に左辺値として扱えるってなら面白いけど、ただのシンタックスシュガーなんでしょ？