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/30(水) 00:04:00.89

企業戦士ﾏｼﾞﾚｽ

**デフォルトの名無しさん** · 2019/01/30(水) 00:19:59.89

「template を使うと、エラーが長くなって判読しにくい」
「template は、不注意に使うと、code の肥大化を招く」
「template のインスタンス化すると、コンパイル時間とメモリー使用量が増大する」

これ以外に、「Other issues」の欄に、無数の問題点が挙がっている。

https://en.wikipedia.org/wiki/Standard_Template_Library

Error messages involving templates tend to be very long and difficult to decipher.
This problem has been considered so severe that a number of tools have been
written that simplify and prettyprint STL-related error messages to make them
more comprehensible.

Careless use of templates can lead to code bloat.[7] This has been countered with
special techniques within STL implementations (e.g. using void* containers internally
and other "diet template" techniques) and improving compilers' optimization techniques.
However, this symptom is similar to naively manually copying a set of functions to work
with a different type, in that both can be avoided with care and good technique.

Template instantiation can increase compilation time and memory usage,
in exchange for typically reducing runtime decision-making (e.g. via virtual functions).
Until the compiler technology improves enough, this problem can be only partially
eliminated by careful coding, avoiding certain idioms, and simply not using templates
where they are not appropriate or where compile-time performance is prioritized.

**デフォルトの名無しさん** · 2019/01/30(水) 00:32:35.94

コンパイル時間が伸びないテンプレートやらジェネリクスやらなんてのはあるの？

**デフォルトの名無しさん** · 2019/01/30(水) 00:36:46.36

「STL で実装されているイテレーターの概念は、最初は理解しにくい」
The concept of iterators as implemented by STL can be difficult to understand
at first: for example, if a value pointed to by the iterator is deleted, the iterator
itself is then no longer valid.

↓実は、英語が良く分からない部分があるが、
「メモリ管理に関して、異なるメモリ・アロケーターが使う異なるメモリープール
を同時に使うようなことは出来ないので、状態依存で振舞ってしまうような
メモリ・アロケーターがちゃんと働く事は、コンパイラが動作を保障できない」
みたいな事かな（何かよく分からない）：
Compiler compliance does not guarantee that Allocator objects, used for
memory management for containers, will work with state-dependent behavior.
For example, a portable library can't define an allocator type that will pull
memory from different pools using different allocator objects of that type.
(Meyers, p. 50) (addressed in C++11).

**デフォルトの名無しさん** · 2019/01/30(水) 00:48:10.51

直訳すれば、
「コンテナのメモリ管理のために使われている Allocator オブジェクトが、
　状態依存の振る舞いを伴って働くことを、コンパイラ準拠は保障しない。」

Compiler compliance does not guarantee that Allocator objects, used for
memory management for containers, will work with state-dependent behavior.

多分、異なったメモリ管理法を使う色々な Memory Allocator があって、
同時に使うことが難しい、というようなことを言っている気がする。

確保されたメモリの先頭アドレスだけを使いたい、というような事でも、
色々な不具合が起きてしまうんだろうか。よく知らないので言ってることも
よく分からない。

**デフォルトの名無しさん** · 2019/01/30(水) 00:52:17.50

smart pointer や unique pointer、各種コンテナ、Array、Vector、Set
など、色々な物がありすぎて、互いにごちゃごちゃして、メモリブロックを
自動開放するような「状態依存」の振る舞いを、コンパイラが保障することが
できない、みたいなことだろうか。

つまり、誰も分けがわからんスパゲッティー状態なので、メモリーリークも
バグも、めちゃくちゃ生じるかもしれないから、危険だよ、と言うようなことかも
知れない。

そういえば、「実装が複雑すぎて訳分からん」みたいなことがどっかに書かれていた。

**デフォルトの名無しさん** · 2019/01/30(水) 00:59:11.93

・C++の言語仕様もごちゃごちゃと勝手に追加された。
　世界中、誰一人として、本当にどうなるかは分からん状態になってる。
　つまり、仕様自体がスパゲッティーになってしまってる。

・STL は、使い方も、実装も、両方複雑で、エラーも解読できない。
　変な決まりと直感に反する振る舞いが多くて、汚くて使いもんにならない。
　仕様が変 ---> 実はバグと同じ。

