C++相談室 part140

**デフォルトの名無しさん** · 2019/01/13(日) 05:56:22.70

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

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

前スレ
C++相談室 part137 (正しくはpart138)
http://mevius.5ch.net/test/read.cgi/tech/1535353320/
C++相談室 part139
https://mevius.5ch.net/test/read.cgi/tech/1538755188/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1530384293/

■長いソースを貼るときはここへ。■
　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

**デフォルトの名無しさん** · 2019/01/27(日) 14:26:38.19

>>221
ぼくのかんがえたなんちゃらだよ
あたらしいかどうかしらんが

ちょっと書き方間違えてたな
class Ci: CProperty<int>{ setter,getter}
class Cj: CProperty<int>{ setter,getter}
これでどうだ

**デフォルトの名無しさん** · 2019/01/27(日) 15:41:24.57

>>217
＞「思う」って言っとかないとまた「勝手に委員会を代弁している！」とか言い出すから、
>>200
勝手に人の主張を捻じ曲げるな

というかプロキシクラスの提案は以前にもここであったし有意義な話だと思うんだけど、
それだと基本型ならともかく、クラス変数のメンバ関数は呼べないんだぜ
そこをどうにかする新たな言語機能は必要になる

**デフォルトの名無しさん** · 2019/01/27(日) 16:00:58.63

まぁ、親クラスのメンバにアクセスしたくなることはけっこうあるけどねｗ

**223** · 2019/01/27(日) 16:57:18.32

いや、単にこういう話
CPropety<std::string> Cs {setter, getter};

Cs = "hogehoge"; 　 // これは出来ても
size_t n = Cs.size();　// これは無理

まぁプロパティ絶対要る、って言いたいわけじゃないけどさ
>>189の言うようにあれば使う程度だけど

**デフォルトの名無しさん** · 2019/01/27(日) 17:05:46.66

リフレクションがないのにプロパティだけあっても意味ないだろう

**デフォルトの名無しさん** · 2019/01/27(日) 17:28:45.73

一般に「プロパティ」と言ったとき

- 変数メンバと同じ字面でアクセスできる
- 列挙可能

C#は両方実現してるけどJavaBeansだと後者だけだね。
C++で話題に挙がるのは専ら前者の性質だけのような気がするが、確かに
それだけだとあまり意味がないと思う。

**デフォルトの名無しさん** · 2019/01/27(日) 19:36:10.69

リフレクション知らんかったので調べてみたけど
ttps://ufcpp.net/study/csharp/sp_reflection.html
ファイルから読んだ内容から動的にクラスを作ったりできる、で合ってるだろうか？
確かにプロパティが欲しくなる場面って設定ファイルの読み書きとかだから、
そういうファイルと言語の橋渡しの機能が無いと片手落ちだというのはわかる気がする（合ってるか知らんけど

仮にINIファイルに対する読み書きを自動化するとして
[Key]
value = ほげほげ

というhoge.iniがあったときに
Ini hoge_ini("hoge.ini");
hoge_ini.Key.value = "ふがふが";

みたいなことが、C++でも出来なくはないけど（そのINIファイルに相当するクラスを手動で書けば）・・・
言語に取り入れようとしたら静的型付けやテンプレートとは死ぬほど相性悪いから無理だろうなぁ

**デフォルトの名無しさん** · 2019/01/27(日) 19:45:08.53

気合で何とか。

**デフォルトの名無しさん** · 2019/01/27(日) 19:59:29.75

使ってるエディタにプロパティージェネレート機能でも入れれば？
それくらいしょうもない話。

**デフォルトの名無しさん** · 2019/01/27(日) 20:02:24.90

そのうち入る静的なリフレクションで十分用はたせそう
プロパティが実現するかは知らんが

**デフォルトの名無しさん** · 2019/01/27(日) 20:04:51.92

プリプロセッサ強化しただけ

**デフォルトの名無しさん** · 2019/01/27(日) 22:48:48.02

メタプログラミング・オープンクラスなど、Ruby が遅い理由

obj.f( )
インスタンスの型が動的だから、obj の型と、メソッドf を毎回チェックするから、遅い

ほとんどのケースで、メソッドが変化しないのだから、

インスタンスをfreeze するとか、
JIT の予測分岐みたいなものを採用しないといけない

