[過去ﾛｸﾞ] C++相談室 part154 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
775: 2021/02/20(土)11:17 ID:ZF+WEG2v(1/3) AAS
半順序とかいう訳が悪い
英語のpartial orderの方が分かりやすい
776(1): ◆QZaw55cn4c 2021/02/20(土)11:27 ID:mkFIMg3t(1/2) AAS
>>774
本によって用語にブレがあるのは数学では常識でしょう？だから>>761 では定義もあわせて書いておきました
777: 2021/02/20(土)11:30 ID:ec7b4JGn(1) AAS
あとは裁判で争うしかないでしょうね。
我々には判決が出せませんから。
778(1): はちみつ餃子 ◆8X2XSCHEME 2021/02/20(土)11:52 ID:N5IkYQZo(1/4) AAS
>>771
前提条件として
・ T の型が trivially copyable である
・ vector の大きさが必要な大きさ分に出来ている
ならそれでもいいよ。
でも、 C の関数を C++ でも使えるのはほとんどが互換性のためでしかなく、
作法的にはあまり使わないに越したことは無いって感じ。
779(1): はちみつ餃子 ◆8X2XSCHEME 2021/02/20(土)11:56 ID:N5IkYQZo(2/4) AAS
>>771
>>778
と思ったけど、 vector<T> ではなくて vector< vector<T> > なのか。
それだと領域が連続するという前提が成り立たないんじゃないんですかね。
780(1): 2021/02/20(土)12:51 ID:K0wy5MAI(1/3) AAS
>>770
どういう意味じゃ…
ムーブコンストラクトする手段をインターフェースとして公開したい需要は論理的に有り得る
それともIFoo::move()に実装が伴うからという意味？
781(2): 2021/02/20(土)14:23 ID:XZPJJfWU(1) AAS
>>779
なぜ？
行優先か列優先かは置いといて、vectorの要素は連続するのだからvectorのvectorも連続するのでは？
サイズやキャパシティが変わったときに不連続になりうるということ？
782(1): 2021/02/20(土)14:39 ID:ZF+WEG2v(2/3) AAS
vectorのvectorの中身はサイズ値とバッファポインタが連続で並んでるだろうな
783: 2021/02/20(土)14:57 ID:upzAgg50(2/2) AAS
>>781
正しくコピーしたければ、
memcpy(b[0].data(), ...)
みたいにしないと。
このとき当然b[1]のデータ領域はb[0]の後ろに連続していない
784: はちみつ餃子 ◆8X2XSCHEME 2021/02/20(土)15:27 ID:N5IkYQZo(3/4) AAS
>>781
vector 型のオブジェクトが連続して並んでいることは保証されるよ。
でも vector 型のオブジェクトのメモリレイアウトがどうなってるかは保証されない。
常識的な実装は >>782 が言う通りヒープから持ってきたメモリのポインタなどを持ってるだけ。
データそのものを内包しているわけではない。
785: 2021/02/20(土)16:22 ID:UDAFNKrx(1/2) AAS
ほらCと同じ基本の部分を教えずにいきなりSTLとか勧めるからこういう初心者が出てくる・・
786: 2021/02/20(土)17:06 ID:1TZxH4Mg(1) AAS
ある程度出てきても問題ないだろ。ちゃんとドキュメント読んで理解してくれる人も多いんだろうし、
「Cと同じ基本の部分」を教えたところでちゃんと理解してくれない人も居るだろうし。
787: 2021/02/20(土)17:09 ID:UDAFNKrx(2/2) AAS
ちょっと何言ってるかわかんない
788(1): 2021/02/20(土)17:54 ID:ZF+WEG2v(3/3) AAS
相談室に初心者が来て何の問題があるのか
789: はちみつ餃子 ◆8X2XSCHEME 2021/02/20(土)18:06 ID:N5IkYQZo(4/4) AAS
>>788
程度による。
790: 蟻人間 ◆T6xkBnTXz7B0 2021/02/20(土)19:27 ID:VmESNyRi(1) AAS
>>771
> array<T> a を vector< vector<T> > b に n 要素分コピーしたいときって
> memcpy(b.data(), a.data(), n*sezeof(T))
> で良いんですかね？
待てよ、b.data()って&b[0]だから型はvector<T>*だろ。書き換えたらいけないアドレスじゃん。
ダメです。
791(1): 蟻人間 ◆T6xkBnTXz7B0 2021/02/20(土)19:49 ID:HfYkFRCd(1/2) AAS
C++のvectorでは、演算子[ ]がオーバーロードされてるから、C言語の常識が通用しないんだよ。
memcpyは危険な関数だから簡単にメモリー破壊できるんだよね。
std::vector v;
int a = 5;
memcpy(&v, &a, sizeof(a)); // vのメモリー破壊。
792: 2021/02/20(土)20:38 ID:PUIofNKd(1) AAS
>>791
流石にそれは質問者のレベルにも達してないんで問題外
793(1): 2021/02/20(土)20:44 ID:Rkd/h2tQ(1) AAS
別にここで何が正しいかを結論できなくてもいいのだが
>>776
そう言うなら「推移的かつ反射的であるのみの順序関係」が「弱順序」と書いてある本を
教えてくれる?
手元になかったらうろ覚えでもいいけど。〇〇の××先生がそう言ってたみたいのでもいいw
知識として一応確認しておきたいかなと。
794: ◆QZaw55cn4c 2021/02/20(土)21:19 ID:mkFIMg3t(2/2) AAS
>>793
>>761 では「推移的かつ反射的であるのみの順序関係が『弱順序』」とはいっていませんよ、よく読んでくださいね
>>761 で言っているのは「一番弱い順序、推移的かつ反射的であるのみの順序関係は、実は任意の二項間においてかならずしも順序関係の真偽が定まらなくてもいい」としかいっていませんですよね‥‥
曲解もはなはだしいと思いますね
ちなみに私の教科書ではこれを「擬順序」と定義しています、大熊正氏の本ですが、私には一生かかっても私には読めないでしょうから、あとはググってください
795: 2021/02/20(土)21:44 ID:K0wy5MAI(2/3) AAS
std::vector v(sizeof(int));
int a = 5;
memcpy(&(v[0]), &a, sizeof(a)); // おk
796(1): 2021/02/20(土)21:47 ID:K0wy5MAI(3/3) AAS
つかこうかorz
std::vector<int> v((size_t)1);
const int a = 5;
memcpy_s(&(v[0]), sizeof(v[0]) * v.size(), &a, sizeof(a));
797: 蟻人間 ◆T6xkBnTXz7B0 2021/02/20(土)21:58 ID:HfYkFRCd(2/2) AAS
この場合は素直にループを書くか、それとも格好良くstd::copy使うのが楽かな。
798: 2021/02/21(日)01:26 ID:G4m9GHw4(1) AAS
for文回したら死ぬ病気にでもかかってんのか？
799: 2021/02/21(日)01:29 ID:oO8KGr2m(1) AAS
条件を満たすならmemcpyのほうが圧倒的に早いからな
800: はちみつ餃子 ◆8X2XSCHEME 2021/02/21(日)01:32 ID:jd0qgVVy(1/2) AAS
それほど速くならない・速くなくていい場合のほうが圧倒的に多いってのもあるけどな。
801: 2021/02/21(日)03:13 ID:ZrTKdY4P(1) AAS
そもそもそんなクソみたいなコードはふつう書かない
802(2): 770 2021/02/21(日)03:54 ID:HYHVDYIS(1/4) AAS
>>780
IFooっていう名前からしてインターフェースってJava/C#的な意味でのそれだと思ってたけど
それならポインタなり参照なりじゃないと機能してないよっていうかコンパイルエラーでしょってツッコミ
803(1): 2021/02/21(日)03:58 ID:0HHdBuLy(1) AAS
メモリコピーを最適化する前に、他にすべきこと沢山あるだろ的な答えになるよな、確かに。
PG界の真理情報だわ。
804: 2021/02/21(日)05:11 ID:L28MHLBD(1) AAS
valarrayでxorとか
805(1): 2021/02/21(日)07:43 ID:F92hI73d(1/6) AAS
>>802
オブジェクトAがconstメンバとして保持しているブツの所有権を移してオブジェクトBを構築することは
ムーブコンストラクタでないと?なのでムーブコンストラクタである必要があり
この要請はオブジェクト全体が直接アクセスかポインタや参照経由の間接アクセスかとは独立愚連隊、
>>803
真に高速化を求められる内側のループでstd::vector<int> xとかしないから
>>796はひとつながりの省略のないコードとして読んだら判断を誤りうる
806(1): 2021/02/21(日)07:51 ID:F92hI73d(2/6) AAS
じゃなかったorz
Foo::Foo(const Foo& src) { (srcを変更して新しいインスタンスを初期化) }
はconst_cast<Foo>的な危険手段でないとやれないが
Foo::Foo(Foo& src) { (srcを変更して新しいインスタンスを初期化) }
とするとなんかコンパイラが警告を出すから
Foo::Foo(Foo&& src) { (srcを変更して新しいインスタンスを初期化) }
にせざるおえないという、
807(3): 2021/02/21(日)13:21 ID:Dqlg3tSu(1) AAS
関数と関数オブジェクトってどう使い分けるの？
808: 2021/02/21(日)13:30 ID:YxY+Ievf(1) AAS
こういう馬鹿にはちゃんとベンチマークとれって言ってやるのが正しい行い。
809(1): 2021/02/21(日)14:32 ID:HYHVDYIS(2/4) AAS
>>805
そんなこと聞いてるんじゃなくて
提示されたコード片じゃどう考えても動かないから何したいか分からんのよ
外部ﾘﾝｸ:wandbox.org
こっから始めてどこをどうしたいか教えてくれ
810: 2021/02/21(日)14:47 ID:9WgNecVw(1) AAS
404 Not Found
811: 2021/02/21(日)15:33 ID:HYHVDYIS(3/4) AAS
すまん
外部ﾘﾝｸ:wandbox.org
812: 2021/02/21(日)16:21 ID:u2qGdVDT(1) AAS
過疎ってるし、初心者どころかJavaの質問でもOKでは？
813(2): ◆QZaw55cn4c 2021/02/21(日)19:01 ID:3Ebck9FU(1/4) AAS
>>807
この質問に対して回答をつける用意がありますが、しばしお待ちを
814(3): ◆QZaw55cn4c 2021/02/21(日)19:27 ID:3Ebck9FU(2/4) AAS
>>807,813
昔のコードを今読んでみたんですが、実のところ関数オブジェクトにする必要性があったかどうか、今の価値観のもとでは首をかしげています
数値計算のプログラムって、無自覚にバンバン書いてると例えばルンゲ食ったをやっているとこと他とかが混ざり合って収拾がつかなくなる、と思って関数オブジェクトにアイソレートした記憶があって、それを思い出して読んでみたんですけれども、今読んでみても、なんだか、ねえ‥‥
2chｽﾚ:tech
815(1): 2021/02/21(日)20:07 ID:F92hI73d(3/6) AAS
>>809
Fooはこんなやつ、
外部ﾘﾝｸ:ideone.com
IFooは、C++ではよく考えたらIFooのオブジェクトを直接生成できないので（>>802の仰せの通り
std::shared_ptr<IFoo>とかで生成することを考えたのだがエラーになるorz
（上のリンク先のコードでコメントアウトしてあるgenerate_IFoo()
思いのほか闇が深かった＼(＾o＾)／
std::shared_ptr<IFoo>が生成できた暁には、
std::shared_ptr<IFoo> pがリソースの所有権を握ったFooを保持しているとき、
std::shared_ptr<IFoo> qというのがいるとして、
*q = *p
で所有権を*pから*qに渡したり、
return *p
で呼び出し元が所有権を有するFooを受け取れるようにしたいﾜｹ
816: 2021/02/21(日)20:09 ID:F92hI73d(4/6) AAS
ちなみにWandboxでソースコードをフォークする方法は
初心者なので
わかり
ません
817(1): 2021/02/21(日)20:14 ID:LxNhpnKU(1/2) AAS
generate_Foo()がコケてるのはnewのところでFooのコピコンがないだけだろ
コピコン書くか、ムーコン使いたいならnew Foo(std::move(foo3))にすればいいだけ
後半も意味不明
*q = *pってそれスライシングだぞ
818(1): 2021/02/21(日)20:23 ID:F92hI73d(5/6) AAS
>>817
普通の（ムーブでない）コピコンは書けないなぜなら>>806の理由により
>*q = *pってそれスライシングだぞ
どゆこと？
Foo foo1とFoo foo2だと
foo1 = foo2
とできるのに、
819: 2021/02/21(日)20:26 ID:F92hI73d(6/6) AAS
ちょっと補足すると、IFooには現状代入手段が無いから、
*q = *pはそもそもコンパイルが通ることはなく、目的とする機能を形而上的に表す仮想コード
のつもり
820(3): 2021/02/21(日)21:03 ID:+My/Unlg(1) AAS
>>814
処理を意味でまとめるようなことなら積極的にやるべきだと思いますが、それは関数オブジェクトじゃなくて関数でもできますよね？
821: 2021/02/21(日)21:05 ID:HYHVDYIS(4/4) AAS
>>815
コピー代入演算子とムーブコンストラクタだけ定義するとか意味分からんし
インターフェースによる隠蔽より先にそっち解決しなさい
何がしたいのか自分で本当にわかってる？
822(2): ◆QZaw55cn4c 2021/02/21(日)21:07 ID:3Ebck9FU(3/4) AAS
>>820
まあ、そのとおりであり、そうなんですよね…
>>814 は関数オブジェクトである必然性はありません、関数オブジェクトを積極的に使う例としては STL にご登場願うしかないのかもしれませんね
823(1): 2021/02/21(日)22:29 ID:LxNhpnKU(2/2) AAS
>>818
shared_ptrは関係ないから普通のポインタで話するぞ（同じ事だ）
IFoo* p = new Foo();
IFoo* q = new Foo();
というのがあったとして*q = *p;ってのは何だと思う？
pとqはIFoo*型だ
だからもちろん*pと*qというのはIFoo型だ
すなわち*q = *p;というのはIFoo::operator=(const Foo&)の呼び出しだ
operator=()はvirtualにできないから、pとqが本当はFoo型オブジェクトを指してることなんか知りもしないし考慮もしない
よってIFoo部分の代入だけが行われて、要はqのIFoo部分だけが首チョンパされてpのIFoo部分が代入される
これをスライシングという
824(1): はちみつ餃子 ◆8X2XSCHEME 2021/02/21(日)23:00 ID:jd0qgVVy(2/2) AAS
>>822
関数オブジェクトに「関数」とついているのは関数と同じ記法で呼び出せるということに意味があって、インターフェイスの問題。
状態を持った関数 (関数オブジェクト) も状態を持たない関数 (関数ポインタ) も統一的に扱えたらうれしいねって話なので、
状態を持たず、高階関数に渡すこともない場合は関数オブジェクトにする意味はないな。
(普通の関数も static 変数への参照を持ってたりする場合もあるので必ずしも状態を持たないわけではないけど。)
825: ◆QZaw55cn4c 2021/02/21(日)23:42 ID:3Ebck9FU(4/4) AAS
>>824,820(>>813,814,822)
結局、どーでもいい一発芸で、ああ動くね‥‥、と思ったまま放置してましたね＜関数オブジェクト
2chｽﾚ:tech
外部ﾘﾝｸ:ideone.com
あとはラムダ式の理解のための存在という認識、か
826: はちみつ餃子 ◆8X2XSCHEME 2021/02/22(月)00:10 ID:oiAqsUn6(1) AAS
「ラムダ式が関数オブジェクト (型の定義と生成) の構文糖」というのは
既存のプログラムとの整合性を壊さない上手いアイデアだと思うけど、
しばらくしたら「関数オブジェクトはラムダ式の実体」という説明のほうが
通りがよくなったりするかもしれないね。
827(1): 2021/02/22(月)04:39 ID:7qATnC1I(1/2) AAS
関数オブジェクトで状態を渡せるのは結構なんだが、コピーコンストラクタ渡しなので、
手の込んだ状態管理だった場合は結局、C言語と同じくユーザー定義変数を介して状態を読み書きすることになる。
828: 2021/02/22(月)08:23 ID:Dz0hZ3aS(1) AAS
>>827
shared_ptr使えば、大抵の場合は問題ないんじゃない？
829(3): 2021/02/22(月)09:54 ID:Y0MZ31oO(1) AAS
>>807,820ですけどQZで始まる人あまりにもレベル低いというか回答者として不適格だと思うのでNGします
830: 2021/02/22(月)10:22 ID:1euWwsnd(1) AAS
>>829
答えてもらってる立場で偉そうに。常識ないの？
831(2): 2021/02/22(月)11:11 ID:M+ptXBNl(1/3) AAS
いやでも実際・・・QZはね・・・
50過ぎのおっさんが無理して絡みにいってるけど空回りしてる感じなんだよね
ほんと残念だけども
832: 2021/02/22(月)11:36 ID:7qATnC1I(2/2) AAS
関数オブジェクトに対するラムダ式の優位性は、ローカル変数を比較的安全かつ手軽に参照渡しできることだろう。
833: 2021/02/22(月)12:08 ID:5Ezd+ZoO(1/2) AAS
あわしろ氏がQzはアカン言うてたけど、ターゲット変えたのかな？
急にその手の書き込みが増えてあからさますぎる。
834(1): 2021/02/22(月)16:15 ID:rpJl6SNk(1/2) AAS
>>831
QZの回答は糞だとして、回答者に対して>>829みたいな態度をとることがどう正当化されるわけ？
835(2): 2021/02/22(月)17:04 ID:M+ptXBNl(2/3) AAS
回答者には無条件で感謝しないといかんのか？
気持ち悪いな
836: 2021/02/22(月)17:39 ID:rpJl6SNk(2/2) AAS
>>835
感謝しろなんて言ってないぞアホ
837: 2021/02/22(月)19:14 ID:SaDkzfTf(1) AAS
>>835
回答を得るのに適切な行動を取りゃいいよ。
変にヘイトを吐くとつっかかる奴がいるから回答から遠くなる。
>>829は感情を制御する訓練をしないとな。
838(1): 2021/02/22(月)19:28 ID:M+ptXBNl(3/3) AAS
たしかに
勝手にNGしとけば十分で煽るように宣言するは意味はまったくないね
擁護した俺が悪かったごめん
839: ◆QZaw55cn4c 2021/02/22(月)19:57 ID:R3R68rti(1) AAS
>>831
認めましょう
>>838
私の意見に一番近いですね
私は、馬鹿な私の意見を見たくない人も多いと想定しており、馬鹿な私が発言するときは馬鹿の印としてトリップをつけるようにしています、それだけは確約しますので、後は好きなように NG に入れていただいて結構ですよ
私はそういう人に干渉するつもりはありません
840: 2021/02/22(月)20:02 ID:5Ezd+ZoO(2/2) AAS
そういう書き込みを見ると、あわしろ氏よりQzのほうが大人に見えるなあ。
まあでも、あわしろ氏には技術評論社がついてるからね。
謝っといたほうが良いんじゃないの？
841: 2021/02/22(月)20:52 ID:jfkpe4Eh(1/2) AAS
>>834
俺も以前質問したら、明らかに見当違いなマウント取りたいだけの回答が来て、言い返した時
君みたいな事言われたよ
回答くれるのは有難いが・・・ねぇ。
まぁそういうのはスルーしろ、ってんならまだわかるけど
ちなまともな回答くれた人には礼言ってるからね
842: 2021/02/22(月)21:08 ID:51epSMYu(1) AAS
知らんがな。キミの意見だけ聞いてその時どっちに問題があったかどうやって判断すればいいんだよ
843: 2021/02/22(月)21:18 ID:jfkpe4Eh(2/2) AAS
そういう話じゃねーよ
844(2): 2021/02/23(火)00:38 ID:6MWC7t1x(1) AAS
あるクラスのメソッドを他所で借りたいというか使いたいときって移譲(インスタンス化)するかコピペするしかないの？
845: 2021/02/23(火)00:41 ID:Z5ZYenTn(1/2) AAS
>>844
メソッドをクラスから分離してテンプレート関数にすれば、クラスの継承関係がなくても使えるので便利。
846(1): 2021/02/23(火)01:01 ID:48JMuLBY(1/2) AAS
>>844
メンバアクセスしていないならstatic関数にしてクラス名::メソッド名()で呼べる
ただメンバアクセスしていない時点でその関数は本当にそのクラスに属すべきなのか再考したほうがいいけど
あと継承する手もあるけど「借りたいから」程度の理由で場当たり的にやると確実に泥沼化する
847(1): 2021/02/23(火)04:11 ID:kBU50DXM(1/2) AAS
>>846
> ただメンバアクセスしていない時点でその関数は本当にそのクラスに属すべきなのか再考したほうがいいけど
極論、引数をとって返り値を返す関数だけで全てのことが実現できますよね？
そう思ったらクラスのメソッドにするよりも何でもクラス外の関数にする方がお得というか楽な気がしてしまいます
848(3): 2021/02/23(火)07:21 ID:7kgSemXY(1/3) AAS
そのとおりで極力フリー関数にするべき
（非静的）メンバ関数というのはデータメンバーの一貫性を保つためだけに使うもんだよ
849(1): 2021/02/23(火)07:27 ID:ex5XjLGm(1) AAS
>>847
"メンバアクセスしてない"てのが重要だと思うよ
実際、非staticではなくstaticなメンバ関数にしたい場面てあんまり無い(外の関数と大して変わらんから)
>>848みたいなのはオブジェクト指向も理解出来てないド素人が玄人ぶってよく言うんだよなぁ・・一応釘だけ刺しとく
850: 2021/02/23(火)08:19 ID:kBU50DXM(2/2) AAS
なんかOOPの行き着く先みたいな話してるな
俺も関数が引数と返り値としてメッセージを渡し合って協働していく方が洗練されてると思う
必然、その方が副作用も少ない
851: 2021/02/23(火)08:29 ID:Z5ZYenTn(2/2) AAS
staticなメンバ関数には、名前衝突しにくい、msvcのインテリセンスのような入力支援を得やすい、という恩恵はある。
852: 2021/02/23(火)08:30 ID:u3MMsI1X(1/5) AAS
メッセージ・・？
何の言語の話してんだ
853(1): 2021/02/23(火)09:47 ID:DwnxTU4/(1) AAS
オブジェクト指向の概念の話をするときにメッセージって言葉使いませんか？
C++ならメッセージ＝メンバ関数
Javaならメッセージ＝メソッド
言語によって呼び方が違うから概念的な話のときはメッセージといったほうが通りがよい
854: 2021/02/23(火)10:07 ID:B3ih21Pc(1/4) AAS
>>849
「オブジェクト指向も理解出来てないド素人が玄人ぶってよく言う」
の意味がさっぱりわからん
>>848の表現に一切ケチつけられる要素ないと思うけど
855: 2021/02/23(火)10:15 ID:gTQJYaBt(1/3) AAS
> データメンバーの一貫性を保つためだけに使う
いったい何が言いたいんだろう
他人に分かり易く言えないのは自分が解ってないからというケースがある
856(1): 2021/02/23(火)10:18 ID:B3ih21Pc(2/4) AAS
> データメンバーの一貫性を保つためだけに使う
この表現で普通に分かるけど
分からん人もいるのね了解
857(1): 2021/02/23(火)10:20 ID:NIjAanwq(1) AAS
メッセージが何のことかわからないのはワロス
858(1): 2021/02/23(火)10:21 ID:gTQJYaBt(2/3) AAS
>>856
でか口は具体的に説明できてからぬかせ
このハッタリ野郎
859(2): 2021/02/23(火)10:22 ID:7kgSemXY(2/3) AAS
データメンバに対して想定した扱い方だけをさせるようにして予期しない状態の発生を防ぐため、って言えばお気に召したかしら
普通はそれを短く「一貫性を保つ」って言うのだけど
860(2): 2021/02/23(火)10:31 ID:u3MMsI1X(2/5) AAS
>>853
使わない、というか使うな誤解を招くから
SmalltalkとかObjective-Cならわかるけど
C++やJavaのそれはメッセージングではないと考えるのが普通(そう見做せないわけではないが
861: 2021/02/23(火)10:33 ID:B3ih21Pc(3/4) AAS
>>858
？
862: 2021/02/23(火)10:34 ID:gTQJYaBt(3/3) AAS
>>859
１行目は納得
２行目の主観論には付き合ってらんね
863: 2021/02/23(火)10:37 ID:B3ih21Pc(4/4) AAS
>>860さんに同意で
C++やJava界隈だと明確に避けてると見てる
メッセージってのは
864(1): 2021/02/23(火)10:49 ID:7kgSemXY(3/3) AAS
ごめんねおじいちゃん知らない表現を使われただけでそんなに拗ねるなんて思わなかったんだ
865(1): 2021/02/23(火)11:07 ID:u3MMsI1X(3/5) AAS
いや、悪いけど>>859を以って
＞データメンバーの一貫性を保つためだけに使うもんだよ
などと言い切れるのは経験不足と見られても仕方ないと思うよ学生ちゃん
866: 2021/02/23(火)11:13 ID:j4L8+y6t(1) AAS
おじいちゃんとか学生ちゃんとか、おまえらマウンティングしながらじゃないと会話できないのかw
867: 2021/02/23(火)11:54 ID:oVEFpcof(1) AAS
このスレは特にそういうの多いよね
868: 2021/02/23(火)12:46 ID:HLi0yp23(1/3) AAS
昔からこのスレは特に酷いよね
なぜマウントの必要があるのかは少しだけ興味深いけど
869: 2021/02/23(火)13:21 ID:+0nZ2NLW(1/3) AAS
Linuxを使う以上、C++を嫌わないとダメだろ。
870: 2021/02/23(火)13:45 ID:iu17pC6m(1/4) AAS
>>857,864
いや、メッセージはわかってるけどなんでC++スレで？
って話だろ
>>860の言うようにC++界隈ではあまり使わんし
単にイキってるだけにしか見えんw
871(1): 2021/02/23(火)13:46 ID:iu17pC6m(2/4) AAS
>>865
どういう理由で経験不足と判断したか言ってみ
872: 2021/02/23(火)13:47 ID:alqL+AST(1) AAS
オブジェクト指向に関しては、今の人は、昔はメモリが高価だったとでも思っておけば良いよ。
873(1): 2021/02/23(火)13:53 ID:UMWafFvJ(1/4) AAS
>>823
レス?クス大儀であった
自己解決しますた、
外部ﾘﾝｸ:ideone.com
874: 2021/02/23(火)13:59 ID:UMWafFvJ(2/4) AAS
一貫性というのはオブジェクト内部の整合性のこ
とを言いたい
のでは…
※ 個人の感想です
875(1): 2021/02/23(火)14:03 ID:UMWafFvJ(3/4) AAS
C++のメソッドの呼び出しをメッセージと言い出すとウィンドウメッセージと紛らわしい（小並感
ていうかC++においてメッセージと言えるのはメソッドの「呼び出し」であってメソッドそのものではない
（例えば）メッセージ自体は継承メカニズムとは独立の概念なのだから
※ 個人の感想です
876: 2021/02/23(火)14:10 ID:HLi0yp23(2/3) AAS
Smalltalkはほぼ知らんけど
メッセージ式ってのは
セレクタ＋引数のことだったはず
いやこれどうでもいいか
877: 2021/02/23(火)14:18 ID:UMWafFvJ(4/4) AAS
ていうか今にして思えばstd::shared_ptr<IFoo>がIFooのインスタンスに対する所有権を適切に移譲したり管理するので
std::shared_ptr<T>に持たせることにした時点でIFoo自体がリソースに対する所有権を管理する必要はなさげorz
878(1): 2021/02/23(火)14:29 ID:+0nZ2NLW(2/3) AAS
smalltalkなんて誰も使わないのだから、アジソンウェスレイのオブジェクト指向プログラミング入門にそう書かれていたからという理解で良いのでは？
若者もいるので説明しておくと、書店で書籍を買う時代があって、書店に並ばなければ書籍の存在自体わからなかったのですよ。
この本は何処の書店にも並んでいたので、スレの高齢者全員が読んでいます。
この本しかなかったんですよ。
良い本だとは思いませんが、30年たった今でも古書に値が付くはずです。
全員が読んでるので、全員が知っているかのように錯覚する人もいるって事です。
879(1): 2021/02/23(火)16:09 ID:CS53pw6I(1) AAS
C++のオブジェクト指向でメッセージングのワード出してくるのは
継承を説明するサンプルコードで動物の階層もちだしてくるのと同じ功罪がある
理解のとっかかりにはいいが、リアルな実装の段階ではそういうポエムみたいな話は忘れたほうがいい
880: 2021/02/23(火)16:11 ID:feF5fzNV(1) AAS
メッセージ（笑）とか頭おかしい奴が言いそう
881: 2021/02/23(火)16:16 ID:+0nZ2NLW(3/3) AAS
>>879
功もあると御自分で書かれているのでは？
882: 2021/02/23(火)19:10 ID:48JMuLBY(2/2) AAS
>>873
これで本当にいいのか？
コピー代入演算子でムーブさせるのが本当にあなたのやりたかったこと？
std::auto_ptrはこの問題があったからdeprecatedになったんだけど
883: ◆QZaw55cn4c 2021/02/23(火)21:53 ID:tPF8d5Rx(1/2) AAS
>>878
＞書店で書籍を買う時代があって、書店に並ばなければ書籍の存在自体わからなかったのですよ。
私の若い頃を思い出します。
当時、神戸の一番大きな本屋さんでは、どうしたわけだかコンピューター関連書籍の部分だけは黒山の人だかりで、いつも二十人くらいがみんな立ち読みしまくっていて、そういう人ごみを押しのけて本を探さなければならなかったくらいでした
最近右翼になった数学者・藤原正彦氏によれば、もっと古い時代には町の小さな本屋さんであっても普通にそんな状態だった、ときいています、とても信じられませんが‥‥
そういうわけで、アマゾン・ウェルカム！
884(1): ◆QZaw55cn4c 2021/02/23(火)21:57 ID:tPF8d5Rx(2/2) AAS
>>875
私は例のペゾルド教本を何とか C++ に適応させたくて、ペゾルド本の WM 処理・巨大 switch 文を C++ に適合させようと未だに四苦八苦していますが、やっぱり MFC に移っちゃったほうが楽チンなんでしょうか？
885(1): 2021/02/23(火)22:05 ID:u3MMsI1X(4/5) AAS
>>871
あまりに一面的な見方やろ
>>848はカプセル化も多態も、上で話してた関数オブジェクトさえ否定する暴論
よほど拒否反応があるんだろうなー、と
886(1): 2021/02/23(火)22:07 ID:HLi0yp23(3/3) AAS
否定したように見えちゃってるんだな
いろんな人がおるな
887(1): 2021/02/23(火)22:15 ID:iu17pC6m(3/4) AAS
>>885
まあ
> （非静的）メンバ関数というのはデータメンバーの一貫性を保つため「だけ」に使うもんだよ
の「だけ」に引っかかってると思うんだけどそっちの方がどちらかと言うと暴論に見えるよ
888(1): 2021/02/23(火)22:20 ID:u3MMsI1X(5/5) AAS
まぁ関数オブジェクトはある意味当てはまってるかもしれんと思うが
>>887
そっちも根拠書いてね
889: 2021/02/23(火)22:28 ID:iu17pC6m(4/4) AAS
>>888
>>886が言うように「否定」はしてないと思うよ
ってことね
890: 2021/02/23(火)22:44 ID:H7IAWcv9(1) AAS
[selector message]
Objective-Cが良かったな。
891(1): 2021/02/24(水)06:48 ID:Vo6CI9FQ(1) AAS
>>884
やってみるとわかるけど、MFCと同じものを自分で作ってる感じになるね
ARM C++時代に作るとああなるんだけど、
今どきのC++20で作るとどうなるのかは興味深い
892: はちみつ餃子 ◆8X2XSCHEME 2021/02/24(水)15:54 ID:EZ8EgbLC(1) AAS
現代的な Windows のフレームワークとしては C++/WinRT に力が入ってるみたいなんで、
今からはこれを使った方がよさげ
893: 2021/02/24(水)17:47 ID:T43vsud+(1/2) AAS
P/Invokeともこれでおさらば、
と言いたいところだがネイティブC++をwrapするC++/WinRT自体はCLR上の言語なんじゃなかったっけ…
違ったっけ…
894: 2021/02/24(水)20:59 ID:T43vsud+(2/2) AAS
C++/CXと混同すた、orz
895: 2021/02/25(木)00:40 ID:hxonNlh3(1) AAS
C++/CLIだよ（小声
896(3): 2021/02/25(木)12:27 ID:Kp+Bp4Dl(1) AAS
int (int)型のコールバック関数ポインタにて、一応呼ばれるのでnullはマズイけど不要なので空にしたいという場合に
int () { return 0; }という引数が一致しない空関数へのポインタを渡すとまずい事になるんでしょうか？
低レベルの知識がないのでよく分からないんですが、スタックの巻き戻しとかでズレが生じるとかありそうな気がしています
897(1): はちみつ餃子 ◆8X2XSCHEME 2021/02/25(木)14:45 ID:ziL/azOs(1/2) AAS
>>896
使われている ABI による。
x64 環境なら Unix (系の多くの OS) でも Windows でも引数は整数4個分までは
レジスタで渡されるんで、スタックの整合性は壊れないはず。
898: 2021/02/25(木)15:12 ID:bxBNuN1v(1) AAS
>>896
スタックは呼ぶ側で処理するからズレないよ
でないと可変長引数とか実現できないし
>>897
そんなもんは処理系やオプション次第
899: 2021/02/25(木)15:36 ID:SLTnVXDN(1) AAS
静的解析ツールやコード分析で警告が出るだろうから直したほうがいいと思うけどね
900: はちみつ餃子 ◆8X2XSCHEME 2021/02/25(木)15:44 ID:ziL/azOs(2/2) AAS
x64 の一般的な ABI ではもう様々な呼出し規約を使い分けないようになってる。
(cdecl と stdcall が混在していた Windows が例外的で
他は 32bit 時代からかなり統一されていたみたいだけど。)
まあそれはともかくとして、
実際には不要でも適当な値が渡るようにして型を併せるほうが良いとは思う。
不整合を残しておくと強い最適化をかけたときにわけのわからないことになりがち。
901: 2021/02/25(木)16:08 ID:0Aa2beUH(1) AAS
はちみつは見所がある弟子にしてやっても良いと、あわしろ氏が褒めてた。
上下前次1-新書関写板覧索設栞歴
あと 101 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.037s