・これらが両方あいまって、「STL はどう振舞うか保障できません」　
　と英語版 Wikipedia に書かれているのかもしれない。

こんな危険ライブラリ(?)は使うべきじゃない。生産性が逆に下がる。

**デフォルトの名無しさん** · 2019/01/30(水) 01:01:19.96

もうちょっと読解力とSTLへの理解高めてからそういう主張をされたらいかがか・・・

**デフォルトの名無しさん** · 2019/01/30(水) 01:05:47.40

>>370
あんたが読解してみろや。

Wikipediaが、変な英語書いてとるだけかも知れんで。

**デフォルトの名無しさん** · 2019/01/30(水) 01:12:49.83

> 世界中、誰一人として、本当にどうなるかは分からん状態になってる。
さすがにこれはない
俺みたいなチン毛みたいなC++グラマーですら、9割がた理解しとるよ
残り1割はもみ手しながら神に祈ってるけど

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

for example, if a value pointed to by the iterator is deleted, the iterator
itself is then no longer valid.

↑STL, こんなんアホ仕様じゃん。

「イテレーターが指している値が削除されたら、イテレーターそれ自体が
　もはや無効になってしまう」

こんなアホ実装しか出来ない、技術のないやつが作ったライブラリが「標準」になって
しまうのが、今の C++ 委員会の実体だ。

こんな状態だから、世界中が引きづられて、地球の生産性が下がっていく。

アメリカ人は馬鹿設計しかできん。だからバグだらけなんだ。

**デフォルトの名無しさん** · 2019/01/30(水) 01:17:13.07

>>372
実世界で天才と言われているオイラが、STLや今のC++は汚いとしか思えないけどな。

**デフォルトの名無しさん** · 2019/01/30(水) 01:39:47.40

Allocator周りへの不満はあるだろうなと思うけど
削除された値を示すイテレータに正しい内容か不正だと通知を入れるのは
あまりにもコストが大きいからやってないだけだと思う

**デフォルトの名無しさん** · 2019/01/30(水) 01:45:57.91

>>369
お前の言ってる事もSTL並みにゴチャゴチャやで。

**デフォルトの名無しさん** · 2019/01/30(水) 01:56:09.46

>>376
STLの方がまだ理屈が通っている分、難解だとしても理解しやすい。

**デフォルトの名無しさん** · 2019/01/30(水) 02:00:39.54

>>362
確かに年2倍は盛ったがシリコンの比例縮小則が続く限りクロックは伸び続けるはず…
リーク電流による爆熱はHigh-Kで対策されたし
マルチコアに向かう流れは業界の怠惰にすぎず、物理的制約のせいではない…！

**デフォルトの名無しさん** · 2019/01/30(水) 02:03:01.61

>>373
それがアホ仕様だとすると、たとえば std::vector の iterator は対応する要素が削除された後
どのような状態になるべきだとおっしゃるのか？

**デフォルトの名無しさん** · 2019/01/30(水) 02:10:35.13

std::move、std::forwardと右辺値参照の関係とか特にtemplateが絡むと分かりにくいな。
まぁ、ライブラリ作るときに気をつければ良いだけだから、比較的どうでも良い問題ではあるけど。
STL自体はそんなに難解でもなくない？
コンテナのAllocatorは実際に差し替えて使ってるやつなんてあんまりいないと思うしw

**デフォルトの名無しさん** · 2019/01/30(水) 02:25:53.25

allocatorに無頓着な人って本当にc++使う必然性あるか考えた方がいいと思う

**デフォルトの名無しさん** · 2019/01/30(水) 02:35:48.20

実際にアロケータ差し替えて使ってるとちょこちょこ「アレ？？」
って思うとこはあるんだよね
まぁ文字コード周りがクソと言われがちなのと同じで、
使う奴が少ないところは結構微妙だったりする
(代替案としてpolymorphic memory resourceは出てきたけどまだ使い倒してないからよくわからん、
メモリの確保に普通型なんか関係無いから、型に依存しなくなったのは便利だなと思うけど)

**デフォルトの名無しさん** · 2019/01/30(水) 02:56:49.38

難しいことよくわからんけど、tupleの要素取り出すのがstd::get<index>(var)なの嫌い
var.get(index)になぜ出来なかったの