**デフォルトの名無しさん** · 2019/01/27(日) 22:50:00.96

C++でテストは何を使用してる？

BoostTest?
GoogleTest?
VC++のネイティブC++Test?
そもそもテストは作成しない？

**デフォルトの名無しさん** · 2019/01/27(日) 22:58:11.13

みなさん、そんなに高度なプログラム書いてるんですか？
集団開発してる人間としてはちょっと信じられない。趣味でやるならわかるけど。

**デフォルトの名無しさん** · 2019/01/27(日) 23:00:26.40

商用だけどparasoftのC++Test使ってて、なかなかいいですよ

**デフォルトの名無しさん** · 2019/01/27(日) 23:02:22.43

昔はSoftIceとBoundsChecker使っていたけど

**デフォルトの名無しさん** · 2019/01/27(日) 23:08:30.18

テストは基本手動で確認でしょう

**デフォルトの名無しさん** · 2019/01/27(日) 23:12:29.52

googletest使ってる。準備しやすいし、そこそこ信用できるから。

**デフォルトの名無しさん** · 2019/01/27(日) 23:12:43.73

VC++のネイティブテスト使ってる
しかしGithubあたりでCIするには相性よろしくない・・・

**デフォルトの名無しさん** · 2019/01/27(日) 23:20:00.64

テストなんか手で書こうがフレームワーク使おうが同じ

**デフォルトの名無しさん** · 2019/01/28(月) 02:32:45.22

>>234
ライブラリのように汎用性の高いものは、テスト用のプロジェクト作ってる（そういうのは大体テンプレ使っててビルドに時間を食われるので）。
実装コードの単体テスは、main のド頭で起動時に必ず実行（リリース時は外す)。
専用ツールの必要性を感じた事がないです。

**デフォルトの名無しさん** · 2019/01/28(月) 07:11:36.24

MyClass c;
と
MyClass* c = new MyClass();
は何が違うんですか？
クラスはnewしないと使えないと書いてあるサイトもありますが上記の表記でも使えているようです

**デフォルトの名無しさん** · 2019/01/28(月) 07:24:44.89

「スタック　ヒープ」でググっといで

**デフォルトの名無しさん** · 2019/01/28(月) 07:24:45.02

質問させて
以下のコードで関数functionの引数にクラスhogeのインスタンスのみを受け付けるようにするにはどうしたらいい？

template<typename T>
class hoge {
省略
};

template<typename T>
class fuga {
省略
};

template<ここがわからない>
hogehoge function(わらないclass hoge のインスタンスのみを受け付けたい)
{
省略
}

**デフォルトの名無しさん** · 2019/01/28(月) 07:24:53.78

すみません、使うメモリ管理の方法が違うということなんですね
では、メモリ使用量をほとんど気にしなくていいPC用アプリの場合はnewを使うのは配列を作るときくらいでしょうか？

**デフォルトの名無しさん** · 2019/01/28(月) 07:29:06.39

template<typename T>
hogehoge function(hoge<T> h)
{}

**デフォルトの名無しさん** · 2019/01/28(月) 07:46:48.21

>>246
プログラムの進行によって形態が変化するグラフを表現する場合なんかは
newでないと実装は難しい。

**デフォルトの名無しさん** · 2019/01/28(月) 07:50:40.23

>>248
そういう場合もあるんですね
ありがとうございます

**デフォルトの名無しさん** · 2019/01/28(月) 07:52:22.02

>>246
配列はstl使えばいい
小さい固定長配列ならstd::array
それ以外はstd::vector

**デフォルトの名無しさん** · 2019/01/28(月) 10:26:04.99

>>246
複数のスレッドからアクセスするならnew
あと動的かつサイズが巨大だったらnew
どっちかわからなかったらとりあえずnew
ただし今時生で使うのはご法度なのでスマポで使う

**デフォルトの名無しさん** · 2019/01/28(月) 11:15:40.31

すまぽ使う場合って明示的にdeleteはしないんですか？

**デフォルトの名無しさん** · 2019/01/28(月) 11:21:32.36

内部で明示的にdeleteされてます

**デフォルトの名無しさん** · 2019/01/28(月) 12:04:58.06

中に人がいるってことですか？

