トップページ⇒tech
1002コメント293KB

C++相談室 part126 [無断転載禁止]©5ch.io

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2016/08/13(土) 11:24:45.65ID:NPYsKJkE
次スレを立てる時は本文の1行目に以下を追加して下さい
!extend:on:vvvvv:1000:512

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

前スレ
C++相談室 part125
http://echo.2ch.net/test/read.cgi/tech/1463761261/

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

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

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
0268デフォルトの名無しさん2016/08/31(水) 16:56:40.77ID:/MnV3wL6
リファレンサオブジェクトをpublicデータメンバで持てって？
0269デフォルトの名無しさん2016/08/31(水) 17:50:46.05ID:WLaQrr/5
>>267
合格。絶対にこんなコード書かないけど、
プロパティの要件は一応満たしている。
0270デフォルトの名無しさん2016/08/31(水) 18:02:51.48ID:N4JrJ9XH
vectorとかの配列リファレンサがこんな形だよな
0271デフォルトの名無しさん2016/08/31(水) 18:55:44.77ID:gRHWeOr5
ここを見てるとC++のダメさ加減がよくわかる。
0272デフォルトの名無しさん2016/08/31(水) 19:41:02.78ID:YUscqvM8
不要だからコア言語に追加されなかったんだろう
0273デフォルトの名無しさん2016/08/31(水) 20:06:57.16ID:XvHw9frf
>>266のアドバイスで、使い方が間違っていなさそうだったので、違う拡大鏡ソフトを使用することで解決しました
0274デフォルトの名無しさん2016/08/31(水) 20:41:02.91ID:+TzIiYAW
プロパティ不要とか苦行かよ
0275デフォルトの名無しさん2016/08/31(水) 20:43:28.45ID:YUscqvM8
プロパティなんてあってもたいして使わない予感
0276デフォルトの名無しさん2016/08/31(水) 20:54:10.62ID:/MnV3wL6
実感じゃねえのかよ
0277デフォルトの名無しさん2016/08/31(水) 20:57:52.91ID:ntcwlW+6
プロパティ否定してる奴はエアプだってはっきりわかんだね
0278デフォルトの名無しさん2016/08/31(水) 21:00:08.58ID:NSLbELcw
クラス書かないからわかんない。テヘペロ。
0279デフォルトの名無しさん2016/08/31(水) 21:32:42.17ID:viOT3sew
Visual Studioだったら「共通言語ランタイム サポート」を有効にすればプロパティ使えるで(ゲス顔
0280デフォルトの名無しさん2016/08/31(水) 21:48:33.01ID:MERKTov5
C++/CLIは別言語
0281デフォルトの名無しさん2016/08/31(水) 21:59:28.02ID:/ANAyxIk
アクセス制限もいらないからな
余計なことして何が起こっても全て使用者の責任
0282デフォルトの名無しさん2016/08/31(水) 22:34:19.56ID:xAEFTakh
全部グローバル変数にすると便利だよ
0283デフォルトの名無しさん2016/08/31(水) 22:57:22.63ID:YUscqvM8
プロパティよく使うってひとは要するに属性を個別にコントロールすることが多いって事かね？
0284デフォルトの名無しさん2016/08/31(水) 23:03:00.58ID:6ukDv4b6
>>283
そうかもね。設計が下手なんじゃないかな。
もっとも俺もC#ではプロパティ使いまくるけどね。大概のは{get; private set;}だな。
0285デフォルトの名無しさん2016/08/31(水) 23:06:47.51ID:gUL/+EZq
は？　属性を個別にコントロールするのが設計の良し悪しとどう関係するんだ？

「C++で標準でできないことは出来る必要がないから、
　そもそも、やろうとする奴が悪いんだ」みたいな幼稚な思考だったらやめとけよ？
それは宗教だ。
0286デフォルトの名無しさん2016/08/31(水) 23:10:36.99ID:YUscqvM8
>>285
俺は良し悪しは言ってないよ
0287デフォルトの名無しさん2016/08/31(水) 23:23:15.94ID:YUscqvM8
まあ外部に
「このクラスは内部に属性A、属性B、属性Cを持ち、その状態とアクセスを管理します」
みたいな仕様を公開してるクラスだったらプロパティは使いたくなるだろうな。
でもどちらかというとそういうクラスは少ないような気がしたのさ。
0288デフォルトの名無しさん2016/08/31(水) 23:36:37.26ID:mzwgRQN4
そんなほとんど起こらんようなケースについて抽象的な説明されてもよくわからんわ。
0289デフォルトの名無しさん2016/08/31(水) 23:45:12.50ID:YUscqvM8
>>288
何が？
0290デフォルトの名無しさん2016/08/31(水) 23:51:01.09ID:/MnV3wL6
>>287
普通にprivateデータメンバじゃん、それ
0291デフォルトの名無しさん2016/08/31(水) 23:56:32.05ID:YUscqvM8
>>290
いや、それらの属性を持ってること自体を外部に公開してる。
privateメンバだったらそんなことは内部仕様にしか書かないでしょ。
0292デフォルトの名無しさん2016/09/01(木) 00:14:02.16ID:PJEueDDa
簡潔に

「どんな属性を持ってるか自体を隠蔽するのが普通」

って書けばいいじゃん
0293デフォルトの名無しさん2016/09/01(木) 00:31:43.23ID:8Xtys+zE
プロパティって、何が便利なん？
C#はGUI作成程度しか使わない俺的感性だと、setter/getterで十分じゃね？と思うんだが、メリットをトクトクと語ってくれ。
0294デフォルトの名無しさん2016/09/01(木) 04:18:24.20ID:siIxmZ+U
プロパティは
classの実装とインターフェースの分離が容易にします
プログラムの字面の変更なしで
後から小細工ができます
言語仕様に内包されたパッチ機能？ｗ
>>293
十分だと思います
後から改変するとき小細工が出来て便利なのかな？
0295デフォルトの名無しさん2016/09/01(木) 06:05:34.36ID:quvSlm2c
いや、setterとgetterがめんどいからプロパティがあるんでしょｗ
0296デフォルトの名無しさん2016/09/01(木) 07:26:09.87ID:8Xtys+zE
>>295
手間変わらなくね？
0297デフォルトの名無しさん2016/09/01(木) 07:37:27.71ID:d6w4LGKM
>>296
C#のプロパティは超便利で手間が大きく違う
使ってみれば分かるよ
いまだにこんな便利なものが実装されていないJavaはゴミ
0298デフォルトの名無しさん2016/09/01(木) 08:36:37.64ID:8Xtys+zE
>>297
いや、使った事あるんだけど…
その上でわからないからトクトクとお願いしてる。
0299デフォルトの名無しさん2016/09/01(木) 08:44:04.42ID:7t+U5xjY
そもそもsetterとgetterが必要なのかって話でしょ
0300デフォルトの名無しさん2016/09/01(木) 08:45:24.36ID:ZAvvKiiS
手間はさほど変わらんと思うけどあとで読んだ時に他のメッセージ転送に埋もれない気はする
0301デフォルトの名無しさん2016/09/01(木) 08:51:59.38ID:8Xtys+zE
>>300
ああ、なるほどね。
意味論として、OOのメッセージとプロパティが、C#のメソッドとプロパティに相当するのか。
言われてみれば当然かも。
あざっす。
0302デフォルトの名無しさん2016/09/01(木) 09:01:16.42ID:DsNIQM1p
超便利と書くからワケがわからなくなる
いちいちGetなんちゃらSetなんちゃらと書くよりも既読性が上がる
0303デフォルトの名無しさん2016/09/01(木) 09:39:25.12ID:DsNIQM1p
既読性って何だ？ｗ
可読性だったわｗ
0304デフォルトの名無しさん2016/09/01(木) 09:52:32.53ID:oseS/uHr
引数0の関数は括弧省略できればいいんじゃないのか
0305デフォルトの名無しさん2016/09/01(木) 10:08:05.72ID:d6w4LGKM
「超便利」が分かって貰えないとか
ほんとにC#のプロパティ使ったことあるんですかねえ（笑）
0306デフォルトの名無しさん2016/09/01(木) 11:42:15.33ID:n+lE1LxE
使えば超便利、だがあまり使わない、って両立するけどな。
0307デフォルトの名無しさん2016/09/01(木) 11:57:18.01ID:f8G6zOLb
listenerに出来るなら便利だけど、単なるsetter,getterじゃなあ

全部メソッドの方が統一感はあると思う。
0308デフォルトの名無しさん2016/09/01(木) 12:08:36.30ID:n+lE1LxE
getter/setter（プロパティに相当するものを含む）を持つクラスと持たないクラスの比率ってどんなもん？
俺は1対5ぐらいだ。
だからあれば便利というのはわかる。
0309デフォルトの名無しさん2016/09/01(木) 12:30:21.99ID:LcnNSect
>>296
手間は結構変わるよ。
まず、getter/setterを普通に定義するのより、
プロパティの方がコード量が単純に減る。
変数名と関数名の一致だとかも考慮しなくていいから、
保守もしやすい。

その上、利用時にはpublicメンバ変数のように使えるから、
呼び出し先のコードもすっきりする。

必須ではないから不要と思うなら使わなければいいけど。
便利機能ってだけだし。
0310デフォルトの名無しさん2016/09/01(木) 12:31:26.62ID:LcnNSect
>>304
それはVBAとかそうだけど、ややこしいからやめてくれｗ
0311デフォルトの名無しさん2016/09/01(木) 12:46:32.26ID:d6w4LGKM
>>298
単純な話こういうことを言ってるんだけど。。。

JavaやC++の場合
private int x;
public getX(){return x;}
public setX(int val) {x=val;}

C#の場合
public int X {get; set;}

手間は1/3以下になってる
ほんとに使ったことあるの？
0312デフォルトの名無しさん2016/09/01(木) 13:12:08.94ID:+q6YP6fM
あんなのが欲しい、こんなのが欲しいと、
みんな口々に勝手なこと言うのを
あれもこれもと言語に取り込む
ということをするかしないかというポリシーは
言語が違えば違って当たり前

C#でどうだからC++もどうせよとか
C#でどうだからJavaはゴミとか
そんなにC#が好きならC#だけ使ってればいい
0313デフォルトの名無しさん2016/09/01(木) 13:23:01.35ID:d6w4LGKM
うるせー（笑）なんだかんだ言っても一番好きなのはC++だよ
高速性が求められる場面ではほぼ唯一の選択肢だし
他の言語に比べて不便なところがあったとしても、かゆいところに手が届く感は最強だし
0314デフォルトの名無しさん2016/09/01(木) 13:37:36.32ID:Zz5UEunk
public変数とgetter/setter付きのprivate変数って何が違うの？
0315デフォルトの名無しさん2016/09/01(木) 13:52:30.49ID:d6w4LGKM
>>314
get/set時にコードが介入できる
0316デフォルトの名無しさん2016/09/01(木) 14:51:04.12ID:nGqVI4Wr
public変数なんか使ったら、まともにプログラミング出来ない。
これは、あり得ない選択

変数は出来るだけ、狭いスコープに閉じ込めるのが基本
0317デフォルトの名無しさん2016/09/01(木) 14:52:33.38ID:3wSPfZnR
>>314
昔見た理屈だと、ゲッターセッターは間に正規化とか突っ込めるからセーフティなんだと。
0318デフォルトの名無しさん2016/09/01(木) 15:42:38.63ID:n+lE1LxE
>>316
上段も下段もそれぞれ正しい
0319デフォルトの名無しさん2016/09/01(木) 16:38:25.17ID:f8G6zOLb
>>314
c++の場合、表記が違うので入れ替えが大変。
0320デフォルトの名無しさん2016/09/01(木) 16:52:35.75ID:oseS/uHr
直接変数に対して入出力してるだけのセッターゲッターでも将来を見越してわざわざ作ってるってことか？
0321デフォルトの名無しさん2016/09/01(木) 17:03:57.26ID:d6w4LGKM
>>320
そういう場合も多いかもしれないけど、.Net環境においてはpublicプロパティにすることによる恩恵は多々ある
例えばDataGridViewに内容を表示するときなど
0322デフォルトの名無しさん2016/09/01(木) 18:10:45.91ID:3cPIMSrP
>>314
public変数じゃ、変更されたタイミングで描画をアップデートするみたいな処理がやりにくくなる
needUpdateViewみたいなフラグをtrueにできるだけでも、getter/setterはあったほうがいい

単なる構造体に近いようなクラスでも、データの不整合を起こさないようにバリデーションが行えるという意味では重要
後から値の範囲を制限したくなるとか、複数の変数間で整合性のとれないケースを排除したくなるということはよくある
例えば、Personクラスが初めは性別と名前しかなかったところを、そこに「父」「母」「息子」「娘」みたいな属性を付けたくなったら、性別女で「父」は弾きたくなる
public変数だったらこれはできないけど、setter経由であればできる
「親」「子」にして性別と合わせて計算すればいいとかいう話があるかもしれんが、余談だがその場合はgetterで男女+親子の属性で「父」とかを取り出すことができるね
0323デフォルトの名無しさん2016/09/01(木) 18:27:41.58ID:zfFV4MMV
getterやsetterの関数呼び出しならまだしも、propertyでファイルアクセスやらネットワークのやら時間かかる処理入れられると嫌な感じ
0324デフォルトの名無しさん2016/09/01(木) 18:41:33.44ID:L3a4bYLC
>>323
それは利用者の予期を裏切るような実装をするなって話であって、
ゲッタセッターならよくてプロパティーではだめだって話じゃないと思うけど
0325デフォルトの名無しさん2016/09/01(木) 19:29:54.38ID:quvSlm2c
>>312
C++も11以降がんがん新しい要素取り入れてるんだから、
今の仕様が絶対的なものじゃないぞ。今の仕様を絶対視するのは宗教だ。
0326デフォルトの名無しさん2016/09/01(木) 19:36:30.23ID:qC9ojyjS
>>322
同性婚の夫婦が養子をとった時に破綻する先見性のない設計ですね w
0327デフォルトの名無しさん2016/09/01(木) 19:46:48.63ID:zfFV4MMV
メンバ変数ぽく使えるより、指示すればgetter,setterを自動生成してくれる方がいいな。

参照とって書き換える関数に渡したらどうなるんだとか考えると、変数っぽく使えるのは混乱招くだけのような。
0328デフォルトの名無しさん2016/09/01(木) 20:02:06.91ID:f8G6zOLb
>>326
不要な汎用化じゃね？
必要になってから修正でいいだろ。
0329デフォルトの名無しさん2016/09/01(木) 20:16:20.03ID:qC9ojyjS
>>328
ネタに突っ込むならもう少し面白いやつ頼むわ
0330デフォルトの名無しさん2016/09/01(木) 20:31:55.38ID:n+lE1LxE
setter/gettrrが要る要らないの話題になるとpublic変数の話題に転びがちだな。
ちょっともにょもにょする。
0331デフォルトの名無しさん2016/09/01(木) 20:40:39.28ID:n+lE1LxE
外部から属性を設定せざるを得ない状況がけっこうあって、なかなかリファクタリングも難しいってことか。
0332デフォルトの名無しさん2016/09/01(木) 21:41:16.10ID:quvSlm2c
>>327
C++でプロパティ導入するなら、getterの戻り値は参照かconst参照のどちらかに制限すれば、
その辺の問題は解決しそう。
0333デフォルトの名無しさん2016/09/01(木) 23:31:36.63ID:kyBhPm5k
そういや、パッと見は普通のフィールド（メンバ変数）なせいで
実行速度とか気にせずに気楽に使ってしまいやすい、なんて弊害も多少あるみたいね。
0334デフォルトの名無しさん2016/09/01(木) 23:49:26.27ID:VuYRfyfh
てかgetter/setterでもプロパティカプセル化が弱くなるから原則使わないのが基本だろ
フラグをプロパティ化してどうのこうのとか言ってるやついたけど、参照透過性なくなって状態遷移図保守の雇用を産みだしてるだけ
0335デフォルトの名無しさん2016/09/01(木) 23:55:31.16ID:quvSlm2c
それはおかしいだろ。メンバ変数を外から操作する必要性は普通にある。
例えばWindowクラスとかどうすんの。メンバ変数変えられないWindowクラスとか欠陥品でしょ。
0336デフォルトの名無しさん2016/09/01(木) 23:55:52.32ID:oRYPM1bK
>>334
言いたいことはわかるが、 外からの属性アクセスをやめたとしても、
実際に内部状態が変化するなら参照透過ではないよな？
0337デフォルトの名無しさん2016/09/01(木) 23:58:42.81ID:VuYRfyfh
>>335
お前がWindowクラスを書くのは自由だけど、C++なんだから数値計算ライブラリとかを想定して書けよ

>>336
もちろん
0338デフォルトの名無しさん2016/09/02(金) 00:04:47.23ID:q6GNZ6RD
>>337
否定されてから急に話題を限定し出すってのは一番見苦しいパターンだぞｗ
素直に間違いを認めろよ。数値解析だっていくらでもそういう事例あるだろ。
0339デフォルトの名無しさん2016/09/02(金) 00:23:31.33ID:dxT5btnL
あるかないかで言えばもちろんあるけど、外部主導の状態コントロールは避けたいので、
設計に時間をかけられるときはhetter/setterは減るだろう、ってだけ。
0340デフォルトの名無しさん2016/09/02(金) 00:25:04.39ID:dxT5btnL
X　hetter
〇　getter
0341デフォルトの名無しさん2016/09/02(金) 00:32:46.64ID:wMSGanuZ
C++はプロパティないのでコード書くときは短く済ませたいんで
ゲッターはSize()、
セッターをSetSize()にして
Get省略してる
0342デフォルトの名無しさん2016/09/02(金) 00:50:46.08ID:VaOayOrf
>>341
自分はSetも省略する
たまに引数の関係でできない時もあるけどさ
0343デフォルトの名無しさん2016/09/02(金) 04:12:21.27ID:+CUdjKtm
俺はオーバーロードになると関数ポインタとるのが面倒になるからsetぐらいは省略しないな
0344デフォルトの名無しさん2016/09/02(金) 04:38:51.30ID:17n5VyUh
メンバ関数ポインタってほとんど使わないから気にしたことなかった…
0345デフォルトの名無しさん2016/09/02(金) 06:31:01.77ID:96M6CE+e
>>342
ああ、引数の違いを利用すればsetもgetも省略できるのか。

int value(int val); ... メンバvalueの値の設定
int value(); ... メンバvalueの値の参照

同じ関数名で機能の異なるものを作るのは危険、
ということから思いつきもしなかったけど、
この使い方なら便利で有用かも知れないな。
0346デフォルトの名無しさん2016/09/02(金) 07:16:35.65ID:Vf4h0u1D
>>345
> int value(int val); ... メンバvalueの値の設定
なぜに戻り値？
03473452016/09/02(金) 07:33:47.21ID:96M6CE+e
>>346
値の範囲制限とかする場合に、
戻り値に「実際に格納された値」を入れて返す。

あと瑣末なことだけど、
cout << a.value(val) << endl;
みたいに格納しつつ値も使う、ができてちょい便利。
0348デフォルトの名無しさん2016/09/02(金) 07:35:34.05ID:MC2dvnuP
そう言うの、以前の値を返すのも多いから紛らわしいな。
0349デフォルトの名無しさん2016/09/02(金) 07:36:05.31ID:sd/G3GoC
std::exchange的な〜？
0350デフォルトの名無しさん2016/09/02(金) 07:49:11.95ID:Vf4h0u1D
>>347
> 戻り値に「実際に格納された値」を入れて返す。

こっちはまだわからなくもないが

> 格納しつつ値も使う、ができてちょい便利。

みたいな設計はどうかと思う
0351デフォルトの名無しさん2016/09/02(金) 08:01:45.25ID:/uIui9G6
そうだな
(a = b) = c;
みたいな20世紀の設計思想だな
0352デフォルトの名無しさん2016/09/02(金) 08:01:48.98ID:5Aji0+2+
*thisを返してしまう
0353 ◆SEdFBOkLSw 2016/09/02(金) 08:29:24.90ID:Nu/77N8P
>>352
メソッドチェーン出来て便利だよね。
0354デフォルトの名無しさん2016/09/02(金) 08:44:56.31ID:OksuLk+6
演算子のオーバーロードみたいな使い方のポリシーでは
a.val(b.val() + c.val()) みたいなやつ

というかどうしてもプロパティが欲しけりゃ演算子オーバーロードで真似っこできるじゃん
0355デフォルトの名無しさん2016/09/02(金) 08:48:54.95ID:xzsbRhmn
は？　演算子オーバーロードでどうやってプロパティの代用すんだよｗ
プロパティ分かってない奴か？　コードを示して見ろ。
0356デフォルトの名無しさん2016/09/02(金) 09:12:04.14ID:+CUdjKtm
http://ideone.com/rZ2S2m
こんな感じか？
0357デフォルトの名無しさん2016/09/02(金) 09:14:47.55ID:OksuLk+6
>>355
ググれば普通に出るが？
なんでそんなに必死なの
http://boost.2283326.n4.nabble.com/the-best-possible-c-properties-implementation-tt2626498.html
0358デフォルトの名無しさん2016/09/02(金) 09:20:57.20ID:OksuLk+6
>>356
そうね、そういう感じ
0359デフォルトの名無しさん2016/09/02(金) 10:36:49.94ID:AFnhG1K/
それじゃ仮想関数にできないじゃん。やり直し。
無理やりオーバーライドできるようにしなくていいよ。
既にコードも必要以上に複雑化しててgetter/setterの方がマシなレベルだし。
0360デフォルトの名無しさん2016/09/02(金) 12:07:39.19ID:+CUdjKtm
>>359
NVIって知ってる？
0361デフォルトの名無しさん2016/09/02(金) 12:09:10.62ID:rUpx5Cs1
結局、プロパティは要らんわな。

タイプ量の問題ならマクロで解決出来るし。
0362デフォルトの名無しさん2016/09/02(金) 12:26:51.71ID:6Qab/oE8
これからのC++にプロパティーは必須だな。
これからもどんどん新しい機能を取り入れてどんどん
わけがわからなくなるといい。
0363デフォルトの名無しさん2016/09/02(金) 12:41:00.31ID:1fpVQ5H8
マクロは入力補完できないし衝突の可能性がある
0364デフォルトの名無しさん2016/09/02(金) 12:49:08.18ID:6Qab/oE8
C++はマクロで出来ることをどんどん機能として取り込んで来たのに
いまさら後戻りはできない。
0365デフォルトの名無しさん2016/09/02(金) 18:00:48.43ID:96M6CE+e
C#の「プロパティ」って機能がどんなのか知らないけど、
現在C++にないから不要な機能だ、と突っ張るのは危険かも知れないよ。

いつか「次の規格から『C#のプロパティ』と同様の機能が追加」と
発表されるかもしれない。これまでもそうやって肥大化してるじゃない。
0366デフォルトの名無しさん2016/09/02(金) 18:28:49.74ID:qjeLwgBZ
Javaでもそうだけどgetter/setterは言語的には単なるメソッドでしかないが
C#のプロパティは言語的にメソッドとは違うものとして認識出来るようになっている
そこから様々な便利さが出てきている
0367デフォルトの名無しさん2016/09/02(金) 19:27:06.33ID:nL/2u0CX
>>364
マクロで出来ることではなく、
マクロに頼っていたことを、
マクロを使わずに出来るようにしてきたんだよ。

スコープに従わないオブジェクト指向の敵との戦いだ
■ このスレッドは過去ログ倉庫に格納されています