C++相談室 part154

**デフォルトの名無しさん** · 2021/01/08(金) 17:54:00.55

※前スレ
C++相談室 part153
https://mevius.5ch.net/test/read.cgi/tech/1602339500/

テンプレここまで

**デフォルトの名無しさん** · 2021/01/11(月) 00:43:54.84

posix平行宇宙論

**デフォルトの名無しさん** · 2021/01/11(月) 00:44:15.09

それだと…CPUの負荷や調子によって…同時になるって…事だよ…。

**デフォルトの名無しさん** · 2021/01/11(月) 00:45:46.62

mutex…危ういな…どうしよう…。運に任せて…諦めるか…。

**デフォルトの名無しさん** · 2021/01/11(月) 00:54:29.81

運任せは辛い…。

**デフォルトの名無しさん** · 2021/01/11(月) 01:30:50.91

https://stackoverflow.com/questions/7373202/what-happens-if-two-theads-lock-a-mutex-concurrently
大丈夫だと言っているが…ほんまかいな…と思います…迷信はつきもの。

**デフォルトの名無しさん** · 2021/01/11(月) 01:37:51.07

テストプログラム作ってさっさと検証しろ無能

**デフォルトの名無しさん** · 2021/01/11(月) 01:59:20.31

>>46
信用できないならソースやアセンブリ読めよ。ここで名無しに答えてもらっても、信用できないんだろ？

**デフォルトの名無しさん** · 2021/01/11(月) 03:08:34.69

MutexはOSに依存するので絶対に大丈夫ということはないですが、数々のトラブルを引き起こし最も懸念されたLinuxが安定してきてるので、現在では実用上問題がないレベルにあると思います。

**デフォルトの名無しさん** · 2021/01/11(月) 03:36:14.65

マルチCPUでバスリクエストが同時に出た場合の制御なんて明確に定義されてんだろうが
OS依存だハード依存だと逃げているから見えない不安に怯えることになるんだよ

**デフォルトの名無しさん** · 2021/01/11(月) 06:01:13.69

LinuxのMutexって使いにくいよね
俺はWindowsから入ったからMutexって名前付きが当たり前だと思ってたんだけどLinuxのMutexには名前がない
どうやって複数のプロセス間で同じMutexを使うんだよ・・・って悩んだ
共有メモリなんかでMutexのアドレスを受け渡しするらしいんだけどさ
面倒くさくなってLinux版の同期制御はファイルロックにしちゃった。。

**デフォルトの名無しさん** · 2021/01/11(月) 06:47:08.93

LinuxのファイルロックはNFSで（※私たちにはバグのように見える）仕様通りの動作をするので気を付けたほうが良いですよ。

ユーザーが指定したファイルやディレクトリを不用意に使用すると再現性の無いバグに悩まされます。

**デフォルトの名無しさん** · 2021/01/11(月) 06:56:23.61

>>52
アドバイスありがとう
Linuxで共有メモリの使い方もよく分からなくて
共有メモリも書いてる途中で読み取りされたら困るから
「書いたよー」「読み終わったよー」ってプロセス間同期したいんだけどMutex受け渡しの前に同期処理って・・・
それで共有メモリの読み書きをファイルロックで同期してMutexを渡すかなーって考えてるうちに
もうファイルロックだけでいいんじゃないかってなってしまった

一般的にはどうやってやるのがよかったんだろ？

**デフォルトの名無しさん** · 2021/01/11(月) 07:35:12.79

>>53
結局、「NFSではバグります」と注意したうえでファイルロックを使うことが一般的に行われてるみたいですよ。

逆に言うと、NFSだけ気を付ければ、問題が起きないみたいです。

**デフォルトの名無しさん** · 2021/01/11(月) 08:06:23.60

ちょっとググっただけだけどそんなに難しいかなぁ？
https://www.geekpage.jp/programming/linux-network/book/07/7-41.php

**デフォルトの名無しさん** · 2021/01/11(月) 08:06:43.86

>>54
ありがとう　ちょと安心した

**デフォルトの名無しさん** · 2021/01/11(月) 08:16:58.50

>>55
コード見てみましたけどMutexの作成と共有メモリの書き込みが終わってからforkしてますね
forkした親と子ならそれでもいいんでしょうけど
実際は親子ではないプロセス間でMutex使いたくなったりするじゃないですか
Mutexが作成される前や共有メモリへの書き込み完了前にスレーブがMutexを要求しに来ると困ります

