C++相談室 part141

**デフォルトの名無しさん** · 2019/02/22(金) 03:07:43.52

次スレを立てる時は本文の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++相談室 part140
https://mevius.5ch.net/test/read.cgi/tech/1547326582/

このスレもよろしくね。
【初心者歓迎】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

**はちみつ餃子** ◆8X2XSCHEME · 2019/03/26(火) 19:30:19.23

cout よりも printf が相対的に良いという人はたくさんいると思うが、
iostream が特に駄目ってだけで、
C++ 的に見れば printf がセンスいいとはとても言えんぞ……

**デフォルトの名無しさん** · 2019/03/26(火) 19:31:00.18

昔みたいにドヤ顔してboost使う必要がなくなったのはいいことだと思うよ。標準が充実していってさ。
最初からヌエ的な発展しかありえないのはそういうものだと思うし。

**デフォルトの名無しさん** · 2019/03/26(火) 19:31:45.68

>>747は多分>>743とかに向けたつもりだと思うんだが
なぜか逆の立場の>>749がダメージ受けてるという

**デフォルトの名無しさん** · 2019/03/26(火) 19:34:05.19

あ、すまん逆ではなかったな

**デフォルトの名無しさん** · 2019/03/26(火) 19:39:12.76

ただ、多数決というのは、正しくも良くも無いけどな。

**デフォルトの名無しさん** · 2019/03/26(火) 19:48:04.23

だったら君が最高の言語を作ればいい
設計は君の最高のセンスをふんだんに盛り込んで独裁的にやればいいよ

**デフォルトの名無しさん** · 2019/03/26(火) 19:59:43.01

とりあえず全員ダメージ受けとけ。

**デフォルトの名無しさん** · 2019/03/26(火) 20:35:50.63

stlのないC++なんてクリープ入れないコーヒーみたいなもん

**デフォルトの名無しさん** · 2019/03/26(火) 21:11:51.51

>>740
C++ の仕様にSTLがないって本当かいな、と思って調べたら
確かに n3337.pdf (C++11のドラフト?) には STL という単語が出てないね。
STLのセンスが良いか悪いか、使うべきか使わざるべきか、
その辺について意見を出せるほど見識はないんで、事実の報告だけ。

『プログラミング言語C++』第4版に「STLなんちゃら」って章が
いくつか載ってるから、仕様の言葉だと思ってたわ。

**デフォルトの名無しさん** · 2019/03/26(火) 21:17:41.21

プログラミング言語C++に後にSTLとなるテンプレートライブラリ作ってストロストラウップに勧めに来た奴が居たので
ストロストラウップが試したら、彼が信条とする「良いライブラリ10箇条に全部あてはまってこりゃｽｹﾞｰとなったという
エピソードがあったような
なかったような

**デフォルトの名無しさん** · 2019/03/26(火) 21:25:01.06

STLは俗称だし、定義も曖昧
皆そう呼ぶのが便利だからSTLという呼び方してるだけ

HPの研究所で働いてたAlex Stepanovが発案して94年あたりに持ち込んだっぽい
ライブラリじゃなくて、いわゆる「汎用コンテナ(データ構造)ライブラリ」についてBjarneが重要と考えたチェックリストのほぼ全部にパスした

**デフォルトの名無しさん** · 2019/03/26(火) 21:30:19.89

c++の仕様にSTLが無くてもrange-based forのようにSTLが備えてるbegin,endに依存した構文は出てる。

**デフォルトの名無しさん** · 2019/03/26(火) 21:41:34.25

STLつってもどうせvectorとmapくらいしか使っとらんだろ。
まあそれで十分なんだが。

**デフォルトの名無しさん** · 2019/03/26(火) 21:52:00.50

STLという言葉を発することがもうほとんどなくないか？
stdは使うけど、まあどっちも輪郭のはっきりしない言葉だ

**デフォルトの名無しさん** · 2019/03/26(火) 21:53:11.01

STLは洗練されている。
素晴らしいデザイン。
コンセプトが入ったらさらに洗練できると思う。

**デフォルトの名無しさん** · 2019/03/26(火) 21:58:59.96

>>742
リソースが制限されてるというより、最大限のパフォーマンス出す場合な
つまりリソースがリッチかどうかは直接関係ない
AAAのpcゲームとかね

パフォーマンスそこそこでいいならc++なんか使う理由がない
遊び以外

**はちみつ餃子** ◆8X2XSCHEME · 2019/03/26(火) 22:03:45.01

>>765
計算量はリソースの一種だで。

**デフォルトの名無しさん** · 2019/03/26(火) 22:05:23.77

