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/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バイト、と仮定した場合の話。

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

>>843
4バイト整数のN要素の配列を仮定しているが、Cの単純な固定長配列だと
4バイト整数はコピーするのが当然。
ところが、Listだと、「追加」するしかない。動的配列である
Vectorも、基本的には「追加」が基本。そうでなければ「動的」と言わない。

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

vector.data()、basic_string.c_str()はCと同じの配列の連続アドレスを保証する数少ないインターフェースでしょ。

**デフォルトの名無しさん** · 2019/03/28(木) 01:07:32.08

正直stringがゼロ終端を保証したのはちょっとどうかなと思ってる
いや便利なんだけどさ・・

**デフォルトの名無しさん** · 2019/03/28(木) 01:15:59.09

>>853
特に不都合無いのだからいいだろう

**デフォルトの名無しさん** · 2019/03/28(木) 01:39:16.25

アドレスと一緒にバッファサイズを渡せないAPIが世の中に無数にある。ヌル終端は優しさ。

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

そもそも printf が

**デフォルトの名無しさん** · 2019/03/28(木) 05:04:36.64

>>851
なぜかC言語は固定配列でC++だと動的が基本らしい
前提違うのに速度ガーとか言われてもなぁw

◆QZaw55cn4c · 2019/03/28(木) 05:12:10.50

>>855
ヌル文字をデータとして扱えない、という決定的なウィークポイントが発生しますね…
昔、ツールがヌル文字を扱えない、という点が後から発覚してとても困った経験があります

**デフォルトの名無しさん** · 2019/03/28(木) 07:13:39.49

>>851
ようゴCマスター様
マスター様は知らなくてビックリするけど、C++ではvectorやlistは要素数が実行時に決まるときに使うんだ
そして驚くべきことに、Cにも要素数が実行時に決まるときに使うための愚かしい機能がなぜか備わってるんだ
reallocっていうらしいんだけどさ
使うときは確保済みのバッファの長さをいちいち調べて、足りなかったら再確保して必要に応じて要素を全部コピーするらしいっすよ
もちろんそんな馬鹿げたオーバーヘッドを払う奴はC++かぶれのド素人だけだけどな
真のCプログラマは一度確保した配列の自由なインデックスにコピーすることでvectorの無意味なオーバーヘッドを回避し超高速O(1)を実現するのだ

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

なんかツッコもうと思ったら既に>>813に書いてあった

**デフォルトの名無しさん** · 2019/03/28(木) 10:11:22.12

>>857
C++の配列は固定長が基本。
STLやboostは、C++とは異なる。

**デフォルトの名無しさん** · 2019/03/28(木) 11:32:51.21

>>859
>そして驚くべきことに、Cにも要素数が実行時に決まるときに使うための愚かしい機能がなぜか備わってるんだ
>reallocっていうらしいんだけどさ

Cでは、realloc は推奨されて無い。
Cで、要素数が実行時に決まるような集合を扱いたい場合は、自前で
ポインタでリンクする、リンクリストを使う。
毎回それをやると間違いやすいので、賢い人は、自前でリストライブラリを作って
それを用いて操作する。

**デフォルトの名無しさん** · 2019/03/28(木) 11:39:08.71

Linuxのソースなんだけど
close(0) close(1) close(2)って書いてあるの見つけたのだが
これってなんの効果が期待できるの？
ファイルディスクリプタ？だと思っていてオープン等をした値番号だと思ってたけど、0 1 2に該当するのがなんなのかと

**デフォルトの名無しさん** · 2019/03/28(木) 12:01:08.00

stdin, stdout, stderr

**デフォルトの名無しさん** · 2019/03/28(木) 12:18:22.29

iteratorでstartとendの中に納まってることが保証されてるのに
各要素にアクセスするときにまた範囲チェックとかあると無駄やん
そりゃ書こうと思えばいくらでも危険なコードは書けるけど
安全なときはそういうの省いて高速化出来るのがCの良いところなのに
(レジスタの値が知らない間に壊れても正常に動くようにとか言ってるなら知らん)

**デフォルトの名無しさん** · 2019/03/28(木) 12:31:30.80

>>861
固定とか決めつけてるのを別にしても何を言いたいのかさっぱりわからん

**デフォルトの名無しさん** · 2019/03/28(木) 12:34:41.89