**デフォルトの名無しさん** · 2021/01/11(月) 08:38:54.12

>>51
名前付きも普通にある
sem_open
名前はセマフォだが当然mutexとして使える

目的がメッセージのやり取りならmkfifoも使える

**デフォルトの名無しさん** · 2021/01/11(月) 08:48:31.88

mutexじゃなくて名前付きセマフォなら普通にプロセス間で使えなかったっけ？

**デフォルトの名無しさん** · 2021/01/11(月) 09:14:02.58

>>57
応用力ないの？
>>58-59みたいにセマフォ使うこともできるし、名前付き共有メモリー + Mutexでもいいだろ

**デフォルトの名無しさん** · 2021/01/11(月) 09:22:15.64

>>60
Linuxではファイルロックで良いよ。

**デフォルトの名無しさん** · 2021/01/11(月) 09:28:25.14

セマフォのほうには名前付きあったんですね見落としてました
ありがとう！

**デフォルトの名無しさん** · 2021/01/11(月) 09:39:24.93

あと別のところでソケットを排他リソースで使うというアイデアを教えてもらったことあります
同じポート番号をバインドできるのは1つだけだからこれを排他に使うという案

**デフォルトの名無しさん** · 2021/01/11(月) 09:52:46.06

3年ぶりの建設的なスレだな。

**デフォルトの名無しさん** · 2021/01/11(月) 10:09:50.89

>>61
ファイルロックはロックしたままプロセス死ぬとリブートしても解消できないのがね

**デフォルトの名無しさん** · 2021/01/11(月) 10:39:47.37

>>51
pthread周りはなんであんな仕様なのか謎
CPUのアーキテクチャーを深く知れば合理性を得心できるのかどうか、

**デフォルトの名無しさん** · 2021/01/11(月) 11:25:14.07

>>65
それはファイルロック（flock関数）ではなく、単純にファイルの存在チェックをしているだけじゃないですか？
flockを使ったファイルロックならプロセス異常終了時にOSによってロックが解放されます

**デフォルトの名無しさん** · 2021/01/11(月) 12:46:20.78

ミックスジュースよりセックスジュースが好きですね

**デフォルトの名無しさん** · 2021/01/11(月) 14:25:33.73

唐突に何いいだすねん君は!
(‘д‘⊂彡☆))Д´)ﾊﾟｰﾝ <ミックスジュースよりセックスジュースが好きですね

**デフォルトの名無しさん** · 2021/01/11(月) 14:41:16.25

ラブジュースだろ

**デフォルトの名無しさん** · 2021/01/11(月) 16:14:45.22

39です…。
mutexの信頼性をずーと疑ってたら…POSIXスレッド…pthread_mutex_lockに行き着きました…
ブロックもするそうです…ソース見てたら…カーネルの様です…pthread_mutex_lock_fullであれば…atomic_compare_and_exchange_val_acq…などもあります…テストアンドセットです…
アトミック操作です…しかし…普通にmutexを実装してpthread_mutex_lock_fullが呼ばれるかは…
分かりません…どんなmutexライブラリも最終的に…このカーネルを呼んでるだけだと思います…
呼ばれてるのは…fullではなく…弱い方のpthread_mutex_lockだと仮定しても…カーネルを疑うなんて…
本当に…ナンセンスな話なので…一応…信用して使うことにします…。

**デフォルトの名無しさん** · 2021/01/11(月) 16:55:02.21

39です…。
結局…fullでなくても…atomic_exchange_acqが呼ばれているようです…アトミック操作です…。
なので…みなさん…安心して使いましょう…。

**デフォルトの名無しさん** · 2021/01/11(月) 16:56:14.48

>>72
そこでやめずに、atomic_exchange_acqの中まで追いかけてみませんか？

**デフォルトの名無しさん** · 2021/01/11(月) 16:56:26.10

https://blog.sakasin.net/pthread-mutex-with-glibc
ソースです…。

**デフォルトの名無しさん** · 2021/01/11(月) 21:32:01.48

Debian woody の頃まで posix thread は使い物にならなかったが Debian etch からようやく使い物になった印象だな
当時から利用している身にしては

**デフォルトの名無しさん** · 2021/01/12(火) 05:50:41.37

わりと最近ですね。

**デフォルトの名無しさん** · 2021/01/12(火) 07:34:00.56