**デフォルトの名無しさん** · 2019/01/30(水) 03:09:37.94

indexはコンパイル時定数じゃないといけないし
テンプレート引数だからvar.template get<index>()とか書かないといけないからじゃね
constexprに出来る文脈ならvar.get(index)にできるだろうけど・・
(個人的にはvar.template get<index>()でいいからそう書けるようにもして欲しかったw

**デフォルトの名無しさん** · 2019/01/30(水) 07:03:31.67

pairもarrayも生配列も同じように使えるようにじゃなかったっけ？
同じ理由で今はv.begin()よりstd::begin(v)が推奨されてるよな

**デフォルトの名無しさん** · 2019/01/30(水) 08:50:33.43

あ　た　り　ま　え　　だ　が
STLは”勉強していない奴”のことは”想定”していないからな
だから”わかりにくい”とか言ってる奴は”勉強不足”の”論外”な人間なわけ

**デフォルトの名無しさん** · 2019/01/30(水) 09:01:51.07

まあC++は人をふるい落とすための言語だからな。
別に書きやすいわけではない。

**デフォルトの名無しさん** · 2019/01/30(水) 09:06:27.12

わかりにくいとか使いにくいとかいう批判をされても作ってる人も使ってる人もふーんとしか思ってない
誰にでも使えるようにだとか寄せ集めのチームの生産性を上げるだけとかは全く考えてない
そういうのはC#の仕事

**デフォルトの名無しさん** · 2019/01/30(水) 12:23:30.32

何言ってんだこいつ

**デフォルトの名無しさん** · 2019/01/30(水) 12:52:40.78

確かにstlの基本ぐらい勉強しろとおもうけど
標準ライブラリ全体になるとかなり無理げーでしょ
肥大しすぎだわ
説明読んでも意味不明で、意味理解したときはむしろc++に絶望を感じる

作ってる人は使ってるひとのこと考えてるとは思えないね
別に数行短くなるとかどうでもいい

**デフォルトの名無しさん** · 2019/01/30(水) 13:39:29.80

全容把握はやる気せんわ>STL。
上でも出てるけどallocatorみたいな問題あるし、そこは付き合ってらんない。

**デフォルトの名無しさん** · 2019/01/30(水) 14:02:07.62

>>387 >>388
でも、C++ の生ポインタや自作リストクラスで十分だと思ってる人が、
unique pointer や smart pointer や container を使うとすれば、
分かり易くなければ意味がない。

分かりにくければ、生ポインタ以上に危険になってしまいかねない。

**デフォルトの名無しさん** · 2019/01/30(水) 14:48:48.06

shared_ptrとコンテナはまあわからんでもないが
unique_ptrが難しいと騒いでる奴は何が難しいと思ってるのかさっぱりわからない
リアルにも結構いるけど

**デフォルトの名無しさん** · 2019/01/30(水) 14:50:08.15

unique打つのが難しい

**デフォルトの名無しさん** · 2019/01/30(水) 15:02:56.56

ゆ・・・ゆにきゅー・・・

**デフォルトの名無しさん** · 2019/01/30(水) 15:07:10.83

＞unique_ptrが難しいと騒いでる奴
そんな奴居たか？

**デフォルトの名無しさん** · 2019/01/30(水) 17:37:34.50

「unique_ptrが難しいから使わないんだ」
「スマポが難しいから使わないんだ」

っていうレベルで考えてるやつがいたとは驚き
周回遅れっすなぁ

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/30(水) 17:48:26.91

>>396
理解が難しいと言ってるやつはあまりいないと思うが、
このスレでは「使いどころが難しい (使える場面は思ったよりずっと少ないのであまり有難みがない)」
という主張はよく出てると思う。

std::unique_ptr の価値を十全に感じたいならば、
一貫して std::unique_ptr を利用する必要があるが、面倒くさいし、
様々なライブラリを組み合わせようとするとそうもいかないこともあるというのは確かにある。
現実は非情である。

私自身はとりあえず部分的な利用であっても、
(少なくともその箇所では) 例外に対して面倒くさい配慮をしなくてよいってだけで充分にありがたいと思うんだけどな～。

**デフォルトの名無しさん** · 2019/01/30(水) 18:20:07.90

いや俺もこないだ色々言ったけど便利だと思うよ
スマポの利便性の否定なんてしてないし使えるときは積極的に使ってる

ただ「全部スマポ使え、そうでないやつのコードは危険」
みたいなアホなこと言い出すやつが出てきて毎回話がおかしくなる
(全部スマポにするのも一つの設計方針ではあると思うけど・・・
どんなメモリ管理のケースにも対応できる、なんて自分は断言できないけどなぁ)

**デフォルトの名無しさん** · 2019/01/30(水) 18:32:35.81

半角ｶﾅのときと似てるな

**デフォルトの名無しさん** · 2019/01/30(水) 18:47:36.15

スマポ使わない奴は死刑にする法律ができても良いくらい。
スマポを使わなかったせいで飛行機が落ちたり電車が衝突したりしてるからな。
住之江の自動運転が衝突したのもスマポ使ってれば防げたしな。
何人殺せばスマポ使うようになるんだってお話。

**デフォルトの名無しさん** · 2019/01/30(水) 22:03:27.11

スマポで物理的な障害を防げるのか
万能だな

**デフォルトの名無しさん** · 2019/01/30(水) 22:05:55.39

プログラムの小さいバグで大事故は割とある話
スマポ案件は知らないが

**デフォルトの名無しさん** · 2019/01/30(水) 22:12:36.60

数値計算のオーバーフローだかゼロ除算だかでスペースシャトル落ちたんやで

**デフォルトの名無しさん** · 2019/01/30(水) 22:12:59.37

そんなに凄いなら、次世代OSでも採用されるでしょうね

**デフォルトの名無しさん** · 2019/01/30(水) 22:27:00.90

いや、住之江自動運転衝突で調べたら物理だったw

**デフォルトの名無しさん** · 2019/01/30(水) 22:27:27.73

bool 値インクリメントで放射線事故なんてのもある。
スマポだって要らんretainして事故が起きる可能性がある。
エラーを防ぐのは人の仕事であって言語や処理系、ライブラリではない。

**デフォルトの名無しさん** · 2019/01/30(水) 23:40:14.23

>>407
ならスマブ発明しろよ。

**デフォルトの名無しさん** · 2019/01/30(水) 23:58:05.04

boolのインクリメントはもう駄目にならんかったっけ

**デフォルトの名無しさん** · 2019/01/31(木) 01:03:44.53

ブールの++は禁止されるね。

スマートブールつ
struct Bool {
enum class Value { True, False };
Value value;
// その他I/Fはお好みで、でも++とか上書きしないように。
};

**デフォルトの名無しさん** · 2019/01/31(木) 11:58:25.10

>>410
Trueがゼロとかキチガイかよ
結局Valueがそのまんま外に出てて、単なる enum class と比較して全く何の意味もないし

**デフォルトの名無しさん** · 2019/01/31(木) 12:04:22.91

やるなとお達しがきたことをやろうとするなよ

**デフォルトの名無しさん** · 2019/01/31(木) 12:41:33.66

struct を class に置き換えるなり好きに使えよアホ。挙動に制限つけたブール定義するのは簡単って意味。多少面倒でも人殺すよりまし。

キャストとかimplicitコンストラクタとか型安全な範囲で定義してね。
思考力無いんか？　猿なの？　お前みたいなの職場にいたらガン無視。ナスと出世目の前にぶら下げて使い倒して、年食ったら捨てるわ。

**デフォルトの名無しさん** · 2019/01/31(木) 13:10:00.69

>>413
知らんがな
413の頭の中には完璧にタイプセーフなぼくのかんがえたさいきょうのboolがあるのかもしれないが、
>>410のコードから単なる馬鹿と優秀な413の違いを読み取るのはさすがに無理がある
俺達に見えてるのはお前のレスの文面だけなんだから、馬鹿だと思われたくないなら馬鹿に見えないようなレスを書きなさい

**デフォルトの名無しさん** · 2019/01/31(木) 13:31:27.74

バカに物事を説明すんの大変なの忘れてたわ。

**デフォルトの名無しさん** · 2019/01/31(木) 13:43:59.16

大入するときいちいちBool::Value::Trueとかってやるの？

**デフォルトの名無しさん** · 2019/01/31(木) 13:57:43.91

ラフスケッチって言葉知ってる？

**デフォルトの名無しさん** · 2019/01/31(木) 16:17:54.16

ラフスケッチだったのか
下手すぎて知恵遅れの落書きと区別付かんかったわ

**デフォルトの名無しさん** · 2019/01/31(木) 16:53:45.33

このスレって、昔デパートの屋上とかでやってた
マングースvsコブラみたいなおもしろさがあるな

**デフォルトの名無しさん** · 2019/01/31(木) 17:57:23.79

こういうつまらんネタに食いついたら負け

**デフォルトの名無しさん** · 2019/01/31(木) 18:40:23.44

キャットファイトでしょうに

**デフォルトの名無しさん** · 2019/01/31(木) 19:14:06.04

落書きレベルのトリックで回避できる問題が10年以上放置されてるのがC++。

**デフォルトの名無しさん** · 2019/01/31(木) 19:31:16.26

>>410だと何がスマートになるの？
trueとfalseは逆にするとして。

**デフォルトの名無しさん** · 2019/01/31(木) 19:48:03.87

暗黙型変換と人が「普通に」書いてしまう演算からbool値の持つ論理的な意味を守れる。

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/31(木) 19:53:56.29

bool は整数型のカテゴリに入ってるから
整数型同士の演算の中ではうっかり int に昇格されたりするんよ。

**デフォルトの名無しさん** · 2019/01/31(木) 20:36:17.65

だったらexplicit operator boolも書いとけばいいのに
誰でも落書きできる所までしか書かないから知恵遅れに見える

**デフォルトの名無しさん** · 2019/01/31(木) 20:48:55.70

boolの問題なんてさんざん語りつくされてる話題なわけで
そんなにいきり立つのも知恵遅れに見えるんだが

**デフォルトの名無しさん** · 2019/01/31(木) 20:52:11.62

そもそもこのスレに新規性なんかないじゃん

**デフォルトの名無しさん** · 2019/02/01(金) 18:33:11.64

pimplって具体的に何が凄いのが実感出来ない‥
実感できるコード例ってありませんか？

**デフォルトの名無しさん** · 2019/02/01(金) 19:20:32.36

コード例は示せないけど
dllとかlib作るときに使ってみるといいと思う

**デフォルトの名無しさん** · 2019/02/01(金) 19:48:57.61

つまんないもん見せなくて済むじゃないか

**デフォルトの名無しさん** · 2019/02/01(金) 20:06:34.47

実装を隠したいときに必須なんだが
隠す必要を感じてない人に説明するのは難しいんだよな
必要ない人は一生必要ないからね

**デフォルトの名無しさん** · 2019/02/01(金) 20:26:30.63

必須ではないがな
他にも方法はある

**デフォルトの名無しさん** · 2019/02/01(金) 20:35:32.21

>>429
Qt使ってみればわかるよ。
コンパイル早め、デバッグ難しすぎ。
そんな感じ。

**デフォルトの名無しさん** · 2019/02/01(金) 20:44:11.59

インターフェース準備してスマポ返せばええやんけpimplなんぞいらんしって思いました

**デフォルトの名無しさん** · 2019/02/01(金) 20:46:34.12

>>435
設計の本には、実装を隠ぺいすることで変更に強くなると書いてあるけど、Qt見ると、いい部分も悪い部分もあるね。

**デフォルトの名無しさん** · 2019/02/01(金) 20:47:43.65

各種OSに対応するには、pimplが良かったのかもしれない。

**デフォルトの名無しさん** · 2019/02/01(金) 20:50:18.54

実装を隠したいならインターフェース使うだけでいい
インターフェースと比べた時にピンプルにはこれといってメリットはない

**デフォルトの名無しさん** · 2019/02/01(金) 20:55:50.49

>>438
設計本の著者は大御所ぞろいだし、身分を明かさず主張しても無駄なのでは。
明かしたらもっと無駄って場合もあるけど。

**デフォルトの名無しさん** · 2019/02/01(金) 20:56:30.95

コンパイル時間が短くなるのがpimplの利点で実装を隠蔽出来るのは副次的なものと何処かで見た気がする

**デフォルトの名無しさん** · 2019/02/01(金) 21:02:05.52

pimplの利点は依存ヘッダを減らせることだと思ってる
真のprivateとかに感動してる人いるけど、あれはなんか違う・・・

**デフォルトの名無しさん** · 2019/02/01(金) 21:07:03.72

開発の効率化=pimpleの利点。
小さな変更で全ビルド5分待ちはやってられん。
一々ヘッダにこんなもん書くかよ、って思ったり思わせたりしないで済む。

**デフォルトの名無しさん** · 2019/02/01(金) 21:49:44.81

>>438
呼び出しコスト
factory経由

あたりがネックになる場合もある

**デフォルトの名無しさん** · 2019/02/01(金) 21:51:57.86

組み込みやってる身としてはpimplは中でnewかまされるのが困る
インターフェースも同様

**デフォルトの名無しさん** · 2019/02/01(金) 22:26:16.19

同じことを思ってplacement newでやる奴を昔作ったけど、std::launderがないと辛かった

**デフォルトの名無しさん** · 2019/02/01(金) 22:26:54.36

別にnewしなても代わりにobj[1000]から&obj[0]、&obj[1]、&obj[2]、…を返すファクトリーにしたら良いんじゃ…

**デフォルトの名無しさん** · 2019/02/01(金) 22:38:43.24

無名namespaceもいいもんだよ

**デフォルトの名無しさん** · 2019/02/01(金) 22:54:58.73

コンパイルエラーで見づらくなるから使わねーわ

**デフォルトの名無しさん** · 2019/02/01(金) 23:17:25.49

クラスの定義をファイルスコープ（風）にしたいときは無名namespaceを使うしかない
static class Foo { ... };と書けたら良いのに！

**デフォルトの名無しさん** · 2019/02/01(金) 23:45:38.78

private namespaceはよ

**デフォルトの名無しさん** · 2019/02/01(金) 23:56:09.24

nemaspace templateが欲しいとたまに思う

**デフォルトの名無しさん** · 2019/02/01(金) 23:58:16.64

ここまでピンプルのメリットすべてインターフェースでも得られる件
・実装隠蔽
・コンパイル時間短縮
・依存ヘッダ最小化
やはり無駄なイディオムだったか
無意味にテクニカルに見せかけてカッコつけたかっただけだろ

**デフォルトの名無しさん** · 2019/02/02(土) 00:15:52.64

インターフェースで依存ヘッダ最小化できるの？

**デフォルトの名無しさん** · 2019/02/02(土) 00:19:23.04

>>452
なんでお前が勝ち誇ってんだよw

**デフォルトの名無しさん** · 2019/02/02(土) 00:22:54.25

上にもあるけどコンストラクタ使えないのは大きな制約だろ

**デフォルトの名無しさん** · 2019/02/02(土) 15:28:45.27

わざと変な名前の名前空間使ってるわ。
なんやらかんやら_WorkingNamespace とか。

**デフォルトの名無しさん** · 2019/02/02(土) 16:20:02.86

変な名前にしなくてdetailかimplでいいぞ

**デフォルトの名無しさん** · 2019/02/02(土) 18:17:31.28

>>455
factoryはだめなの？

**デフォルトの名無しさん** · 2019/02/02(土) 18:28:03.14

templateでコンストラクタ呼び出すとこ全滅するじゃん

**はちみつ餃子** ◆8X2XSCHEME · 2019/02/02(土) 18:38:05.82

隠蔽つったってなぁ、
呼んでも良いのとそうでないのを言語の規則で可視化しようってだけのことで、
なんなら名前規約で「これは外から呼ぶなよ！」というのを徹底できるならば
別にそれでもかまわんのよ。

でも、広く使われるライブラリはキッチリ分けて、
変な使い方をエラーにしてくれた方がありがたいし、
どのくらいキッチリと隠蔽するかは場合によるというか、程度問題よね。

**デフォルトの名無しさん** · 2019/02/02(土) 22:25:17.69

>>459
コンストラクタが必要になったらそこでラッパーを書けばいい

**デフォルトの名無しさん** · 2019/02/02(土) 22:41:55.99

>>459
Factory使えよ
そのテンプレートが現実にどれだけ汎用的に使えたか思い返してみるとわかると思うが、コストラクタを直接呼ぶのは制約が強くなりすぎる
インターフェイスに限った話ではなく一般論として、インスタンスの生成は間に一段Factoryを噛ませたほうがいい