>>862
で、そのオレオレ車輪の再発明クソライブラリは
std::vectorやstd::listより何が優れてるの？
範囲チェックしないから高速wなの？

**デフォルトの名無しさん** · 2019/03/28(木) 12:45:22.23

差異があるとすれば、deep copyだね
決めつけ良くない

**デフォルトの名無しさん** · 2019/03/28(木) 12:48:36.64

>>862
ランタイムでサイズが決まる動的配列にリンクリスト使うのはさすがにダメすぎる

**デフォルトの名無しさん** · 2019/03/28(木) 12:56:24.56

>>863
デーモンになりたいんだろうな

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

>>869
そもそも、C で出来ないことは、コンピュータのアーキテクチャ上、ほぼ
絶対に出来ない事。
だから、Vectorが、効率面でCを上回ることは絶対に有り得ない。

**デフォルトの名無しさん** · 2019/03/28(木) 13:05:17.92

>>869,871
ソートはどうなの？（・∀・）ﾆﾔﾆﾔ

**デフォルトの名無しさん** · 2019/03/28(木) 13:06:22.45

春休みでスレの勢いが上がり、スレの品質が落ちた。

**デフォルトの名無しさん** · 2019/03/28(木) 13:22:32.10

義務教育でプログラミングとか教えたら
もっと変なの増えそう
python界隈に来ないで欲しい

**デフォルトの名無しさん** · 2019/03/28(木) 13:29:56.71

>>874
こういう金融とかの兵隊養成用だから競合はしないと思う
https://pbs.twimg.com/media/DwtF98FUwAIU166.jpg

**デフォルトの名無しさん** · 2019/03/28(木) 13:49:18.36

そのへんの化石言語はいい加減消滅させるべき

**デフォルトの名無しさん** · 2019/03/28(木) 13:51:20.07

化石じゃないまだドメイン次第で現役Fortranだってこの間新しい仕様出たし！ってつっかかられるぞ
08をちゃんと実装したコンパイラ出してから言ってくれよって気持ちだが

**デフォルトの名無しさん** · 2019/03/28(木) 14:01:46.15

>>873
お前が言うな

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

_____(コボル)

答え COBOL

_____(フォートラン)

答え FORTRAN

これのどこが問題集やねん！

**デフォルトの名無しさん** · 2019/03/28(木) 14:08:39.40

来年度からこれが流通するぞ

**デフォルトの名無しさん** · 2019/03/28(木) 15:14:03.54

ほんと役人どもがやることはいつもずれてる

**デフォルトの名無しさん** · 2019/03/28(木) 16:17:03.97

>>880
その言葉を見る限り、あなたは日本人じゃない気がする。
この文脈で、あなたが言いたかったのは、
「来年度からこれが流通するぞ」ではなく
「来年度からこれが常態化するぞ」
という事だったと思うから。

**デフォルトの名無しさん** · 2019/03/28(木) 17:38:04.05

>>871
それ言い出すなら逆もまたしかりだろ
extern "C"すればCで出来てC++に出来ないことはないぞ。

**デフォルトの名無しさん** · 2019/03/28(木) 17:39:39.59

だいたいC++にはasmがあるしな
アセンブラで出来ることは出来るんじゃね

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

>>881
おまえらが役人からずれてるんだろ。
日本は公務員のための国やぞ。

**デフォルトの名無しさん** · 2019/03/28(木) 18:20:50.90

それは一理ある
日本は官僚統治国家だから

**デフォルトの名無しさん** · 2019/03/28(木) 18:30:14.54

公僕が・・・舐めてると潰すぞ

**デフォルトの名無しさん** · 2019/03/28(木) 18:32:28.62

888

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

でも、ターゲットにRubyとC++を選択したのは正解だと思ってるよ。

**デフォルトの名無しさん** · 2019/03/28(木) 18:43:27.34

Rubyはない

**デフォルトの名無しさん** · 2019/03/28(木) 18:45:09.06

日本政府は日本人と将来の日本の年金などのための政治を行えばいいのだから、
日本人が作ったものを使うように推進するのは悪いことではない。
余りにも使いにくいもので無い限りは。
だからWordをやめて一太郎を使うようにしたり、Rubyを使うようにしたり
するとすれば、それは英断だよ。

**デフォルトの名無しさん** · 2019/03/28(木) 18:45:11.14

RubyはWindowsでまともに動かないから、Linux採用するのかな。

**デフォルトの名無しさん** · 2019/03/28(木) 18:48:52.21