woodyって20年くらい前だっけ
最初はJavaVMもグリーンスレッドというVM内の仮想スレッド実装だったんだよね
あれもOSネイティブのスレッドが信用されてなかったからなのかな
もちろん、現在のJavaVMはOSのネイティブスレッド使う実装になってるけどね

**デフォルトの名無しさん** · 2021/01/12(火) 07:44:47.10

Javaといえばブラック何とかプロジェクトがSUNに文句言ってなかったっけ？

**デフォルトの名無しさん** · 2021/01/12(火) 07:45:53.88

Etchが2007年と書いてあるな。

**デフォルトの名無しさん** · 2021/01/12(火) 09:08:57.41

設計思想的なことについて質問があります。
クラスの使い方がよく分かりません。

僕が今何かを作ろうと思ったら、関数の集まりが引数や返り値のやり取りを通じて協調するような設計をしてしまいます。
この引数や返り値が多く複雑になったりしてきたらクラスを用いた設計を考える、という理解は正しいでしょうか？

**デフォルトの名無しさん** · 2021/01/12(火) 09:22:47.73

>>80
正しいかどうかは知らないし気にしないでいいと思うけど、
そういう場合はただのデータの集まりとして構造体（これもクラスの一種だけど）を使うだけでも簡単になるだろうね。

**デフォルトの名無しさん** · 2021/01/12(火) 13:35:30.39

個人的には、一度無理にでも概念(ウインドウとか表示とか作ってるソフトの主要な概念)をクラス名にして作ってみるといいとおも
やってるうちに慣れてくる

**デフォルトの名無しさん** · 2021/01/12(火) 14:01:10.35

そうだね
なにかを題材にしてオブジェクト指向やってみるのがいいと思う
でもウインドウはどうかなー　そもそもUIツールキットをある程度知らないといけないし
GUIってオブジェクト指向らしからぬ部分も多いので

もっとビジネスロジック中心の題材がいいと思うよ　たとえば掲示板システムとか
板には複数のスレがあって、各スレの中には複数のレスが並んでて、スレの書き込むメソッドでレスが1つ増えてーみたいな

**デフォルトの名無しさん** · 2021/01/12(火) 15:56:33.61

>>4 >>11
. を再定義したいと思った

**デフォルトの名無しさん** · 2021/01/12(火) 17:32:55.18

>>82
初歩的な質問なのですが、クラスってモノじゃなくて概念でも良いのでしょうか
つまり、歩く人のプログラムを作るとき、人というクラスが歩くというメソッドを持っていても良いし、歩くというクラスが一歩進むというメソッドを持っていても良いのでしょうか
言語の仕様上はもちろんどちらでも良いと思いますが、どちらの設計の方が筋が良いということはないと思って良いですか？

**デフォルトの名無しさん** · 2021/01/12(火) 17:34:51.31

ナントカ系の関数群みたいに相互に関連し合っているものを
暗黙じゃなく明確化するのがクラスだよ

**デフォルトの名無しさん** · 2021/01/12(火) 17:38:10.34

>>85
「歩く」をクラスにするよりは「歩ける」をインターフェースにしたらどうかな
人間クラスに「歩ける」インターフェースを実装することで「歩く」メソッドがあることを保証できる

対象ドメインをどのようにモデル化するかは状況や要件次第

**デフォルトの名無しさん** · 2021/01/12(火) 19:05:06.19

メタファとして生き物がよく用いられるけどなんだかなあっていつも思う

**デフォルトの名無しさん** · 2021/01/12(火) 19:50:41.34

>>87
「歩け」インターフェースを定義したらインスタンスが歩ける想定であることは自明なのでは…

ちなメソッドは一般にオブジェクトの状態変化を引き起こすﾌﾞﾂなので
命令型プログラミングの範疇であり命令形で命名すうるが正しい

※ 個人の感想です

**デフォルトの名無しさん** · 2021/01/12(火) 19:52:42.41

しかしインスタンスの生成というプロセスは関数型プログラミングから拝借しており、
命令型と関数型のいいとこ取りしようとして失敗した
classベースのオブジェクト志向は

**デフォルトの名無しさん** · 2021/01/12(火) 19:58:16.79

何ベースのが成功なの？

**デフォルトの名無しさん** · 2021/01/13(水) 09:25:15.89

場合によっては歩くクラスもありだと思うよ。
ゲームで次の行動を一つずつ記憶させたい場合とか。
commandパターン、mementoパターンでググって

