C++相談室 part133
■ このスレッドは過去ログ倉庫に格納されています
次スレを立てる時は本文の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 C++/CLIのことをVC++っていうのやめろよ
それにC++風ですらないし >>418
なるほど君は知らないんだな。VC++/CLIは混ぜられるんだよ。
君が言っているのはmanagedで、俺が言っているのはunmanaged。
まあ、どうせ君は使わないのだろうし、深く知る必要はないが。 ID:Rt5tAWZZ0 こいつ話噛み合わなさすぎてやべえぞ >>401
protectedこそちゃんと設計しないとメタメタになるだろうが
publicもprotectedもコードの利用者が自由に使えることには変わらんから公開インターフェースには変わらんぞ
お前もしかして「protectedだしメンバ全部下駄雪駄付けて継承先に丸出しするおー(^q^)」ってやってんの？
誰がどんな派生クラス作ってどんなふうにいじくって親クラスのふりして混入させてくるかわからないのに？
世界に発信しないからどうでもいいって？同僚や1年後の自分はたまったもんじゃねえな >>423
ただ単にforeground colorまたはbackground colorを変更するだけのために
いちいちオブジェクトを破棄してGDIリソースを開放して再びGDIリソースを確保してオブジェクトを新規作成し直してどうぞ
>>423にとって不幸なことに、この惑星では現実のアーキテクチャーも現実の外部世界も移ろいゆくもの（mutable）なんじゃ >>424
変更をstateとしてカプセル化しろという示唆だボケ
外からガチャガチャいじんな >>425
setForgroundColor(Color color)がカプセル化の結論ではありえないとする根拠は？
だいたいstateにせよ（＝mutableな要素をオブジェクト内に受け入れる）というのは>>400から話が逸れているわけだが 背景色が暗かったら前景色を明るくして見やすくするとかそういう制御はしないのか？
最初はしないつもりでも後から必要になったりリクエストが来たりしたらどうするんだ？
前景背景以外の第3の色のパーツが増えたらどうする？
アルファチャンネルが増えて半透明時はその裏側の色にも合わせて制御する必要が出てきたらどうする？
インターフェースってのは中のデータメンバーの下駄と雪駄とかそんなレベルで決めるもんじゃないんだよ
お前の言ってることは次元が低すぎるんだよ >>426
前景色をいつでも外部から独立に変えて良いオブジェクトならそれで構わないけど
それをforeColorメンバ変数があってそのsetterだから〜みたいな程度の低い議論で決めたんだとしたら
後で大変な苦労をすることになるだろうな
今のお前はしなくてもお前の同僚やユーザーや1年後のお前がな >>427
>背景色が暗かったら前景色を明るくして見やすくするとかそういう制御はしないのか？
>最初はしないつもりでも後から必要になったりリクエストが来たりしたらどうするんだ？
>前景背景以外の第3の色のパーツが増えたらどうする？
>アルファチャンネルが増えて半透明時はその裏側の色にも合わせて制御する必要が出てきたらどうする？
setForgroundColor()を備えた低水準なクラスを実現した上で、
ユーザーの好みや用途に合わせた高水準なクラスをかぶせる階層設計にする
なんでもかんでも詰め込んだクラス設計はアレくね？>>427の好みなのかもしれんが どういう設計にするかって話じゃなくて
設計を決めるのに最初からデータメンバーと下駄雪駄ありきで考えるのをやめろって言ってるんだが
何一つ伝わってないようで残念だ >>430
>設計を決めるのに最初からデータメンバーと下駄雪駄ありきで考えるのをやめろって言ってるんだが
はげどうで、それにたいするスレ内に書かれた情報を前提とする答えが階層設計(>>429
何一つ伝わってないようで残念だ
ていうか
>>427程度では可能性を列挙しているだけで何を作るべきなのか指定したことにならない
仕様提示も無しにクラスの詳細を設計せよとかどんだけ〜 427は例えば前景背景色を変えるインターフェースを作るときに考慮しなきゃならなそうな事のほんの一例を挙げただけで
詳細設計しろなんて誰も言ってないんだが
最初に考慮すべきことはそもそも何を実現するつもりなのか、そのためにどういう操作を受け付けなきゃならないかであって、
privateのデータメンバーにbgColorがあるとかはどうでもいいし、必要ならそんなもの後から変えたっていいんだよ
それをデータメンバーありきで脳死で下駄雪駄付けてたら、そのメンバーの存在が公開外部仕様になって簡単に変えられなくなるんだよ
お前さんの例で言うと、不用意にsetFgColor()とsetBgColor()を公開したら、ずっとその2つを外部から独立に自由に変えられるようにしなきゃならなくなるの
本当にそうするべきなのかは、それこそオブジェクトの本来の目的次第で判断することでしょ？
「とにかくデータメンバーにbgColorとfgColorがあるんだからひつようなんです(^q^)」とか抜かしてたらバカで無能だと思うだろ？
お前さんは今そう見られてるんだよ buttonならselectedとかdeselectとか、たぶんそんなインターフェース。
color露出とか正気の沙汰ではない。 setColor()なんてグラフィックコンテキストのIFならありがちだけどな。 世の中のたくさんの組織で使われたりするような汎用ライブラリならね >>435
そういうライブラリならあり得るんだろ？
要件もわからんのに頑なに否定する ID:dE7pgqu30 がアホと言う結論でよろしいか？ 別にset〜Colorなんて普通にありだろ
変なふうに頭固いやついるね 正直GUI系は納期に晒されやすいということもあってコードが汚くなりがちではある
それが劣っているとか優れてるとかではなく気の毒ではある >>438
設計の話してるのにいきなり実態を語るとか話をそらそうと必死
って言うことでいい？ >>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の話が途中から変わっていることには目をつぶって差し上げても良いので そもそもセッターゲッター書きまくらなきゃいけなくなるんだけどどうすればいいの？っていう話では >>441
俺が発端だとしたら書きまくるなんて言ってない
楽に書く方法導入されたかな〜って聞いただけ
されてないのは分かったからもういけど >>443
残念ながら標準C++には無いねー。
俺の周りでも結構欲しがる人多いんだけど、何が良いのかいまいちわからないなー。
使うときに、変数を扱うような記法で、関数コールが出来るってだけだよね…
一文字減るだけで何が嬉しいのか… >>444
それについては
to.setBackgroundColor(from.getTextColor());
より、
to.backgroundColor = from.textColor;
の方が読みやすいから俺は否定はしない >>447
後でカラーが変更されたときに処理を追加したくなったときに面倒 セッターとゲッターをいちいち作るのかという単純極まる話に流れもへったくれもあるか 欲しけりゃ作れというCいやBから続くハングリー精神を忘れた主張はいくら喚いても無駄だ そういうおまえさんも、ここ僅か数レスの流れから目を背けているだろうが 不変条件がある→カプセル化(class)
不変条件がない→露出(struct)
では駄目なの？ >>306
try-with-resources/java.lang.AutoCloseable, java.io.Closeable/Java7〜 ですか >>448
お前は
>>444 と>>447を100回読み直して出直してこい >そういうおまえさんも、ここ僅か数レスの流れから目を背けているだろうが
何回読んでもこのレス最強すぎて草生える >>462
いいから読み返してこい。自分がどんなトンチンカンなレス返したのか自覚するまで帰ってくるな。 >>463
すまんマジでわからん
お手数ですが改めて解説して頂けますか？ >>464
プロパティっつーのは
> to.backgroundColor = from.textColor;
みたいなコードでも.backgroundColorが変更された時の処理が書ける
って話だから プロパティが常に左辺値として扱えるってなら面白いけど、ただのシンタックスシュガーなんでしょ？ getsetなんちゃらより視覚的にわかりやすくて見た目がスッキリして汚物感がない あえて無視してるとかじゃなくてガチでわからんのか…… to.backgroundColor.blue = 100;
みたいに書いても意図通りに動かないからクソ to.backgroundColor.blue(100);
でいいだろ。 あるデータメンバをpublicにしたほうが合理的と判断したならすればいい
そこでいちいち教条主義にとらわれて見えない不安と戦うアフォは
物事の分別がわかるようになるまでROMってろ また流れの読めない奴が来たのかよ...
しかもドヤ顔 w
> 物事の分別がわかるようになるまでROMってろ
お前がな >>470
コンパイルエラーになるなら問題ないやろ >>465
それをC++でどうするかって話でしょ…
そんなことで上から煽ってたんか
付き合う必要なかったな >>476
お前がレスしたコメントが
「それをC++でどうするかって話」に読めたならマジで救いようがないな。
何がどうなってお前の中ではそうなったのか知らんがそれを外に出してくんな。 >>476
> それをC++でどうするかって話でしょ…
そんな話しはしとらんし
引っ込みつかなくなってるのかマジで話の流れが読めないのかわからんけどしばらくROMっとけ どうにかする以前に現状の標準規格ではどうにもならない >>478
お前こそスレタイ見直した方が良いぞ
引っ込みつかなくなってんのはどっちだか 要するに俺様の個人的好みがああだから言語もそれに合わせるべきと言っているだけ
周りと全会一致状態ならともかく批判的な意見に攻撃的な態度をとるだけ
どっから見ても単なる厨二病の自己チュー まあ言論の自由なんだけどね
やってて恥ずかしおまへんか？ setの方はプロキシオブジェクト噛ませば無理矢理できなくもない（やる価値もない）
getはどうやっても無理 マジで引っ込みつかなくなってるんだな...
>>443 そろそろプロパティが導入されたかなぁ？
>>444 されないねぇ、何が嬉しいのかよくわからんけど
>>447 メソッドが読み書きするより読みやすいでしょ
>>448 変更時に処理を追加できないだろうが
一同 ファッ！？、ヤベーよ、こいつ w プロパティはmsvcだと普通に使えるし、実装できない訳じゃないでしょ
つーかclangもマイクロソフト独自のプロパティに対応してるらしいとの噂 C++と関係ない話題をふっておいて噛み合ってないとか 出来るけどテンプレート引数やautoと相性悪いからあまりオススメしない C++でC#みたいなプロパティがサポートされる日は永遠に来ないからもう駄々こねるな 頭いっちゃってる奴らがサイドショーでもやってんのか？ C#以外のメジャーな言語に採用されたら有用性を認めてやる >>498
JavaScriptにはあるよ。
便利だが、基本的にアジャイルで頻繁に変更する環境向けであり、
C++みたいにゴリゴリやりたいところに向くかは少し疑問。
とはいえ、俺は導入に賛成だが。 >>498
Python Kotlin Swift >>500
Swiftにはないよ。
Computedプロパティと.Netのプロパティを同じだと思ってるなら一から勉強し直したほうがいい。 >>501
Storedプロパティに限定した話だったの？
俺そっち要らない派だからどうでもいいんだけど。 >>495
>>486読んでまだそんなこと言ってるなら相当ヤベーぞ w C#のプロパティはカプセル化の範疇を超えた使い方する奴が出てきてからクソだと思い始めた >>504
可能であれば例よろしく。URLでいい。 いや、どんな機能もクソな使い方をする奴は少なからずいるよ。
そんなもんだよ。 C言語にバックポートしてほしい機能はテンプレート一択。
何を言っているのかわからないと思うが。。。 >>505
プロパティ便利すぎとか言ってる同僚が書いた200行を超えるゲッターや初回だけ挙動が違うセッターなど
publicな変数も混ざってる環境なため普通の変数だと思ってあっちこっちで参照していたら気づかないうちに激重になっていた
どこがボトルネックになっているのか探すのに時間がかかった 仮にもc++使いならばそんなアホみたいな事例を気にする必要はなかろう >>508
サンクス。
> どこがボトルネックになっているのか探すのに時間がかかった
多分これがC++がプロパティを入れない理由だと俺は思っているが、
今のC++の勢いならどうせいつか入れるのだろうとも思っている。
> 200行を超えるゲッター
これはあまり行儀はよくないが、
メソッドとフィールドの文法的区別をなくすのがgetteｒでもあるから、
正しいといえば正しい。
> 初回だけ挙動が違うセッター
これはコンストラクタでやるべきものをセッターに持って来たことが悪い。
つまり、セッターの問題ではない。
セッター文法がこれを誘発するかと言えば、関係ないと思うから、プログラマその人の問題だと思う。
で、C++は一応「プログラマは正しくプログラミングできる」という前提だから、
どうせプロパティもいつか入れるんでしょ、と思っている。
その時には、「getterには重い処理を入れない」等の掟が出来るのだと思う。 ＝での演算子のオーバーロードがsetterに相当する
その辺りを自動でやってほしい
他、＋＝やらの演算子も余りにも面倒なのでどうにかしてほしい
pythonではそういう軟弱な特殊メソッドがあるが軟弱なのでC++の感触には合わない
さらに困難で不可解な記述方法を編み出すべきだ C#についてはサッパリだけど、調べたらかなり便利そうな機能だね、処理を差し挟めるというか？
C++で「stringのように振る舞う値」を作ろうとするとまずその型から定義しなきゃならないし
継承でやっつけることも可能だけど、問題点もある
さらに「intのように振る舞う値」となると継承不可だし、各種演算子をいちいち定義しないといけない
型を定義したいわけじゃなく、ある型のインターフェースを持ちつつアクセス時の処理を入れたいだけ、ってのは
確かにC++にも欲しくなるね
大した例えじゃないと思うけど、いずれ似たようなことが出来るようになったらいいなぁ プロパティって要するに、セッターは1引数の関数って場合が多いような。ゲッターは引数無しの関数。
カッコつけないだけで可読性がそこまで上がるもんかと思う。 ■ このスレッドは過去ログ倉庫に格納されています