>>892
自分の環境では、Windowsで普通に動いてると思ってるけど。

**デフォルトの名無しさん** · 2019/03/28(木) 18:49:56.61

関数型教えればいいのに。

**デフォルトの名無しさん** · 2019/03/28(木) 18:58:40.35

教えるなら実用性と手軽さからしてC++、Javascript、python

**デフォルトの名無しさん** · 2019/03/28(木) 18:59:00.99

>>883
えっ配列初期化子がC++でも使えるように？

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

>>891
国産のを応援するのは判るが
それが利権になってただのクズが集まって来たり
金貰うと進歩が止まったりするのが日本の悪いところ

**デフォルトの名無しさん** · 2019/03/28(木) 19:04:55.98

国産であっても良いものでなければ応援するべきではない
Rubyは滅ぶべき言語トップ10に入る

**デフォルトの名無しさん** · 2019/03/28(木) 19:07:54.30

>>896
書き方同じじゃなくても同様の事が出来るだろ
cで出来ないこと無いって話にたいしてなのだから

**デフォルトの名無しさん** · 2019/03/28(木) 19:20:56.01

PythonとRubyだったら、Rubyもそんなに悪くは無いと思う。
Pythonは可読性が悪いように感じる。空白インデントだけでブロックや
関数の終わりを決めてしまうので、内部関数が終わってるかどうか分からず、
人の書いたソースが読みにくくて困ったことがある。

**デフォルトの名無しさん** · 2019/03/28(木) 19:39:26.72

C++er的には
動的型の時点でノーサンキューだろ
そういうのが嫌でC++使ってるんじゃないのか

**デフォルトの名無しさん** · 2019/03/28(木) 19:40:51.32

特にRubyは教祖様が
絶対に型は書きたくない
って駄々こねてるから

これはもう日本のガラパゴス化が一層激しくなるな

**デフォルトの名無しさん** · 2019/03/28(木) 19:43:44.68

pyは読みより書きの方が問題
間違えてインデントけずっても気づかないことが多い

**デフォルトの名無しさん** · 2019/03/28(木) 19:51:12.67

>>901
個人的には型のある言語の方が好きだ。
型があった方が、変な問題にはまる率が下がるので開発が速く進む。
大規模開発には絶対、型が必要。
初心者にも大人気言語だった元祖のBASICも、Aが浮動小数点型、A$が文字列型で、
確か、A% が整数型。配列は DIM A(100) や、DIM B%(10,10) などで、
宣言は省略できる場合が多いが、ちゃんと型はあった。
Rubyなどは、A にあらゆる型が入れられるので、関数呼び出しなどが
かなり怖い。間違っていても問題の切り分けが出来ないので「はまったら」大変。
だから、とても慎重にコードを目で見ないといけなくなる。

**デフォルトの名無しさん** · 2019/03/28(木) 19:52:41.47

>>903
Pythonで、良く分からなかったのが、インデントの空白の個数。
2個でも4個でも好きな量を選べるのだろうか？

**デフォルトの名無しさん** · 2019/03/28(木) 19:55:00.97

言語仕様上は揃ってさえいればいい

**デフォルトの名無しさん** · 2019/03/28(木) 19:59:44.37

>>906
やはりそうだったんだ。だから余計に解読できなかったんだな。
エディタでカラムを数えたり、上まで戻ったりして、やっと認識していた。
でも不安が残った。ブロックが終わってるのかどうか物凄く分かりにくい。

**デフォルトの名無しさん** · 2019/03/28(木) 20:02:46.54

今のPythonはカオスだからな
見易い文法目指していたはずが
内包表記やらラムダやら見づらくする文法が増えて推奨までされている

フレーム作るか否かもわかりづらいことこの上ない

◆QZaw55cn4c · 2019/03/28(木) 20:22:58.04

>>851
「実装A, B, C があり、機能 f について、A.f, B.f C.f のそれぞれに、こんなメリデメがあります！」
なら理解できますが、>>820 は、
「A.g, B.f, C.f のそれぞれにこんなメリデメがあります！」
でしょう？それって変じゃないですか？
A.g とかじゃなくて、A.f で比べて欲しいのですが？

**デフォルトの名無しさん** · 2019/03/28(木) 20:33:45.97

>>908
最近の言語全般に言えることだな。
無駄機能入れすぎなんだよ。
クソみたいなシンタックス入れるくらいならライブラリを充実させるほうが正しい。