**デフォルトの名無しさん** · 2021/01/13(水) 09:45:27.73

歩くということは、位置が変化する。
現在位置は人オブジェクトのプロパティなのか？
それでええのか？

**デフォルトの名無しさん** · 2021/01/13(水) 11:14:57.57

>>93
良くね？

>>87
インターフェースって継承される前提のものなんですよね？
どのクラスが「歩ける」を継承するんですか？

**デフォルトの名無しさん** · 2021/01/13(水) 12:34:30.18

>>85
数値化できるものなら何でもオーケーだ
歩行を数値化するにはN個の関節を持つM本の脚をパラメータとし時間経過ごとの接地点と関節の位置をジェネレータみたいに連続的に返すような設計が考えられる

**デフォルトの名無しさん** · 2021/01/13(水) 13:12:01.01

>>94
じゃあ将棋の駒オブジェクトはプロパティとして位置を持っているのか？

**デフォルトの名無しさん** · 2021/01/13(水) 14:09:32.74

俺の考えるOOシステムでは、駒オブジェクトは盤面オブジェクトやルールブックオブジェクトへの参照を持っいる。

駒オブジェクトへ前へ3移動とメッセージを送ると、駒オブジェクトはルールブックオブジェクトと盤面オブジェクトを用いて、移動可能であれば盤面オブジェクトへ自身を移動するようメッセージングする。

**デフォルトの名無しさん** · 2021/01/13(水) 15:31:14.00

intを継承してmyintクラスを作ることは可能ですか？

**デフォルトの名無しさん** · 2021/01/13(水) 15:38:23.35

システム次第でしょ。
もしも将棋の駒が自律歩行多脚戦車だったら、GPSシステムがすべての位置情報を管理してるなんておかしいし。

**デフォルトの名無しさん** · 2021/01/13(水) 15:38:43.61

enum class なら可能。

**デフォルトの名無しさん** · 2021/01/13(水) 20:01:32.91

C++はテンプレートがあるので設計の詳細を先送りできる。
その特徴を生かせるように、プッシュ型を流行らせませんか？
プッシュ型は、前提が少ないので、利用者が自由に組み合わせることが出来ます。

これは、インターフェースによって事前に詳細を設計してしまう方式と真逆かもしれないが、組み合わせによって機能を作ることが出来まっする。

**デフォルトの名無しさん** · 2021/01/13(水) 21:14:51.93

プッシュ型って何？

**デフォルトの名無しさん** · 2021/01/14(木) 06:54:42.42

Caper や Bison でプッシュ型を調べてみるとわかると思います。

**デフォルトの名無しさん** · 2021/01/14(木) 06:59:25.06

あらゆるソフトウェアで使いまわされるライブラリにおいて、詳細が既に決まっているのは不自由なことです。

**デフォルトの名無しさん** · 2021/01/14(木) 07:12:21.89

templateと比べてプッシュ型の利点が分からん。

**デフォルトの名無しさん** · 2021/01/14(木) 07:23:48.43

>>105
プッシュ型はパーサーでよく使われます。
ユーザーが柔軟性を求めるからです。

Caperはプッシュ型、Bisonはパーサー側が文字を読む方式ですが、オプションとしてプッシュ型を選べます。
パーサにおいてプッシュ型とは、（パーサではなく）パーサを呼び出す側が文字を送り込みます。

それによって何が起きるでしょうか？
従来のパーサーは状態と共に行番号を保存します。
プッシュ型の場合、行番号を保存するのは呼び出し側です。

パーサーが読む文字とは何でしょうか？
プッシュ型において、Cではint、C++ではユニコード。コードポイントです。
文字デコードを行うのは、呼び出し側です。

では従来のパーサでは？
行番号を管理するためには、文字デコードもパーサーの仕事です。
つまりパーサーは大きな塊でアリ、組み合わせる部品ではありません。

**デフォルトの名無しさん** · 2021/01/14(木) 07:27:04.63

プッシュ型はUNIXに通じるものがありますが、UNIXでは実現されませんでした。

**デフォルトの名無しさん** · 2021/01/14(木) 07:47:44.25

パーサーは本来、構文解析が仕事です。
しかし、現状多くのパーサーは、構文解析以外の機能を密に結合している。

本来の仕事以外は分離して、小さな部品にすることで再利用性が高まる。
という感じですかね。

