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/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の代表格なのだが
まさか自分で書けばいいから使わなくていいとか言いたいん？

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

ライブラリを使うのは甘え

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

>>321
普通に直接値を持てばいいでしょ
それでカバーしにくい代表的なケースといえば
俺なら遅延初期化したいケースとか多態性を使いたいケースとかが真っ先に思いつくけど、
スマポ派からはそういう指摘が全然出てこなかったってことは実際それほど困らないことの何よりの証拠だなw

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

>>320
値かポインタかの話でなくでポインタをどう管理するかの話でしょ
値で済む場合が多いなんて一般化できねーし
あと値のことRAIIっていうから誤解されてる

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

初期化の遅延はoptionalがいるから用途として挙げるのは微妙なところ
17使えない場面自体は山ほどあるだろうけどさ

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

deleteの手間を惜しむならコメント書くのもやめればと思う

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

なんなのこの根性論w
便利なものは使えよ
ゼロコストじゃん

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

deleteは手間じゃなくてリスクって認識なんですよね
自分を含めて人間を信用してないからdeleteを書かせない（スマポに任せる）
この文脈で人間を信用してないからコメントは書かせる

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

30年前の議論してるな

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

new/delete するかどうかの話と、 new/delete する場合にスマートポインタを使うかどうかの話とが
ごっちゃになってる人が居るように見えました。

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

deleteはもちろん人間が読むためのもんよ。
リソースの解放なんて副次的なもの。

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

またえらいのがやって来たなw

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

メモリ解放程度ならお仕着せのスマポで簡単かもしれんけどさ
その他のリソース開放も重なると慎重になったほうがいいわ
どうせ別途開放処理書くなら一緒にポインターも解放したほうがコードの対称性もよくなってわかりやすい

しかしリソース開放漏れがOSレベルでしょっちゅう発生してるのなんとかせい

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

リソース開放漏れって、ロックされているの？それは悲しいな

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

>>317
ファクトリパターンを使いつつ、その場では管理せず
ライブラリ内の任意の場所で管理させる場合は？
それまでの間は生ポだよな
>>319
COM全否定かよ

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

>>319
const-ness理解してないのはC++理解してない証拠だから。

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

>>335
ファクトリーからunique_ptrもらって管理役にムーブで渡せばいいだけだろ
生ポ返して「お前がdeleteしとけよ」なんてファクトリー危なっかしくて仕方ないわ

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

>>337
なんでユーザーが受け取ってユーザーが渡す前提なんだよ
経験不足にも程がある

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

ていうかスマポ派は
「スマポ使って楽できる(設計上も問題なく、またそうすべき)場面でもスマポ使わない(または使えない)馬鹿」
を勝手に想定してモノを言ってるから毎回言い争いになるんだと思うが
スマポごときでマウンティングとかおめでてーな

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

そもそもスマポ自体が推奨されるものかどうか。
stl も boost も本当は C++ じゃない。

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

「どうして、人々は、『私は本当は boost を使いたくない』と遠まわしにほのめか
　すのでしょう？」

Why do people seem to insinuate I would rather not use Boost?
Very often here on SO I see notes about boost such as
If you are fine with using Boost...
or
If you can use Boost...

https://stackoverflow.com/questions/33452925/why-do-people-seem-to-insinuate-i-would-rather-not-use-boost

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

>>338
「ユーザー」の意味がわからんが、自分が作ったファクトリーは自分だけが使うから危なかろうとなんだろうと構わないっていう意味で抜かしてるならあんたはマトモな開発者じゃないね

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

Why do people seem to insinuate I would rather not use Boost?
↓
多くの人が、「Boostを使わないほうがいい」、と主張しているように見えるのは
なぜですか？

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

>>342
そこまで自分とこのライブラリ開発者も自分すらも信用出来ないのなら
C++使うべきじゃないよ

だいたいその途中経路全てCopyConstructible, CopyAssignableを要求される文脈が
一度たりとも発生しないという保証が無ければunique使えないよな
ていうか趣味グラマだろお前w

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

なんでユーザーがやる前提なんだ、って聞いて「自分だけが使うから」
なんて発想になる時点でお察しなんだが・・まぁ言ってもわからんだろうな

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

なんだキチガイか
ムーブするっつってんのになんでコピー可能性要求してんだこのキチガイ
ファクトリーが作ったものを管理屋に渡す前になんでヨソにコピーしてんだこのキチガイ

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

RAIIを徹底しましょう。

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

これくらいユーザーの関わるレイヤーがバラバラなのがc++なんだわ。

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

レイヤーではなく勉強量

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

stlもboostもc++でないという人は他の人が作ったライブラリもc++じゃないというんだろ？

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

Python3はPythonじゃないとか言ってPython2使い続けてるゴミみたいだな

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

ビルド速度、コンパイラの安定性もまともに計らずに
ただ新しいものだけ使えばいいってのはただのバカにしか見えないがな。

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

ワロタ

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

たった8年前に標準化されたばかりの超絶最新機能を使いたがるバカにID:+ftC4go9様がお怒りだぞ

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

10年は寝かさないと成熟したとは言えないでしょ
なんならもう少し見て20年

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

たかが新機能に10年も20年も寝かすとかアホか!
・・と言う人はC++の歴史をよく眺めましょう

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

新しい言語が使えなくなっちゃう

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

20年あったらメモリは2^20倍になってCPUの速度も2^20倍ぐらいになる！

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

しかして人間の知能はあまり変わらない
10年で1.01倍くらい

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

年数の問題でなく、単に boost や C++ の設計者が馬鹿なだけだよ。
はっきり言って。

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

で、その新機能とやらで生産性が上がると本気で思ってんのかね？
おめでてーな。

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

>>358
特にCPUの速度に関して本気で言ってんのだったら物を知らないね、あなた。

**デフォルトの名無しさん** · 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

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