**デフォルトの名無しさん** · 2019/03/28(木) 20:46:24.22

メリデメっていうやつw
すまんがめっちゃ底辺臭する

**デフォルトの名無しさん** · 2019/03/28(木) 20:56:41.12

ハイクラスの人はなんて言うんだよ。

**デフォルトの名無しさん** · 2019/03/28(木) 21:07:04.95

>>882
お前さんの言い換えた方の日本語もかなり不自然だよ。他人の言葉尻をとらえてどうこう言えるほど、お前さんも日本語が得意な訳ではないだろう。
そもそも、普通の人はそんなことで日本人かどうか気にしたりしない。

**デフォルトの名無しさん** · 2019/03/28(木) 21:20:29.56

>>858
文字列の途中に格納することは新仕様でもできるでしょ？

◆QZaw55cn4c · 2019/03/28(木) 21:28:18.93

>>912
「不正確な略語を口にするのは　doubleplus-unwise である」
という事実をジョージ・オーウェルに学びました、彼は略語と esperant は毛嫌いしていたようです
https://ja.wikipedia.org/wiki/%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9%E3%83%94%E3%83%BC%E3%82%AF

**デフォルトの名無しさん** · 2019/03/28(木) 22:54:40.69

double型の変数a、bがあるとして、
a/bが整数かどうか判定するには

**デフォルトの名無しさん** · 2019/03/28(木) 22:55:53.73

厳密には無理

**デフォルトの名無しさん** · 2019/03/28(木) 23:04:52.64

なぜ>>917はベストを尽くさないのか

**デフォルトの名無しさん** · 2019/03/28(木) 23:06:15.20

標準のコンテナなんて使う理由ある？
遅くて使い物にならん

ストリームなんて実用に耐えれないくらい遅いだろ

**デフォルトの名無しさん** · 2019/03/28(木) 23:08:40.51

もう飽きたからいいよ

**デフォルトの名無しさん** · 2019/03/28(木) 23:14:08.39

ではa/bに最も近い整数はどうやったら出せますのん？

**デフォルトの名無しさん** · 2019/03/28(木) 23:17:25.36

(int)((a + 0.5) / b)

**デフォルトの名無しさん** · 2019/03/28(木) 23:17:26.82

a/bを丸めりゃいいと思うが？

**デフォルトの名無しさん** · 2019/03/28(木) 23:21:48.84

std::round(a/b)

**デフォルトの名無しさん** · 2019/03/28(木) 23:22:20.86

両方の案を採ってC++14ではstd::floor(a / b + 0.5)にｹﾃｰｲ？
C99なら丸め関数あるけど…

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

CにあってなぜC++にないと思った

**デフォルトの名無しさん** · 2019/03/28(木) 23:24:22.62

C99はもはやC++とは別物やし…

**デフォルトの名無しさん** · 2019/03/28(木) 23:33:50.74

丸めって絶対の正解がないからな

**922** · 2019/03/28(木) 23:36:38.79

お恥ずかしい。素で間違えた。括弧の位置が違う。

**デフォルトの名無しさん** · 2019/03/28(木) 23:49:56.39

>>918
それは自分に問いかける言葉だったんじゃ。

**デフォルトの名無しさん** · 2019/03/29(金) 00:05:03.99

>>930
>>918についてはまだ誰も判定精度のベストを尽くしていない件について：
多分
　std::abs((a/b) - ((a/b)の小数以下を丸めた値)) <= std::numeric_limits<double>::min()
あたりがベスト？

**デフォルトの名無しさん** · 2019/03/29(金) 00:08:06.95

>>931
いや、元ネタの話。

**デフォルトの名無しさん** · 2019/03/29(金) 00:09:22.47

上田次郎の言葉。

**デフォルトの名無しさん** · 2019/03/29(金) 00:20:10.55

一太郎は自滅したからなぁ
どうしているのかと思えば名簿の話であんなことしていたのかと・・・
上手くやればいくらでも出来たのに勿体無い

**デフォルトの名無しさん** · 2019/03/29(金) 00:38:09.37

>>931
いやこの場合はイプシロンじゃなくバイナリ一致で比較すべき

**デフォルトの名無しさん** · 2019/03/29(金) 00:53:41.69

まだ428万なのに一勝で400くらいしか上がらなくなったんだけど中堅名乗ってええか？