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

**デフォルトの名無しさん** · 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で対策されたし
マルチコアに向かう流れは業界の怠惰にすぎず、物理的制約のせいではない…！