これはテンプレートと同じでもろ刃の剣でもあるんですよ。
詳細を設計しないんですから。

しかし、STLの寿命の長さを見て分かる通り、詳細が設計されていないという事は利用者が自由に設計できるという事で、使い出があるんです。

**デフォルトの名無しさん** · 2021/01/14(木) 07:48:23.53

もちろん、パーサーに限った話ではないですよ。
例です。

**デフォルトの名無しさん** · 2021/01/14(木) 09:22:59.17

みんながみんなパーサーを開発する側じゃないからなー
もっと身近な例はないですか？
このようなデザインパターンがプッシュ型だとこうなる、みたいな

**デフォルトの名無しさん** · 2021/01/14(木) 09:29:21.76

>>110
使う側にとって良いことなんですよ。

それと、プッシュ型は万能ではないんですよ。
一部のコンポーネントの部品化に対して利益があるのです。

**デフォルトの名無しさん** · 2021/01/14(木) 10:01:10.49

>>111
身近な例はないかという問いに対しその回答は意味不明では？

**デフォルトの名無しさん** · 2021/01/14(木) 10:15:16.01

まあそうですね。
すいませんでした。

**デフォルトの名無しさん** · 2021/01/14(木) 10:22:13.84

身近な例で利点があるなら広めるのに協力するのもいいが今の時点で利点が分からん。

**デフォルトの名無しさん** · 2021/01/14(木) 15:40:36.18

別にC++だけの問題じゃないんだけど…質問…例えば…エクスプローラのようにファイル一覧出すじゃん…
画像や動画は…サムネイルを出すじゃん…このサムネイルは非同期で更新になるじゃん…
一度開いたら…キャッシュから読み込みたいじゃん…このキャッシュの保存ってさぁ…一意にするのに…
ファイルパス・更新日時・サイズである程度一意になるけど…完璧な一意ではないじゃん…
同じ名前・同じ更新日時・同じサイズで上書きされたら、前の画像がサムネイルに出るじゃん…
どうすんの？

**デフォルトの名無しさん** · 2021/01/14(木) 15:42:53.95

キャッシュなんてそんなものだから…それでいいのかなぁ…

**デフォルトの名無しさん** · 2021/01/14(木) 15:53:35.11

その気持ち悪い｢...｣をやめてくれ

**デフォルトの名無しさん** · 2021/01/14(木) 15:55:13.17

ファイルパスと更新日時で一意になると考えていいでしょ
コンテンツが変更されれば更新日時が進むという前提で
それさえも許せないクリティカルなシステムならファイルの全バイト列から衝突率の低いハッシュ作るとかファイル読むのと変わらんことになる
クリティカルなシステムではキャッシュ使わんな

**デフォルトの名無しさん** · 2021/01/14(木) 16:05:02.51

なるほど…。

**はちみつ餃子** ◆8X2XSCHEME · 2021/01/14(木) 16:09:33.34

https://martinfowler.com/bliki/TwoHardThings.html
> There are only two hard things in Computer Science: cache invalidation and naming things.

計算機科学においては二つの難しいことがあります。
キャッシュの無効化と名前の付け方です。

**はちみつ餃子** ◆8X2XSCHEME · 2021/01/14(木) 16:16:29.09

ファイルシステムによるけど iノード番号だったり
それに近い管理機構で一意に特定できる場合もあるんじゃないの。
サムネイルくらいなら雑でいいやという割り切りもあると思うけど、
ある程度は不整合がないようにする努力もしてると思う。

**デフォルトの名無しさん** · 2021/01/14(木) 23:16:54.98

特徴的な文体はblogでも見た！

**デフォルトの名無しさん** · 2021/01/14(木) 23:49:25.09

スヌープとLRUでおｋ
この2つでダメだという香具師は、
スヌーピングのロジック設計をサボっているか、
メモリをケチって必要量に未達なだけ

**デフォルトの名無しさん** · 2021/01/16(土) 08:13:56.08

おはようございますみなさま、質問させてください

ユーザー定義クラスを作成し、循環参照を防止するためweak_ptrをメンバに持たせています。
そして任意の処理でshared_ptrをweak_ptrに代入し使用したいと思っておりました。
しかし、メンバ関数内部でweak_ptrを使用すると、式にはポインタ型が必要です、旨のエラーが出てしまいます。
調べてみたところ、lock（）でshared_ptrに再度権利委譲するとshared_ptr側から動くのですが、私が初心者な事もあり何か釈然としません（我が儘でしょうか……）
一度weak_ptrに落とし込んだものを再度shared_ptrに戻す部分が引っかかっているのだと思います（気にしすぎですかね）

