C++相談室 part154
レス数が900を超えています。1000を超えると表示できなくなるよ。
たしかに
勝手にNGしとけば十分で煽るように宣言するは意味はまったくないね
擁護した俺が悪かったごめん >>831
認めましょう
>>838
私の意見に一番近いですね
私は、馬鹿な私の意見を見たくない人も多いと想定しており、馬鹿な私が発言するときは馬鹿の印としてトリップをつけるようにしています、それだけは確約しますので、後は好きなように NG に入れていただいて結構ですよ
私はそういう人に干渉するつもりはありません そういう書き込みを見ると、あわしろ氏よりQzのほうが大人に見えるなあ。
まあでも、あわしろ氏には技術評論社がついてるからね。
謝っといたほうが良いんじゃないの? >>834
俺も以前質問したら、明らかに見当違いなマウント取りたいだけの回答が来て、言い返した時
君みたいな事言われたよ
回答くれるのは有難いが・・・ねぇ。
まぁそういうのはスルーしろ、ってんならまだわかるけど
ちなまともな回答くれた人には礼言ってるからね 知らんがな。キミの意見だけ聞いてその時どっちに問題があったかどうやって判断すればいいんだよ あるクラスのメソッドを他所で借りたいというか使いたいときって移譲(インスタンス化)するかコピペするしかないの? >>844
メソッドをクラスから分離してテンプレート関数にすれば、クラスの継承関係がなくても使えるので便利。 >>844
メンバアクセスしていないならstatic関数にしてクラス名::メソッド名()で呼べる
ただメンバアクセスしていない時点でその関数は本当にそのクラスに属すべきなのか再考したほうがいいけど
あと継承する手もあるけど「借りたいから」程度の理由で場当たり的にやると確実に泥沼化する >>846
> ただメンバアクセスしていない時点でその関数は本当にそのクラスに属すべきなのか再考したほうがいいけど
極論、引数をとって返り値を返す関数だけで全てのことが実現できますよね?
そう思ったらクラスのメソッドにするよりも何でもクラス外の関数にする方がお得というか楽な気がしてしまいます そのとおりで極力フリー関数にするべき
(非静的)メンバ関数というのはデータメンバーの一貫性を保つためだけに使うもんだよ >>847
"メンバアクセスしてない"てのが重要だと思うよ
実際、非staticではなくstaticなメンバ関数にしたい場面てあんまり無い(外の関数と大して変わらんから)
>>848みたいなのはオブジェクト指向も理解出来てないド素人が玄人ぶってよく言うんだよなぁ・・一応釘だけ刺しとく なんかOOPの行き着く先みたいな話してるな
俺も関数が引数と返り値としてメッセージを渡し合って協働していく方が洗練されてると思う
必然、その方が副作用も少ない staticなメンバ関数には、名前衝突しにくい、msvcのインテリセンスのような入力支援を得やすい、という恩恵はある。 オブジェクト指向の概念の話をするときにメッセージって言葉使いませんか?
C++ならメッセージ=メンバ関数
Javaならメッセージ=メソッド
言語によって呼び方が違うから概念的な話のときはメッセージといったほうが通りがよい >>849
「オブジェクト指向も理解出来てないド素人が玄人ぶってよく言う」
の意味がさっぱりわからん
>>848の表現に一切ケチつけられる要素ないと思うけど > データメンバーの一貫性を保つためだけに使う
いったい何が言いたいんだろう
他人に分かり易く言えないのは自分が解ってないからというケースがある > データメンバーの一貫性を保つためだけに使う
この表現で普通に分かるけど
分からん人もいるのね了解 >>856
でか口は具体的に説明できてからぬかせ
このハッタリ野郎 データメンバに対して想定した扱い方だけをさせるようにして予期しない状態の発生を防ぐため、って言えばお気に召したかしら
普通はそれを短く「一貫性を保つ」って言うのだけど >>853
使わない、というか使うな誤解を招くから
SmalltalkとかObjective-Cならわかるけど
C++やJavaのそれはメッセージングではないと考えるのが普通(そう見做せないわけではないが >>859
1行目は納得
2行目の主観論には付き合ってらんね >>860さんに同意で
C++やJava界隈だと明確に避けてると見てる
メッセージってのは ごめんねおじいちゃん知らない表現を使われただけでそんなに拗ねるなんて思わなかったんだ いや、悪いけど>>859を以って
>データメンバーの一貫性を保つためだけに使うもんだよ
などと言い切れるのは経験不足と見られても仕方ないと思うよ学生ちゃん おじいちゃんとか学生ちゃんとか、おまえらマウンティングしながらじゃないと会話できないのかw 昔からこのスレは特に酷いよね
なぜマウントの必要があるのかは少しだけ興味深いけど Linuxを使う以上、C++を嫌わないとダメだろ。 >>857,864
いや、メッセージはわかってるけどなんでC++スレで?
って話だろ
>>860の言うようにC++界隈ではあまり使わんし
単にイキってるだけにしか見えんw >>865
どういう理由で経験不足と判断したか言ってみ オブジェクト指向に関しては、今の人は、昔はメモリが高価だったとでも思っておけば良いよ。 一貫性というのはオブジェクト内部の整合性のこ
とを言いたい
のでは…
※ 個人の感想です C++のメソッドの呼び出しをメッセージと言い出すとウィンドウメッセージと紛らわしい(小並感
ていうかC++においてメッセージと言えるのはメソッドの「呼び出し」であってメソッドそのものではない
(例えば)メッセージ自体は継承メカニズムとは独立の概念なのだから
※ 個人の感想です Smalltalkはほぼ知らんけど
メッセージ式ってのは
セレクタ+引数のことだったはず
いやこれどうでもいいか ていうか今にして思えばstd::shared_ptr<IFoo>がIFooのインスタンスに対する所有権を適切に移譲したり管理するので
std::shared_ptr<T>に持たせることにした時点でIFoo自体がリソースに対する所有権を管理する必要はなさげorz smalltalkなんて誰も使わないのだから、アジソンウェスレイのオブジェクト指向プログラミング入門にそう書かれていたからという理解で良いのでは?
若者もいるので説明しておくと、書店で書籍を買う時代があって、書店に並ばなければ書籍の存在自体わからなかったのですよ。
この本は何処の書店にも並んでいたので、スレの高齢者全員が読んでいます。
この本しかなかったんですよ。
良い本だとは思いませんが、30年たった今でも古書に値が付くはずです。
全員が読んでるので、全員が知っているかのように錯覚する人もいるって事です。 C++のオブジェクト指向でメッセージングのワード出してくるのは
継承を説明するサンプルコードで動物の階層もちだしてくるのと同じ功罪がある
理解のとっかかりにはいいが、リアルな実装の段階ではそういうポエムみたいな話は忘れたほうがいい >>879
功もあると御自分で書かれているのでは? >>873
これで本当にいいのか?
コピー代入演算子でムーブさせるのが本当にあなたのやりたかったこと?
std::auto_ptrはこの問題があったからdeprecatedになったんだけど >>878
>書店で書籍を買う時代があって、書店に並ばなければ書籍の存在自体わからなかったのですよ。
私の若い頃を思い出します。
当時、神戸の一番大きな本屋さんでは、どうしたわけだかコンピューター関連書籍の部分だけは黒山の人だかりで、いつも二十人くらいがみんな立ち読みしまくっていて、そういう人ごみを押しのけて本を探さなければならなかったくらいでした
最近右翼になった数学者・藤原正彦氏によれば、もっと古い時代には町の小さな本屋さんであっても普通にそんな状態だった、ときいています、とても信じられませんが‥‥
そういうわけで、アマゾン・ウェルカム! >>875
私は例のペゾルド教本を何とか C++ に適応させたくて、ペゾルド本の WM 処理・巨大 switch 文を C++ に適合させようと未だに四苦八苦していますが、やっぱり MFC に移っちゃったほうが楽チンなんでしょうか? >>871
あまりに一面的な見方やろ
>>848はカプセル化も多態も、上で話してた関数オブジェクトさえ否定する暴論
よほど拒否反応があるんだろうなー、と 否定したように見えちゃってるんだな
いろんな人がおるな >>885
まあ
> (非静的)メンバ関数というのはデータメンバーの一貫性を保つため「だけ」に使うもんだよ
の「だけ」に引っかかってると思うんだけどそっちの方がどちらかと言うと暴論に見えるよ まぁ関数オブジェクトはある意味当てはまってるかもしれんと思うが
>>887
そっちも根拠書いてね >>888
>>886が言うように「否定」はしてないと思うよ
ってことね [selector message]
Objective-Cが良かったな。 >>884
やってみるとわかるけど、MFCと同じものを自分で作ってる感じになるね
ARM C++時代に作るとああなるんだけど、
今どきのC++20で作るとどうなるのかは興味深い 現代的な Windows のフレームワークとしては C++/WinRT に力が入ってるみたいなんで、
今からはこれを使った方がよさげ P/Invokeともこれでおさらば、
と言いたいところだがネイティブC++をwrapするC++/WinRT自体はCLR上の言語なんじゃなかったっけ…
違ったっけ… int (int)型のコールバック関数ポインタにて、一応呼ばれるのでnullはマズイけど不要なので空にしたいという場合に
int () { return 0; }という引数が一致しない空関数へのポインタを渡すとまずい事になるんでしょうか?
低レベルの知識がないのでよく分からないんですが、スタックの巻き戻しとかでズレが生じるとかありそうな気がしています >>896
使われている ABI による。
x64 環境なら Unix (系の多くの OS) でも Windows でも引数は整数4個分までは
レジスタで渡されるんで、スタックの整合性は壊れないはず。 >>896
スタックは呼ぶ側で処理するからズレないよ
でないと可変長引数とか実現できないし
>>897
そんなもんは処理系やオプション次第 静的解析ツールやコード分析で警告が出るだろうから直したほうがいいと思うけどね x64 の一般的な ABI ではもう様々な呼出し規約を使い分けないようになってる。
(cdecl と stdcall が混在していた Windows が例外的で
他は 32bit 時代からかなり統一されていたみたいだけど。)
まあそれはともかくとして、
実際には不要でも適当な値が渡るようにして型を併せるほうが良いとは思う。
不整合を残しておくと強い最適化をかけたときにわけのわからないことになりがち。 はちみつは見所がある弟子にしてやっても良いと、あわしろ氏が褒めてた。 >>896
古いCから新しいC++まで含め、素朴な観点では原則的には大丈夫では有るが、
あなたが言っているように例外処理が入ってくるとどうなるかは不明。
C/C++では型を厳しくしているのは、そういうことを避けるため。
あなたのやろうとしていることは、関数アドレスをキャストしなくては
関数ポインタへの代入できない。
このようにキャストすることによって、アーキテクチャ依存となり、不具合が起きる
確率が0でなくなる。 >>902
[補足]
例外処理はとても複雑なことが行なわれることがある。
関数ポインタに代入する際に関数シグネチャが異なるものをキャストして入れると
どうなるかは処理系依存となる。
関数アドレスを同じビット数の整数型の変数との間で相互にキャストするのは構わない。
関数なのに、異なるシグネチャのものを代入しあうのは問題。 >>891
そうですか‥‥
いまどき MFC の教科書が存在するかどうかは疑問ですが、やっぱり MFC に戻るしかないのですか!
でも、あのドキュメント=ビュー構造はいまだによく理解できないですね‥‥ C++は一応明示的に破ろうとしなければ結構ちゃんとチェックしてくれる
C? 知らんな >>902-903
「引数が一致しない」という素朴な観点でアウトだろうし例外処理関係ないだろ。 >>907
でも、引数を関数内で参照して無い場合、素朴な呼び出し規約的には問題ない。
例外処理の unwinding は仕様が難しいので良くわからないと言うこと。
実際は大丈夫かも知れない。 int (int) { return 0; }で埋めて何が嫌なのかが分からないからな
特別な事情があるなら動かすハードとかの仕様調べろ
そんなのないなら素直に安全に書いとけ、でいいじゃん >>904
一つのデータを複数のウインドウで見るって考え方だよ
テキストエディタでもスプリットバーやマルチビューは普通に使うだろ >>909と同意見だ
[](int){return 0;}では何がダメなのか
説明がないとこれ以上何とも言い様がない cは互換型の概念がガバガバだからなあ…
typedefは当然互換だけど、structは中身のpodが同じでも(typedefしなければ!)タグ名で弾けるので、一々structに包めば論理ミスを防ぐこともできなくもない 規格書を読んでみんなC++覚えてたの?
入門用のドキュメント読んだら規格書読むべきですか? 趣味のC++オタクでいいんならそれでいいと思うよ
C++を実用したいならそういうのはやめとけ、というかまず手を動かせ
その上で疑問が出てきたら調べるのはアリ 問題に遭遇したときに疑問として感じ取れる人ならいいんだが、
謎理論を自分の中に構築して邁進してしまうやつも
少なからずいるので安易に手を動かせとは言いにくい。 各コンパイラに固有の実装依存があるから、結局は試すしかない。
PGが規格と違った動きをしているコンパイラをなじったところで、勝利するのはPGではなくコンパイラ。 商用コンパイラがその商用コンパイラがサポートしているはずの規格と違う挙動だったらそれは文句言ってもいいだろ。 文句を言うのはいいけど、規格書を盾に納期は延びないのよ。 まあその通りなんだけど、誰かが言ってるからコンパイラ改良されるわけで PGは、コンパイラが規格準拠してくれる日のために #if #endif で区切ってすぐに切り替えできるようにしておくことしかできない。
dirent周りのカオスを知っているなら、規格準拠をうるさく言う虚しさを理解しているはず。 商用コンパイラを商売で使うならサポート契約とセットじゃねーの?
使い倒さないと契約料丸損やないけ。 >>922
いつも思うけど、お前仕事で書いたことねーのに何でそんな偉そうなん?
ちな俺はVCのバグ報告(テンプレート周りとか気付かれにくい部分)何度かしてるが、直るのは早くても半年後だよ
仕事でなくともとりあえず何とか回避するしか無いし、報告するにも再現性あるコード提供しないと迷惑かける
皆お前みたいに暇じゃねーんだよ >>923
こういうのって結構な割合で最適化の不具合だったりするよね
特に組み込み系だとしょっちゅうそういうのあるから、該当箇所だけ最適化レベル下げて通したりしてるわ
もちろん不具合の報告もしてるけど修正まで時間かかるからね すぐにとはいかない現実があるのはわかるが、サポート契約の内容を本当に把握して言ってる?
商品の瑕疵に対応するのはあたりまえだからサポート契約ってのはそれ以上のものだよ。
契約内容によるけど、コンパイラのバグである証明とか全部してやる必要はかならずしもなかったりするぞ。
VC のバグ対応がよくないならそれは VC のサポートチームが良くないってだけだ。 #if #endif マクロがない言語は無駄にネストするのが欠点だと思う。 #if での切り分けだってネストはありうるけど、
それが見た目に分かりづらかったりするし、
いいことばかりじゃないよ。 一昔前なら effective c++ くらいは読もうってとこだったが、
今はどうだろうな。efective modern c++ でも足りない感じがする。
てかc++やるなら自分であれくらいのポイント抑えるくらいの準備が必要かもしれんという地獄。 スマートポインタが標準規格に採用されたC++11とそれ以前では、作法が随分違ってくる気がするよ。 >>917
「文句」みたいな感情的なものじゃなく
ドライにバグレポだ
再現コードだけじゃなく回避方法もつけて >>923
> いつも思うけど、お前仕事で書いたことねーのに何でそんな偉そうなん?
やめたれw >>925
> 契約内容によるけど、コンパイラのバグである証明とか全部してやる必要はかならずしもなかったりするぞ。
無いかも知れんが、「なんかおかしいんです~」でバグの特定がめっちゃ困難なことはプログラマーは身を持って知ってるから
そもそもバグの解決が遠のいたら苦しむのは自分だし >>931
いや、純粋な言語仕様の話なら別に偉そうでもいいのよ正しい事書いてくれてるなら >>932
雑な報告でいいというわけではないが、
サポート契約の利用率が非常に低い (値段は高いのに!) というのはよく聞く話なんで、
報告して対応待ちというだけじゃなくてもっとプロジェクトに巻き込んでいいはずなのになという感じ。
C++ の話じゃないけど、 LispWorks (Common Lisp の処理系) のバグ報告をしたら数日中に暫定パッチが
出てきたりとかワークアラウンドの提案とかもしてくれるという事例を利用者のブログで
見たことがあって商用処理系ってすげーなーと思ってたんだが、
そういう対応のほうが例外的に良すぎるだけなんかね? >>934
そういう対応はマイナーメーカーの方がいいことが多いよ
MSの対応が悪いとは言わないけどユーザーがアホほど多いから処理系のバグにぶち当たる可能性も低いし スケジュールきついだけかもよ
バグがあるのわかってたけど数日かかりそうだから放置
バグ報告が出たから優先度上げて修正 そもそもユーザー数がアホみたいに多くてあらゆる層で利用されてるようなコンパイラだと
バグ報告あがってきてもまずそれほんとにバグなの??
ていうかまたコイツのリポートか!!!もしかしてただのいやがらせとかじゃないの??とか
色々まず疑ってかからないケースも半端なく多いだろうしな レス数が900を超えています。1000を超えると表示できなくなるよ。