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

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

Visual Studio使ってたらインテリセンスがautoをコンパイル前に展開して表示してくれるけど

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

テンプレート以外で変数がコンパイル前に決まらないことってあるの？
テンプレートならauto使う必要なくね

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

テンプレートだからこそ使いたい。

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

>>653 >>686
経験豊富なプログラマが沢山参加しているのが事実なら、船頭多くして
船山に登る状態なのかも知れない。

**デフォルトの名無しさん** · 2019/03/26(火) 04:01:17.90

>>692
実感として、年々汚くて使いにくい仕様が増えている気がする。

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

>>714
たいていのスクリプト言語は動的型付け
autoと同じと考えてるならレベル低すぎ

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

>>722
仕事で流行ってる流行ってないなんて関係ないだろｗ

**デフォルトの名無しさん** · 2019/03/26(火) 09:42:45.74

流行ってない＝情報がない、人がいない、資産がない＝ゴミ

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

ビジネスの都合しか考えられないゴミ
JavaとかC#使ってれば

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

ビジネスの都合でc++って場合が多いだろ
ここに居るような奴等は

**デフォルトの名無しさん** · 2019/03/26(火) 15:10:01.00

>>727
wとかsとか付いたのが無駄に増えて面倒になったな

int32_t とか uint32_t とか uint64_t とかは賛成

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

>>733
そういう名称の問題だけに限った話ではなくて、結論から言えば、仕様を
多数決で決めてしまうと初心者向けの言語になる。スクリプト言語とかに
近いような。

構造的な問題とか、統一感的な問題とかもあるし、そもそも、C/C++の
良さまで失うような標準仕様だとかも、例えば、boost などの、
stl = standard template library なんかも、ここでは信者が多いかの
用に見えるけど、まるでC/C++とは思想の異なる全く別のスクリプト言語の
ような仕様になっている感じがする。

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

>>734
STL否定している時点で、そもそもC++の想定しているユーザーからは外れているんじゃね
iostreamならともかく

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

>>735
1998年くらいまでのC++はまあまあ良いと思っていたが、それ以後、別の
言語になってきてる気がする。特にここの人はSTL信者が多いが、
実は、98年くらいまでのC++とは似ても似つかないものだよ。
それを使ったコードには、往年の C の片鱗さえも残ってない。
だから、言語名から C という冠を下ろすべきだ。

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

信者も何も標準コンテナ使わずに何使うんだよ
自前で書くとかそれこそダメな方向だろう
eastlなんかでも使用感をなるべく標準に近づけているのに

**デフォルトの名無しさん** · 2019/03/26(火) 18:00:25.71

C++98以前のC++が今より良いってどんなマゾだよ

**デフォルトの名無しさん** · 2019/03/26(火) 18:04:33.55

template自体嫌いなんかな
それもうCで良いじゃない

**はちみつ餃子** ◆8X2XSCHEME · 2019/03/26(火) 18:10:49.26

C++ の仕様に STL などというものは存在しない。
かつて STL と呼ばれていたものは完全に C++ の一部になっているし、
仕様の他の項目と区別する方法はない。
C++ 使いが C++ の機能を使うのは当たり前だ。

気に入らないと思うのは自由だし、良くない部分だって実際あるが、
常識的には標準が用意しているライブラリは言語の利用方法を体現するものであって、
言語の基本思想と極端に乖離してるわけないだろ。

**デフォルトの名無しさん** · 2019/03/26(火) 18:36:42.18

標準ライブラリだからといって使う義務はないわけで
最小限のランタイムで動くnative言語というところがc++を使う理由になってるプロジェクトが多いだろう
その目的にそぐわないのが今の標準ライブラリのデザイン
メタプログミングの遊び場とかしている

ただし20年前と比べるのはどうかと思うが

**はちみつ餃子** ◆8X2XSCHEME · 2019/03/26(火) 18:44:59.17

標準ライブラリをどうしても使わなきゃならんってことはないけど、
使わないための積極的な理由がなきゃ標準を選択するよ。
リソースが制限されているところで使わないっつーならそれはそれでいいよ。
それも出来るのが C++ だからな。

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

結論から言えば、STLはライブラリとしての「センス」が悪い。

POSIX の fopen()系や printf() 系などは使いやすいと思っていたが、
STLにはそれを感じないし、coutも変だったが STLもそれと同じ轍を踏んでる感じ。

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

>>743
お前さんのレスからは、｢僕の好みじゃないからヤダヤダ｣という程度のことしか見えてこない。

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

誰でも頭が良くなる、プログラムが書けるようになる方法が発見される 86052
https://you-can-program.hatenablog.jp

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

メイヤーズは最高に美しいライブラリと言っている

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

すっぱい葡萄
ttps://ja.wikipedia.org/wiki/%E3%81%99%E3%81%A3%E3%81%B1%E3%81%84%E8%91%A1%E8%90%84
　自分のものにしたくてたまらないにもかかわらず、努力しても到底かなわない対象である場合、
　人はその対象を「価値の無いもの」「自分にふさわしくないもの」と見なそうとし、
　それをあきらめの理由として納得し、心の平安を得ようとするものである。
　フロイトの心理学では、これを防衛機制および合理化の例とする。また、社会心理学においては、認知的不協和の例とされる。
　英語には、この寓話を元に生まれた熟語として "sour grapes" があるが、これは「負け惜しみ」を意味する。

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

やっぱりネットは駄目だ。
頭の悪いプログラマが支配してる。

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

>>747
意味不明だな。誰でも入手できるライブラリで、なおかつ、
昔のC/C++より誰でも出来るスクリプト言語よりだというのに。
言ってることが逆さま。

**はちみつ餃子** ◆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だと無駄に大きなバッファ作りがちだったり、バッファの使いまわしによりスレッドセーフでないコードを書きがちであったりする