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(水) 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を噛ませたほうがいい

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

左様コンストラクタでFooのファクトリーを呼ぶFooのWrapperクラスでも書いたら一応STL対応はできる気がする
やらないけど

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

Factory が駄目なら Virtualコンストラクタを使えば良いじゃない。by マリー

**デフォルトの名無しさん** · 2019/02/03(日) 05:14:26.28

テスト

**デフォルトの名無しさん** · 2019/02/03(日) 09:30:58.19

・バカ
std::shared_ptr<Pimpl> p = std::make_shared<Pimpl>(a, b);

・賢者
std::shared_ptr<Interface> p = factory->create_shared(a, b);

**デフォルトの名無しさん** · 2019/02/03(日) 09:42:10.45

pimplクラスをポインタで取り回すのは確かにバカだ

**デフォルトの名無しさん** · 2019/02/03(日) 10:02:23.87

ポイントがInterfaceにあるのかcreate_sharedにあるのかよくわからんな。
結局どういう主張？

**デフォルトの名無しさん** · 2019/02/03(日) 10:03:56.22

>>466
factoryがshared_ptrを返すのは愚者だろ
生ポかunique_ptrにした方が必要に応じてshared_ptrへも変換できて自由度が高い

**デフォルトの名無しさん** · 2019/02/03(日) 10:12:34.61

>>469
auto s = factory->create_shared(a, b);
auto u = factory->create_unique(a, b);
auto p = factory->create_raw(a, b);

p->get_deleter()->delete(p);

**デフォルトの名無しさん** · 2019/02/03(日) 10:17:43.87

pimplで共有、占有、手動のライフサイクルをサポートするにはどうすればいいの？

**デフォルトの名無しさん** · 2019/02/03(日) 12:13:54.64

namespaceの名前ってやはり2文字や３文字の短い略称などにするべきだと思いますか？

**デフォルトの名無しさん** · 2019/02/03(日) 12:40:43.63

>>472
いいえ
stdは極めて悪い例であり、決して真似してはいけません