**デフォルトの名無しさん** · 2019/01/28(月) 12:18:45.84

sumapoってさ
参照カウント処理はアトミックなの？
シングルスレッドのときにオーバーヘッドは問題ないの？

**デフォルトの名無しさん** · 2019/01/28(月) 12:35:54.44

shared_ptrかunique_ptrかで違う
パフォーマンス気にするなら自分で計測しろ

**デフォルトの名無しさん** · 2019/01/28(月) 12:51:46.26

さすがに今時アトミックなインクリメントをネイティブにサポートしてないようなCPUは考慮不要だろ
そんなゴミデバイスをターゲットにした開発でスマポなんか使うとは思えん

**デフォルトの名無しさん** · 2019/01/28(月) 12:52:40.84

>>251
>ただし今時生で使うのはご法度なのでスマポで使う

そんなことない。C++ の本流は今でも生ポインタ。
ポインタは理解できない人が多くて、そういう人が嫌いがちなだけ。
それは彼女自身が理解できないから。

**デフォルトの名無しさん** · 2019/01/28(月) 13:06:48.75

そやな

**デフォルトの名無しさん** · 2019/01/28(月) 13:20:55.77

そもそも有効範囲を把握できなくなるような行方不明オブジェクトなんかそんなに必要になるかね
GC言語でもそんなの滅多にないわ
大抵のケースではオブジェクトの生存期間と一致する適当な親玉クラスが存在するから、そいつがまとめて掃除するように作るだろ

**デフォルトの名無しさん** · 2019/01/28(月) 14:17:08.44

彼女？

**デフォルトの名無しさん** · 2019/01/28(月) 14:23:26.09

本流が何を指すのかよく分からないが個人的な観測範囲ではスマポ推奨する人間の方が多い
大体ポインタ理解した所でヒューマンエラーが防げる訳じゃないんだからスマポに頼るほうが結果的に楽だと思うがなぁ

**デフォルトの名無しさん** · 2019/01/28(月) 14:40:06.30

いっさいdeleteしないという方針にするならわかるけど混ざるのは嫌だね
いざというときの安全策というのでは曖昧すぎ

**デフォルトの名無しさん** · 2019/01/28(月) 15:18:30.76

RAIIとかデストラクタ書くのめんどいとかでスマポよく使うけど
それでもファクトリ？パターンとか生存期間の明確な管理をすべき場面、戻り値の共変性のために
そこそこ生ポ使うけどな
生ポがご法度とか、お前ご法度言いたいだけちゃうんかと

**デフォルトの名無しさん** · 2019/01/28(月) 15:25:11.18

そりゃdeleteはしない方針ですよスマポ使うんだから

deleteだって言ってるからメモリアドレスを扱いたいのではなくヒープ確保の結果であるポインタとして話をするね

ライフタイム全部管理し切る自信があって、ムーブとか書くのがめんどくさいってんなら生ポでも良いと思う
ただ人間そんなに優秀じゃないので必然性に迫られない限りスマポ使う方が大多数には向いてるし、ヒープ確保の結果としてのポインタが生ポインタである必然性ってそうそう出会わなくない？
（有るなら具体例を示して貰えるととても有難い）

**デフォルトの名無しさん** · 2019/01/28(月) 15:30:59.26

親玉クラスに任せられない時は、実体管理用のクラス作ってるわ。
何とかFactoryって。仮想クラスはオブジェクトスライシングを避けるためにも基本参照でしか使わん。
いい加減ガベコレつけろよ、と。

**デフォルトの名無しさん** · 2019/01/28(月) 16:06:58.04

factoryがunique_ptrじゃだめな場面ってそんなに多いんですかね

**デフォルトの名無しさん** · 2019/01/28(月) 16:34:44.00

そもそも boost や STL って、C++をC++でなくしてしまうことがある
奇妙で変なライブラリだ。

**デフォルトの名無しさん** · 2019/01/28(月) 16:36:58.41

なんか、C++をスクリプト言語化したい人の集まりみたいになってる。
JS や Python みたいな書き方のまま、C++ の速度だけが得られることが
彼らの希望のように思える。

**デフォルトの名無しさん** · 2019/01/28(月) 17:00:48.06

何言ってるんっだこいつ