そこでお聞きしたいのですが、クラス内部で動的に定めたいと思っているweak_ptrを使う際に、これ以外の方法はありますでしょうか？
それとも上記の通りlock()で一時的なshared_ptrに束縛した方がいいのでしょうか？

朝から長文失礼しました

**デフォルトの名無しさん** · 2021/01/16(土) 08:49:06.94

ロックしないと知らない間に参照先のshared_ptrで持ってるオブジェクトが破壊されてても文句言えないけどそれでもいいの？
weak_ptrってそういうものだぞ

**デフォルトの名無しさん** · 2021/01/16(土) 09:17:41.99

>>125
ありがとうございます。
おっしゃる通りだと思います。
納得いたしマスター！

**デフォルトの名無しさん** · 2021/01/19(火) 02:35:16.36

移譲って要は継承せずにオブジェクトとして使うってことですよね？
なぜ「移譲」なんてわけわからない名前がついてるんですか？

**デフォルトの名無しさん** · 2021/01/19(火) 04:45:45.04

移譲じゃなくて委譲な。
転送でもいいと思うよ

**デフォルトの名無しさん** · 2021/01/19(火) 07:52:05.16

代理、丸投げ

**デフォルトの名無しさん** · 2021/01/19(火) 09:18:39.64

日本語の問題だけど移譲は同じレベルに権限等を移すこと、委譲は下のレベルに移すことらしい
委譲は継承より権限の制限があるという含みがあるんだと思う
あくまで人間の組織での比喩なんだろうけど

**デフォルトの名無しさん** · 2021/01/19(火) 09:54:48.36

名前付けるほどのことか？と問われればたしかにそう思う
クラス内で他のクラスオブジェクトを使ってるだけｗ

**デフォルトの名無しさん** · 2021/01/19(火) 11:29:25.06

移譲コンストラクタってC++11まで存在しなかったの？

**はちみつ餃子** ◆8X2XSCHEME · 2021/01/19(火) 11:40:18.61

>>132
はい。 C++11 で導入された機能です。
それまで存在しませんでした。

**デフォルトの名無しさん** · 2021/01/19(火) 16:38:03.96

C++03の頃のプログラミングめちゃくちゃ大変そうだね・・・

**デフォルトの名無しさん** · 2021/01/19(火) 20:00:27.80

「オブジェクト指向？じゃあ継承しなきゃ！共通実装はみんな継承でポリモにしろ！」みたいなノリのクソ設計が溢れかえった時期があって
カウンターとして無理に継承せんでもオブジェクト持って使えばええんやでっていう事に名前付けたのが委譲とかコンポジションとか
しょうもないんだけど継承教に対抗するには名前が必要だったんよ

**はちみつ餃子** ◆8X2XSCHEME · 2021/01/19(火) 21:06:03.25

>>134
そのとおりだよ！
前スレで C++11 (以降) に否定的な意見も出てるが、
使える状況であえて C++03 (以前) を選択したがる感覚はわかんね。

**デフォルトの名無しさん** · 2021/01/19(火) 22:52:29.91

テンプレート使わなければC++03でもいける（かも）

**デフォルトの名無しさん** · 2021/01/19(火) 23:09:23.44

なんか、ここはどこ私はだあれなやついるなｗ
なんでテンプレートが出てくるのか

**デフォルトの名無しさん** · 2021/01/19(火) 23:29:07.70

C++03にはテンプレート無いしな

**デフォルトの名無しさん** · 2021/01/19(火) 23:43:32.07

何を狙ってボケてんのかわからん
解説求む

**デフォルトの名無しさん** · 2021/01/20(水) 19:27:35.22

C++スゲー=俺スゲーしたいだけの学生が増えたんだろ

>>134, >>136
エアプ乙
便利にはなったが、メタプログラミングやってても委譲コンストラクタ無くてもそんなに困らんかったぞ
メンバの初期化には関数の戻り値だって使えただろ、どこで困るんだ？

**デフォルトの名無しさん** · 2021/01/20(水) 19:33:42.85

あ、委譲コンストラクタが無くても、の話であって03と11がどうこうじゃないよ