最大限のパフォーマンスを出すために作ったeastlみたいなのも標準の使用感踏襲するくらいには標準の設計は良くできているよ

**デフォルトの名無しさん** · 2019/03/26(火) 22:05:31.83

STLはわしが育てた。

**はちみつ餃子** ◆8X2XSCHEME · 2019/03/26(火) 22:17:08.86

そうか。

**デフォルトの名無しさん** · 2019/03/26(火) 22:23:19.39

tupleはSTL？

**デフォルトの名無しさん** · 2019/03/26(火) 22:33:50.26

>>767
移行が楽になるようにむやみにapi変えないのはソフトウェアの定石
それより変わったところ、拡張されてるところに注目しようか

**デフォルトの名無しさん** · 2019/03/26(火) 22:49:38.25

C++2zには俺の作ったライブラリが標準搭載されると思う。

**デフォルトの名無しさん** · 2019/03/26(火) 23:13:14.99

天下のマイクロソフトが考えたATLでもいいんだぞ

**デフォルトの名無しさん** · 2019/03/26(火) 23:32:43.00

ATL（adult T-cell leukemia-lymphoma）は語呂が悪い

**デフォルトの名無しさん** · 2019/03/26(火) 23:38:15.00

std::tuppleはPythonフリークが無理矢理ねじ込んだのではないか
C++11で追加された可変長テンプレートなくして有り得なかったコンテナやし
std::pairと被っとる

**デフォルトの名無しさん** · 2019/03/26(火) 23:43:43.21

tupleなんかどの言語にもあるだろ
現代の言語の基本的概念の一つで当然サポートされるべき

**デフォルトの名無しさん** · 2019/03/26(火) 23:49:19.01

ライブラリでサポートだけどな
これがダメなところ

**デフォルトの名無しさん** · 2019/03/27(水) 00:07:37.22

何で？

**デフォルトの名無しさん** · 2019/03/27(水) 00:38:40.54

>>759
じゃあ、ストロストラウップの物を見る目が無い。
彼自身のセンスが悪いんだ。

**デフォルトの名無しさん** · 2019/03/27(水) 00:42:46.01

なんちゃらラウップは言いにくいからいつも
ビョーーンさん、と呼んでいる

**デフォルトの名無しさん** · 2019/03/27(水) 00:47:30.04

tupleは型関数でも重宝するよね

**デフォルトの名無しさん** · 2019/03/27(水) 00:56:42.26

タプルはなにが嫌といって get<0> とかいうのがものすごく嫌
要素が4個ぐらいになったら1年後ぐらいにコード書き直そうとして
・・えっとこの値取りだすの get<1> だっけ？ get<2> だっけ？とか絶対なるから使わない

**デフォルトの名無しさん** · 2019/03/27(水) 00:58:48.50

そんな貴方にenum定数

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

いい加減enumにメンバ関数定義させろと。
enum classの時にどうにかすべきだった気もするが。
後は静的なリフレクションも
enumと文字列の相互変換とか殆ど定型コードになるのにいちいち書くのが面倒すぎる。
マクロで書くのも微妙だし

**はちみつ餃子** ◆8X2XSCHEME · 2019/03/27(水) 02:16:29.42

>>779
センスがあるか無いか知らんけど、
すっぽすっぽ先生が是とした以上は C++ 的ではあるはずだろ。
それが駄目なら C++ が駄目だし、駄目なので君は使わなくていいよ。

**デフォルトの名無しさん** · 2019/03/27(水) 02:25:21.92

標準コンテナ使わないらしい人の
抜群のセンスを見てみたいので、コードの一部でも見せて欲しいものだな

**デフォルトの名無しさん** · 2019/03/27(水) 02:59:41.39

Eigenが絶妙に不便なんだけど行列演算を標準でサポートする予定ってあるの？

**デフォルトの名無しさん** · 2019/03/27(水) 03:31:56.74

>>786
アイデア盗まれるだけ損。

**デフォルトの名無しさん** · 2019/03/27(水) 06:12:39.11

センスが悪いというだけで具体的にどこがどう悪いか、どんなだったらセンスが良いのか言わないと、説得力ゼロだな。

**デフォルトの名無しさん** · 2019/03/27(水) 06:31:30.44

>>743
＋1

**デフォルトの名無しさん** · 2019/03/27(水) 06:40:01.31

>>780
禿

**デフォルトの名無しさん** · 2019/03/27(水) 06:52:27.00

>>784
定型文ならtemplateで書けないの？

**デフォルトの名無しさん** · 2019/03/27(水) 07:12:11.84