**デフォルトの名無しさん** · 2019/01/28(月) 17:10:28.91

そういう言語じゃないの？
The Real Stroustrup Interviewで
> I designed C++ so programmers could write code that is both elegant and efficient.
って言ってるけど

**デフォルトの名無しさん** · 2019/01/28(月) 17:37:02.66

>>267
スマポ使うと共変使えなくなるよ
ていうか言語なんて好きに使えや
自分の使い方を他人に押し付けるな

**デフォルトの名無しさん** · 2019/01/28(月) 17:57:23.32

>>271
Stroustrup の定義した C++ は結構美しかったんだよ。

boost と stl によってはものすごく汚くなった。

C++ 98 位でが本当の C++ で、それより後は C++ ではないと思う。

**デフォルトの名無しさん** · 2019/01/28(月) 18:01:22.30

ぼくが考える最強のC++

**デフォルトの名無しさん** · 2019/01/28(月) 18:13:41.58

口だけ達者だからな。スクリプター達は。。。

**デフォルトの名無しさん** · 2019/01/28(月) 18:30:57.19

>>275
お前のことだぞ

**デフォルトの名無しさん** · 2019/01/28(月) 18:32:51.86

>>272
非virtualなメソッドを噛ませたりしてcovarianceを使わないようにしますかねぇ
その手間をかけてもなおライフタイムの管理をスマポに頼りたいです

**デフォルトの名無しさん** · 2019/01/28(月) 18:39:44.25

というか、スクリプターの方がバイナリ・プログラマより圧倒的に多いので
（スクリプト言語の方が習得が簡単なためだと考えられている）、
どうしたってこうなっちゃうな。

でもC++の厳格な書き方は、大きなプログラムを書くときには便利なんだけどね。

**デフォルトの名無しさん** · 2019/01/28(月) 18:40:38.89

？？？？
何を言ってるのか分からんのだが

**デフォルトの名無しさん** · 2019/01/28(月) 18:42:34.38

>>277
そこら辺は結局設計方針でしょ
まぁ共変使う場面もそんなにないけど

**デフォルトの名無しさん** · 2019/01/28(月) 18:45:57.76

美しいとかそんなのどうでもいいんだよ!
C++ってのはなぁ、戦略爆撃機に例えるとB52なんだよ
基本設計は大昔すぎて今となっては古くさい
後付けでゴチャゴチャと魔改造やりすぎたせいで
今時の若造が見ると「なんでもっとスマートにできないのか」って言う
だがな、こいつは戦争の道具なんだ
たかがちんけな美学のために性能や機能は犠牲にしない
必要とあれば何でも貪欲に付けたしていくがそれは時代に迎合したいからではなく
仕事に必要だからやるだけだ
そんなプロフェッショナルのための戦争の道具、それがC++だ!

**デフォルトの名無しさん** · 2019/01/28(月) 18:48:22.51

>>281
嘘コケ。
ただのオナニーだろ。

**デフォルトの名無しさん** · 2019/01/28(月) 19:15:51.56

>>273
c++11以降のauto,constexpr,template変数当たりは必要だと思うけど。
constexprにかんしてはc++14以降だけ

**デフォルトの名無しさん** · 2019/01/28(月) 19:20:45.82

イミュータボォなヴァリューオブジェクトを実装するときにコピコン使うかスマポ使うか悩む

**デフォルトの名無しさん** · 2019/01/28(月) 19:46:05.45

例外安全性考えたらスマポ使わないでやるのは地獄
生ポとかいってるやつはどうせリークしまくりコード書いてるだろ
たとえ例外オフにしてたとしてもな

**デフォルトの名無しさん** · 2019/01/28(月) 19:56:32.74

何言ってんだこいつ

**デフォルトの名無しさん** · 2019/01/28(月) 20:02:46.72

スマポがなかった頃、僕はリークしまくりでしたっていう自己紹介文では？

**デフォルトの名無しさん** · 2019/01/28(月) 20:22:57.30

aho ?

**デフォルトの名無しさん** · 2019/01/28(月) 20:28:40.03

>>247
出来ましたーありがとうm(_ _)m

**デフォルトの名無しさん** · 2019/01/28(月) 21:27:20.71

>>281
C++ 98 位まではここまでごちゃごちゃしてなくて、それなりの
美しさは有ったんだよ。

**デフォルトの名無しさん** · 2019/01/28(月) 21:35:34.93

流れを切って悪いが、コンセプトを使ってクラスを抽象化するのってありだと思う？　仮想関数のコストを払いたくないのが主な理由です。
これに関する指針とか本とかあったら教えてつかわさい。

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/28(月) 22:06:31.16

>>291
あり。
仮想関数はあくまでも実行時のディスパッチが必要な場合に使うもので、
コンパイル時に解決できる多相性はコンパイル時に解決するのが望ましい。

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/28(月) 22:06:58.78

>>287
リークしてるのに気づいてもいないやつらよりいいよ。

**デフォルトの名無しさん** · 2019/01/28(月) 22:23:20.84

>>291
Modern C++ Designは読んだ？
あとはallocator_traitsなんかを調べたら参考になるかもね

>>293
スマポが無いとリソース管理全く出来ないやつとかお断りだわ

**デフォルトの名無しさん** · 2019/01/28(月) 22:27:46.35

例外安全性の困難さを知らないやつほど大口を叩く

**デフォルトの名無しさん** · 2019/01/28(月) 22:35:01.85

お前の業界の話なんか知らんわ
例外使わない&リソース管理は一元化してる業種だってあるんだよボケ
自分が他人をけなしてるから自分もけなされてるってわかってるか？

**デフォルトの名無しさん** · 2019/01/28(月) 22:36:25.09

>>293
メモリー買い足してもダメ？

**デフォルトの名無しさん** · 2019/01/28(月) 22:39:50.87

＞スマポが無いとリソース管理全く出来ないやつとかお断りだわ
ガチで障害者で草

**デフォルトの名無しさん** · 2019/01/28(月) 22:47:52.82

リソース管理一元化の意味わかる人、解説頼む
スマポ使わない理由なのかそれ

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/28(月) 22:49:39.89

std::shared_ptr は、まあ速度的に不利になる場合もあるだろうけど、
std::unique_ptr を避ける理由って C++11 すら使えない環境の場合以外にはないと思うんだが、何かある？

**デフォルトの名無しさん** · 2019/01/28(月) 22:51:28.96

>>299
そりゃ寿命を親玉クラスのインスタンスと一致させられるなら参照カウンタは要らんやろ
渡すところは全部参照でいい

**デフォルトの名無しさん** · 2019/01/28(月) 22:57:22.66

>>300
そら管理責任を背負ってる部分では使えばいいけど、その一元管理されたリソースを使う側には
普通生ポか参照で渡すだろ
そういう場合にunique使う必要は無いし(unique_ptrの参照でも渡すのか？)
sharedにすると逆に管理責任が曖昧になる
特定のタイミングで一括でリソース確保、解放したいようなシステムを想像したらわかるかと

**デフォルトの名無しさん** · 2019/01/28(月) 23:03:29.70

どうせシーケンス図的なもん書かずに大きいプログラムは作らないと思うんだよね。
そうすると解放する場所も一目瞭然なのであまり必要性を感じない。
それに縛られないプログラムもあると思うけど、その場合得てしてC++は向いとらん。

**デフォルトの名無しさん** · 2019/01/28(月) 23:04:18.01

そして人は神クラスを作る

**デフォルトの名無しさん** · 2019/01/28(月) 23:06:28.09

黙ってればよかったものをw

**デフォルトの名無しさん** · 2019/01/28(月) 23:08:56.84

>>300
使ってもいいけど、積極的に使いたくなる状況は意外と少ない
上の人も言ってるように親玉クラスとかスタックの上の方とか管理責任を持ってるところでは使いたければ使ってもいいけど、
そういうときはunique_ptr使わなくてもRAIIで勝手に解放されるでしょ
unique_ptrが本当に有効なのは所有権を他所に完全に引き渡してしまうケースだけど、
値を好んで多用する文化を持ちmoveも使えるC++において、そういうケースってわりとレアだと思う

**デフォルトの名無しさん** · 2019/01/28(月) 23:09:08.50

歴史を再現してて尊い

**デフォルトの名無しさん** · 2019/01/28(月) 23:13:08.96

>>305
>>285
自分が何書いたか読み直そうな