>>792
やりたいことは単にenumの値の識別子とその文字列を対応付けるだけなんだが、templateで書けるの？

enum class Color {
Red,
Green,
Blue
};
inline auto to_string(Color c)
{
switch (c){
case Color::Red:return "Red";
...
}
}
こんな感じのことがしたい

**デフォルトの名無しさん** · 2019/03/27(水) 07:24:00.67

マクロ Stringizing Operator (#) を使うしかないのでは。

**デフォルトの名無しさん** · 2019/03/27(水) 07:44:38.63

>>789
×センスが悪い
○自分の趣味合わない
だから説明する必要なし嫌い嫌い言っておけばおk
ちょうど114514回目のstd:get嫌い民も現れたところだ

**デフォルトの名無しさん** · 2019/03/27(水) 07:59:25.35

ストラウストラップも例外入れるかどうかあたりまでは
かなり真剣に仕様を考えてた印象だけれどそれ以降はタガが外れた感じだ。
最近はもうどうしようもなくなってる。

**デフォルトの名無しさん** · 2019/03/27(水) 08:00:04.09

>>793
その処理ならmapかunordered_map使うのが良くないだろうか？

**デフォルトの名無しさん** · 2019/03/27(水) 08:06:10.74

なお誰もストラウストラップに意見を出せるほどプログラミング言語の勉強をしていないもよう

**デフォルトの名無しさん** · 2019/03/27(水) 08:07:01.17

>>797
逆変換はunordered_mapだな

文字列化の方はswitch使うのが一番コンパイラがいい感じのコードにしてくれる

**デフォルトの名無しさん** · 2019/03/27(水) 08:25:16.34

関数の引数として vector<int> を参照渡ししたいのですが、これのデフォルト引数を空の vector<int> にする方法ってありますか

**デフォルトの名無しさん** · 2019/03/27(水) 08:33:50.59

std::vector<int> &v = std::vector<int>() じゃないのん

**デフォルトの名無しさん** · 2019/03/27(水) 08:43:24.12

>>801
参照渡しでもそのやり方できますか？

**デフォルトの名無しさん** · 2019/03/27(水) 08:45:04.79

やればわかる

**デフォルトの名無しさん** · 2019/03/27(水) 09:24:45.56

const？

**デフォルトの名無しさん** · 2019/03/27(水) 09:33:08.23

>>786
センスうんぬんを言ったのはおれじゃないけど、
標準ライブラリ使わないという主張に対して、ソースがエレガントかどうかを問うのは目的がわかってない

端的にいうと標準ライブラリのオーバーヘッドが許容できないんだよ
多少記述が汚くなろうがパフォーマンス引き出すのが優先

cとc++のベンチだと結局cの方がいいスコアになってること多いだろ
(全てがそうでないのは知ってる)
そこをcと同等まで引き上げるわけだ

**デフォルトの名無しさん** · 2019/03/27(水) 09:36:50.33

だったらC使ってれば
それ以外の選択肢無いんだから

**デフォルトの名無しさん** · 2019/03/27(水) 09:40:51.50

>>806
そこはアセンブラ使えばというところだろ

**デフォルトの名無しさん** · 2019/03/27(水) 09:40:55.11

>>804
VC2017だとconstじゃなくてもいけた
てか参照のデフォルト引数ってconst限定だったのか
仕様変わったのかVCだけおかしいのか知らんけど

**デフォルトの名無しさん** · 2019/03/27(水) 09:45:55.40

いうまでもなく、ボトルネックでないところは労力はかけない
メンテが楽な手法を使う
それに完全にゼロコストなものは普通に使うさ

**デフォルトの名無しさん** · 2019/03/27(水) 09:52:34.13

標準コンテナでcより遅くなるってどんなパターン？
単方向listで十分なのにlistだと双方向とかそんなやつ？
あんまりlist使わんからよくわからんが
vectorは使い方を余程間違えない限り大抵代替品より速いような

メモリ確保回りはallocator使えばいいし
data使えばただのメモリブロックだよね

**デフォルトの名無しさん** · 2019/03/27(水) 10:01:31.18

99％iostreamのこといってるからな

**デフォルトの名無しさん** · 2019/03/27(水) 10:04:51.88

>>810
要素の追加時に容量の拡張が必要かどうかのチェックが入ったりするから、オーバーヘッドはゼロではないよ

**デフォルトの名無しさん** · 2019/03/27(水) 10:08:24.05

>>812
それpush_back or emplace_back使っているのが悪いのでは
cの同等コード書いてもチェックは必要だろ
チェック要らんことが分かっているならresizeしておけ

**デフォルトの名無しさん** · 2019/03/27(水) 10:12:49.51

Cで作っても同じでワロタ

**デフォルトの名無しさん** · 2019/03/27(水) 10:22:17.37

>>813
便利なものがあれば人間は使ってしまうもんだ
その積み重ねがパフォーマンスの差に繋がる
俺は一般には便利なものを使って時間を節約することでボトルネック解消にかける時間を確保でき、
結果的にパフォーマンスはより高くなると思うけど、そこはスケジュールの制約次第だな

**デフォルトの名無しさん** · 2019/03/27(水) 10:29:47.46

Cマスター「C++は配列に追加するときにサイズチェックするから遅い(ｷﾘｯ」

ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
こんな雑魚がでかい顔してるからいつまでもセキュリティホールがなくならないんすなあ

**デフォルトの名無しさん** · 2019/03/27(水) 10:34:12.90

Cマスター「要素追加時にサイズチェックするという便利さの積み重ねがパフォーマンスを落とす(ｷﾘｯｷﾘｯ」
やべえ笑い死にしそう
笑い事じゃないけど

**デフォルトの名無しさん** · 2019/03/27(水) 12:49:47.89

プロファイラで調べて本当に問題あるならどうにかするけど
ただわざわざc的に書いても大抵誤差レベルでしか変わらんよね
どちらかと言うとバッファの確保の仕方を工夫した方が効果が大きい

**デフォルトの名無しさん** · 2019/03/27(水) 13:05:12.78

>>816
トレードオフもわからん雑魚

**デフォルトの名無しさん** · 2019/03/27(水) 13:06:52.67

>>810
・以下、要素数が N とする。

・C/C++ の原定義の固定長配列は、要素の代入に1クロックしかかからない。もちろん、
　O(1)で、物凄く速い。なお、固定長なので「代入」であり「追加」ではない。

・Listはリストだから1個の要素の追加はO(1)で、要素数に依存せず安定した速度が出るが、
　内部で、newされるはずなので、最低でも170クロックほどかかってしまう。

・Vectorは動的配列だから、最悪のケースでは要素の追加にO(N)の時間がかかり固定長配列より遅くなる
　と思う（よく知らない）。

**デフォルトの名無しさん** · 2019/03/27(水) 13:34:58.24

>>817
複数の要素を追加するとき、わざわざ事前にまとめてリサイズするか？ということだよ
1要素ずつ処理するのは生ポならかえって面倒になることが多いし、見た目にいかにも非効率そうなコードに見えるから、大抵の人は自然にそうするだろう
一方vectorだとどうだろうね
心理的な問題なの

**デフォルトの名無しさん** · 2019/03/27(水) 13:45:54.22

同じようなことはvectorに限らず一般的に言ええて、
例えばC++はRTTIの便利さ故にCと比較してプログラマが無駄なメモリの確保や破棄を行いやすい傾向がある
逆にCだと無駄に大きなバッファ作りがちだったり、バッファの使いまわしによりスレッドセーフでないコードを書きがちであったりする

**デフォルトの名無しさん** · 2019/03/27(水) 13:46:41.13

すまんRTTIじゃなくてRAIIな

**デフォルトの名無しさん** · 2019/03/27(水) 14:07:44.29

クロックなんてわからんじゃろ

**デフォルトの名無しさん** · 2019/03/27(水) 14:29:28.16

VC++2017なんだけど
デストラクタで投げた例外をキャッチできずabortするのはVC++の仕様？
RAIIとラムダを駆使した自作finally内で
例外投げたらキャッチできずabortしてハマったわ
デストラクタ内で例外投げるのが汚いのは知ってたが
そうか、自作finallyもデストラクタ利用してるからダメなのかな

**デフォルトの名無しさん** · 2019/03/27(水) 14:35:28.06

デストラクタはデフォルトでnoexceptやで

**デフォルトの名無しさん** · 2019/03/27(水) 14:54:30.22

サンクス
デストラクタをnoexcept(false)指定したらcatch出来たわ

てことは自作finallyは念のためnoexcept(false)指定にしたほうが良いのか
それか自作finally内で例外投げるのは完全禁止にするか
悩むわ

**デフォルトの名無しさん** · 2019/03/27(水) 14:56:55.41

まぁでもよく考えたら
例外が発生して自作finallyが実行されてる時に
さらに自作finally内で例外飛ばしたら二重例外になるから危険か
なるほどなるのど

**デフォルトの名無しさん** · 2019/03/27(水) 17:38:06.36

>>820
意味がわからん
そもそもCでも固定長配列の代入は実データのコピーを伴いO(n)だ
アドレスや参照のやり取りならO(1)

**デフォルトの名無しさん** · 2019/03/27(水) 17:50:46.31

全体じゃなくて一要素やろ？

**デフォルトの名無しさん** · 2019/03/27(水) 17:55:38.42

あーそう言うことか
固定長的に使いたいなら始めにresizeするだけじゃない

便利だからチーム内で使ってしまう人がいることを問題にするより、使わずにいちいち独自コードで処理されて余計遅くなったり、バグ仕込まれたりする方が余程ヤバイだろ

**デフォルトの名無しさん** · 2019/03/27(水) 18:00:35.88

先生、配列の長さにリミットを設ける方法を教えてください

**デフォルトの名無しさん** · 2019/03/27(水) 18:00:36.53

まぁそれでも範囲チェックは入るし、常にヒープ使われるし
それすら問題になるようなクリティカルな場所なら生配列なりarray使えばいいと思うけど
適材適所じゃないかねぇ

**デフォルトの名無しさん** · 2019/03/27(水) 18:03:25.00

operator[]なら範囲チェック入らんよ

**デフォルトの名無しさん** · 2019/03/27(水) 18:14:58.29

末尾に追加の話だろ

**デフォルトの名無しさん** · 2019/03/27(水) 18:15:04.13

うお、マジだ誤解してた

**デフォルトの名無しさん** · 2019/03/27(水) 18:20:39.73

>>836は>>834宛
まぁ要素数わかってて末尾に入れてくのはナンセンスやね
速度を気にしない場所ならどうでもいいけど

**デフォルトの名無しさん** · 2019/03/27(水) 18:39:59.51

よくあの時代にこのような洗練されたライブラリを設計できたものだと思います。
もしかすると宇宙人にもらったのかも。

**デフォルトの名無しさん** · 2019/03/27(水) 20:06:12.42

配列の長さチェックのオーバーヘッドとかなんかものすごくデジャブ感のある議論だな。
肯定、否定どちらにしてもマウンティングかましたくなる題材なんかね。

**デフォルトの名無しさん** · 2019/03/27(水) 21:09:05.61

標準コンテナで問題になるのはやっぱりヒープだよ
境界チェックとか仮に無断だとしても一定時間で終わる処理
ヒープ使われると最悪システムコールで負荷変動大きすぎる

ちなみにアロケータは要素数で管理できないから面倒
あとvectorで最初にreserveしても最大長越えないチェックが必要で面倒

でこれらを解決するコンテナがboostにあるのでそれを使う

**デフォルトの名無しさん** · 2019/03/27(水) 21:18:02.40

あと標準ライブラリのリンクリストはそもそもの設計が非効率
(クリーンな設計ではあるが)
素朴なcの実装と比べてかなり差がでる
これも代替がboostにある

**デフォルトの名無しさん** · 2019/03/27(水) 21:25:03.72

>>835
末尾追加の話なら、Cでも同じだけコストかかるだろ。
>>840
arrayならstackに積まれる。

◆QZaw55cn4c · 2019/03/27(水) 21:31:48.60

>>820
なんか変じゃないですか？
list や vector のときは要素の「追加」なのに、生配列だけ要素の「代入」と設定するのですか？
list や vector で要素の「追加」を考察するのなら、生配列の場合も要素の「追加」を検討してください

**デフォルトの名無しさん** · 2019/03/27(水) 21:38:22.09

>>842
arrayは固定長
欲しいのは最大長を事前に確定しつつ、その範囲で可変長で使えるvector
という話ね

**デフォルトの名無しさん** · 2019/03/27(水) 21:45:52.93

ここのCマスター様は、現在の配列長と挿入インデックスのチェックしてreallocしてなんていう
パフォーマンスの悪い便利さに甘えた処理などしない
堂々とv[N]に無条件代入を行って超高速O(1)追加を実現するのだ

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2019/03/27(水) 21:50:08.37

事前のresizeかreserveでええんとちゃう？

**デフォルトの名無しさん** · 2019/03/27(水) 21:51:09.94

事前に分かるならスタック固定長でいいじゃん

**デフォルトの名無しさん** · 2019/03/27(水) 22:02:47.67

reserve あれば困る事なんてないやろ

**デフォルトの名無しさん** · 2019/03/27(水) 23:54:55.06

一般的には無いよ
局所的な話を持ち出してああだこうだ言ってるのが今
そして何をするつもりかは誰も知らん

**デフォルトの名無しさん** · 2019/03/28(木) 00:42:33.33

>>829
要素数がN、データの大きさは4バイト、と仮定した場合の話。