**デフォルトの名無しさん** · 2019/01/28(月) 23:28:08.44

所有権というのがいまいちわからんのだけどclassAがunique_pというデータを所有していたとして、他の関数からunique_pを参照して内容を書き換えるのは何も問題ないんだよな？

生成と破棄をまかせるだけという理解でok?

**デフォルトの名無しさん** · 2019/01/29(火) 00:00:27.39

>>308
unique_ptrについてぐくった？

**デフォルトの名無しさん** · 2019/01/29(火) 00:03:11.11

>>310
ID変えてまで必死だな
「uniqueはコピーできねーよバーカ！」
とでも言いたいんだろうか

**デフォルトの名無しさん** · 2019/01/29(火) 00:04:05.29

>>306
unique_ptrもRAIIじゃん
本当にわかってんのかね

**デフォルトの名無しさん** · 2019/01/29(火) 00:05:28.12

何やってもださいやつw

**デフォルトの名無しさん** · 2019/01/29(火) 00:19:10.99

>>309
この場合所有権といえばそう。

**デフォルトの名無しさん** · 2019/01/29(火) 00:21:22.57

>>312
RAIIしたいだけならunique_ptrがなぜ必要？

**デフォルトの名無しさん** · 2019/01/29(火) 00:52:07.42

自動変数として宣言するには危険なぐらい巨大であるとか
他の構造体なりクラスなりにメンバとして埋め込むのが憚られるような
ばかでかい構造体やクラスを保持するのに使うと便利
この使い方に徹するなら所有権みたいな中途半端なﾌﾞﾂで悩まずに済む

メンバをunique_ptrで保持するクラスはコンストラクタで例外が生じてもリークせずに済むおまけ付き
コンストラクタで例外など起こすなよというのは置くとして…

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/29(火) 03:58:18.59

>>302 >>306
何も全部のポインタを置き換えるべしというわけじゃない。所有権の管理に使う話。
下流には「アクセスを許す」のであって、「所有権を渡す」必要はないだろ。
(渡したい設計のときは渡せばいいが。)
可能なら一環してスマートポインタで扱うに越したことは無いとは思うが、
下流に渡すのは生ポインタにするという方針もそれはそれで悪くないと思う。

>>260 みたいなケースであっても、下流には生ポインタで渡すのであっても
スマートポインタは有用にはかわりないって話。

所有権の観点から見ると生ポインタってのは所有権を持っているか持っていないか
わからない状態ってことで、でも、その中に std::unique_ptr がひとつあれば、
それが後始末をするのだというサインになる。
所有権をどこで持っているのか見た目にわかるので、単純に、読みやすい。

もちろん、一旦生ポインタとして取り出したものをまたスマートポインタに入れたりすると
おかしなことになるのでそうしないように気を付ける必要はあるけど。

例外に対して気をつかうのはポインタを適切に扱うより冗長でつらいのでやりたくないってのもある。

**デフォルトの名無しさん** · 2019/01/29(火) 04:01:02.14

class A
{
Foo* pFoo;
public:
A(): pFoo(new Foo(42)) {}
A(A& other): pFoo(other.pFoo) { other.pFoo = nullptr; }
A& operator=(A& other) { std::swap(this->pFoo, other.pFoo); }
~A() { delete pFoo; }
};

class A
{
std::unique_ptr<Foo> pFoo;
public:
A(): pFoo(std::make_unique<Foo>(42)) {}
};

どっちが間違えにくいかなんて明白だろ
「俺は間違えない」「間違える低能が悪い」とか抜かす奴はソフト品質の勉強してくれ

**デフォルトの名無しさん** · 2019/01/29(火) 04:04:45.84

あと自分の管理下のデータメンバーを参照するポインタをホイホイ外に渡したいだなんて
それカプセル化出来てない証拠だから

**デフォルトの名無しさん** · 2019/01/29(火) 08:17:54.67

突っ込みどころが多いなあ
>>317も>>318もRAIIがあるから不要なケースが多いという主張に対する反論にはなってないぞ

**デフォルトの名無しさん** · 2019/01/29(火) 08:26:37.92

スマートポインタがそのRAIIの代表格なのだが
まさか自分で書けばいいから使わなくていいとか言いたいん？