C++相談室 part152

**デフォルトの名無しさん** · 2020/07/12(日) 13:42:20.13

https://mevius.5ch.net/test/read.cgi/tech/1589424805/

**デフォルトの名無しさん** · 2020/09/23(水) 19:48:39.67

仕事で使うならBetter Cで留めるのが正しいC++の使い方。

**484** · 2020/09/23(水) 20:09:34.36

>>493
> std::add_pointer_t<int()> f;
> std::decay_t<int()> f;

（´･∀･`）ﾍｰ
そんなんあるんですね
勉強になりました

>>529
凄くC++らしいと思うけどｗ
意地でもテンプレートで何とかしようというのは

◆QZaw55cn4c · 2020/09/23(水) 20:16:22.00

>>524
確かに、数物系に「特異」な人のコメントにしては貧弱だなあと、私も思いました
たとえばガロア理論、とか、相対性理論、超弦理論、とか、を熱っぽく語って欲しいです

個人的にはエルゴート理論について薀蓄を知りたいですね

◆QZaw55cn4c · 2020/09/23(水) 20:16:56.39

>>527
でも iostream は失敗作という気がふつふつと…（略）

**デフォルトの名無しさん** · 2020/09/23(水) 20:38:06.09

c++らしいって言っても時代によってかなり変わるし無意味な言い回しだわ。

**デフォルトの名無しさん** · 2020/09/23(水) 21:11:40.16

時代によってかなり変わるの？
C++98以降しか知らないけど
C++らしさ＝テンプレート
と断言していいほどの一点張りだと思うけど（個人の感想です）

**デフォルトの名無しさん** · 2020/09/23(水) 21:58:09.41

もうどこから突っ込んでいいかわからんくらい馬鹿

**デフォルトの名無しさん** · 2020/09/23(水) 23:12:26.96

ここまで喧喧諤諤の多くの意見が飛びかっておるが
iostream は要らん子、というのは一致しておるな
とくに operator << >> 系のやつ

**デフォルトの名無しさん** · 2020/09/23(水) 23:42:00.61

coutで出力するよりstd::stringに一旦文字列化してからprintf()で出した方が速いという時点で以下略

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/23(水) 23:55:04.80

個人的には iostream をそこそこ好きなんだが、
今だったらこんな設計はしないだろうなというのはとてもよくわかる。

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/24(木) 00:04:29.70

>>535
互換性を捨てられない以上は汚い部分も捨てられないんだよね。
だからどうやって抽象化層をかぶせるか、もっと直接に言えば
汚い部分をどう隠すかというのが C++ らしさじゃないかな。

そして型 (または型の表記) に関して汚い部分を隠す道具としては
テンプレートは特に有用なもののひとつだとは思う。

ただ、一点張りは言い過ぎで、取れる手段、手数の多さも C++ らしさだというのが私の感想。
組み合わせよう。

**デフォルトの名無しさん** · 2020/09/24(木) 03:03:21.13

printfで%dとか%zとか指定するのめんどいやん

**デフォルトの名無しさん** · 2020/09/24(木) 03:09:46.41

printfはバッファオーバーフローの脆弱性を産みやすい

**デフォルトの名無しさん** · 2020/09/24(木) 03:10:26.11

早いとか以前の問題

**デフォルトの名無しさん** · 2020/09/24(木) 05:20:27.18

>>531
＞意地でもテンプレートで何とかしよう
"自分でテンプレート書いて"色々どうにかしてる人が言うならまだ説得力もあるけどね
add_pointer_tとかdecayは基本的に標準ライブラリの実装(のためのメタプログラミング)の上での副産物だろ
テンプレートの文脈(=受け取った型に、場合により変換を施す必要がある)でもないとこでそんなん使って
「C++らしい」とか、だいぶ痛々しい

まぁ別に使用を禁止されてるわけでもないから使いたきゃ好きにすればいいけどね・・・

**デフォルトの名無しさん** · 2020/09/24(木) 06:18:07.32

>>544
同意

**デフォルトの名無しさん** · 2020/09/24(木) 06:37:36.81

>>533
まあね、俺も禿１からの付き合いだけど
未だによくわからんところはある

iostreamに限ったことじゃなく古株のクラスライブラリって
だいたい今作るならこうはしないってところが何かあるね
大きな実害なければ我慢するし
困る場合はそれこそ腕が鳴るチャンス

**デフォルトの名無しさん** · 2020/09/24(木) 06:40:25.74

>>535
たとえばだけど、二次元配列がいるならクラス化するとかね
人によるだろうけどvector<vector<int>>は俺あんまりやりたくない

**デフォルトの名無しさん** · 2020/09/24(木) 06:48:44.27

用意されているものを使っただけだろ
意地でもとかバイアスが入るのはコンプレックスの顕れだからこそ
ギャンギャン強弁してくるわけだ

**デフォルトの名無しさん** · 2020/09/24(木) 07:02:36.59

>>542
printfでバッファオーバーフロー？
お前器用なやつだな

**デフォルトの名無しさん** · 2020/09/24(木) 07:04:12.32

decayに_t付けるの忘れてた
>>548
それ誰に向けて言ってるの？

**デフォルトの名無しさん** · 2020/09/24(木) 07:09:28.96

返事をするのは心当たりがあるという自己申告かな？

**デフォルトの名無しさん** · 2020/09/24(木) 07:14:45.36

なんか口調でわかるわ、いつものアホか・・・
「＞」これが付いてるのは引用箇所だからな、覚えとくといいよw

**デフォルトの名無しさん** · 2020/09/24(木) 07:33:47.41

俺はまだ誰にとも言ってないんだがｗ

**デフォルトの名無しさん** · 2020/09/24(木) 07:40:21.81

はいはいわろすわろす

**デフォルトの名無しさん** · 2020/09/24(木) 08:57:55.68

printf, scanf系はtypedef型の正体を知っておかねばならないとかクラス型を基本型と同等に扱えないとかモロモロあるのに
いつまでもマンセーしててもしゃーないで

**デフォルトの名無しさん** · 2020/09/24(木) 09:00:20.65

>>549
いや普通にありえるからググってわかる程度のこと聞くなよ

**デフォルトの名無しさん** · 2020/09/24(木) 09:01:54.41

>>555
typedefの正体を意識してprintf/scanfを使うのは
privateでデータメンバを隠す話と真っ向逆だね

**デフォルトの名無しさん** · 2020/09/24(木) 09:12:36.08

最終出力がわかりにくいとかロケール対応しにくいとかあるわけだけど
引数順にしか出力できない時点でprintfもロケール対応のやりにくさは変わらん

**デフォルトの名無しさん** · 2020/09/24(木) 09:31:03.57

>>556
ググっても出てこないぞ

**デフォルトの名無しさん** · 2020/09/24(木) 09:40:43.54

ググりかたから教えなきゃならんの？
相手にしてられんわ

**デフォルトの名無しさん** · 2020/09/24(木) 09:44:41.22

>>558
そんなあなたにput_money, put_time

**デフォルトの名無しさん** · 2020/09/24(木) 10:57:49.94

>>561
ロケールと書いたのが悪かったな
多言語化だな
語順を変えるとかやりにくい
Pythonのようにフォーマット文に引数の順番をかければ
言語による語順の違いもフォーマット文の差し替えだけで済む

**デフォルトの名無しさん** · 2020/09/24(木) 11:05:22.76

>>562
安易に考えすぎ
実際にやってから言え

**デフォルトの名無しさん** · 2020/09/24(木) 12:32:18.71

>>556
ググれー
で逃げる気マンマンでワロタ
おとなしくsprintfでした、ごめんなさい
って言ってりゃいいのにw

**デフォルトの名無しさん** · 2020/09/24(木) 12:43:09.70

>>547
boost::numeric::ublasとか使えばいい。

**デフォルトの名無しさん** · 2020/09/24(木) 12:47:12.82

>>562
ああ確かに語順の変え方はprintfと変わらんな
auto time_v = time(nullptr);
cout << put_time(localtime(&time_v), "%m/%d/%y %H.%M'%S");

**デフォルトの名無しさん** · 2020/09/24(木) 13:45:56.89

>>564
お前も本当にゴミだな
wikipediaのリンク貼っといてやるよ
ほら
https://ja.wikipedia.org/wiki/%E6%9B%B8%E5%BC%8F%E6%96%87%E5%AD%97%E5%88%97%E6%94%BB%E6%92%83

**デフォルトの名無しさん** · 2020/09/24(木) 13:47:01.22

まじでバカはしね

**デフォルトの名無しさん** · 2020/09/24(木) 14:13:22.68

その話のどこがバッファオーバーフローなんだ？

**デフォルトの名無しさん** · 2020/09/24(木) 14:23:05.33

>コールスタック上のリターンアドレスを書き換えて不正なコードを実行させる

**デフォルトの名無しさん** · 2020/09/24(木) 14:24:13.29

自分の過ちを認めろと言う割に自分は謝らず図々しく更に無駄な質問を重ねるとは

**デフォルトの名無しさん** · 2020/09/24(木) 14:30:21.28

>>565
boostは標準規格外なので却下

**デフォルトの名無しさん** · 2020/09/24(木) 14:38:20.48

>>570
バッファオーバーフローさせるだけではコールスタック上のリターンアドレスは狙えないぜ
同じ記憶域期間を持つ他のオブジェクトを破壊する可能性があるというだけだ
コールスタック上のリターンアドレスを狙うなら配列でないオブジェクトのアドレスにオフセットかけるだけでもできるしな
逆に自動変数のアドレスを確実に得る技術が必要になる

printf/scanfといえばバッファオーバーフローという固定観念に囚われているから
そういう読みになっちまうんだよ

**デフォルトの名無しさん** · 2020/09/24(木) 14:46:00.53

まともに日本語の文章も読めないようじゃプログラムは君には難しいよ

**デフォルトの名無しさん** · 2020/09/24(木) 14:49:15.10

メモリ位置にあるデータを確認できると書いてあることすら読めてない

**デフォルトの名無しさん** · 2020/09/24(木) 14:54:12.15

おまわりさんこのひとです

**デフォルトの名無しさん** · 2020/09/24(木) 14:55:32.81

おとなしく、日本語もググるのも難しくてひとつずつ教えてもらわなきゃできません
ごめんなさいって言ってりゃいいのにｗ

**デフォルトの名無しさん** · 2020/09/24(木) 14:59:43.90

>>575
俺、自動変数のアドレスを確実に得る技術って言ったけど
おまえさんは、これが何のことかわかってる？

printf/scanf関係ないんだがｗ

**デフォルトの名無しさん** · 2020/09/24(木) 15:11:43.38

Wikipediaまで引用してあげたのにまだごねるのか
本当にわがままだな

**デフォルトの名無しさん** · 2020/09/24(木) 15:12:12.34

ばかはしね

**デフォルトの名無しさん** · 2020/09/24(木) 15:48:16.32

> printfはバッファオーバーフローの脆弱性を産みやすい

重箱の隅な記事では、最後の「やすい」という主張の裏付けにはならないってことだ
粗暴な罵倒語も裏付けになるわけがないな

**デフォルトの名無しさん** · 2020/09/24(木) 15:53:47.24

そんなにprintf好きなら勝手に使えばいいんじゃない？

**デフォルトの名無しさん** · 2020/09/24(木) 16:06:33.08

おまいら printf の戻り値は毎回チェックしろよ

**デフォルトの名無しさん** · 2020/09/24(木) 16:26:18.33

printfの書式にユーザ入力を使うことなんてあるか？
SQLインジェクションとはワケが違うぞ

**デフォルトの名無しさん** · 2020/09/24(木) 17:02:36.61

バッファ使ってるsprintfと
バッファ使ってないprintfの
違いもわからんのか

**デフォルトの名無しさん** · 2020/09/24(木) 17:26:51.00

確かにprintfの書式文字列に関するメモリ破壊の脆弱性が示されてるが、これを｢バッファオーバーフロー｣と呼ぶのは違和感があるな

**デフォルトの名無しさん** · 2020/09/24(木) 17:33:32.86

わかってないくせに危険な関数使うなよ

**デフォルトの名無しさん** · 2020/09/24(木) 17:34:56.21

パフォーマンスとか以前の問題だろうが

**デフォルトの名無しさん** · 2020/09/24(木) 17:36:15.17

>バッファ使ってるsprintfと
それ勝手に持ち出したのお前だからなｗ

**デフォルトの名無しさん** · 2020/09/24(木) 18:19:48.23

こっからどう乗り切る気？

**デフォルトの名無しさん** · 2020/09/24(木) 18:21:49.52

結局のところ、>>542が恥ずかしい奴だったという結論でok?

**デフォルトの名無しさん** · 2020/09/24(木) 18:26:33.04

>>591
お前みたいな頭悪いやつが多くて
何も有益な話にならないから解散
という結論

**デフォルトの名無しさん** · 2020/09/24(木) 18:37:51.09

cout << ...
がダサいだのprintfが早いだの
程度が低いんだよ

**デフォルトの名無しさん** · 2020/09/24(木) 18:48:48.99

>>592
ん？
バッファーオーバーフローとメモリー破壊の区別もつかないアホがドヤって撃沈だろ？
ダサすぎるw

**デフォルトの名無しさん** · 2020/09/24(木) 18:53:55.27

適当に脳内で読み替えとけや無能
こっちはprintfなんてそもそも使わんから詳しいことに興味はない
だからググれって最初に伝えたんだわ

**デフォルトの名無しさん** · 2020/09/24(木) 19:02:40.95

>>594
じゃあメモリ破壊とバッファオーバーフロー
でリターンアドレスの書き換え方が
どう違うのか説明してみ

**デフォルトの名無しさん** · 2020/09/24(木) 19:10:17.44

ID真っ赤で必死ﾀﾞﾅw

**デフォルトの名無しさん** · 2020/09/24(木) 19:11:45.79

逃げるのか？ｗ

**デフォルトの名無しさん** · 2020/09/24(木) 19:13:39.45

ご自慢の知識を披露してみろよばかが

**デフォルトの名無しさん** · 2020/09/24(木) 19:44:29.22

はい結局にげたー雑魚～

**デフォルトの名無しさん** · 2020/09/24(木) 19:56:55.65

>>595
詳しいこと知らんのに
>>542で参戦してくるの？
振られたネタならともかく自分で振っといてwwww

**デフォルトの名無しさん** · 2020/09/24(木) 20:09:35.67

printfに脆弱性ある
というのが重要な点なのにあくまでも上げ足取りをするのか
本当にごみしかいないな

**デフォルトの名無しさん** · 2020/09/24(木) 20:10:35.38

ID真っ赤で恥ずかしい奴w

**デフォルトの名無しさん** · 2020/09/24(木) 20:12:58.68

なにが恥ずかしいの？IDすぐリセットされるし

**デフォルトの名無しさん** · 2020/09/24(木) 20:25:09.79

ほれぼれする雑魚っぷり

**デフォルトの名無しさん** · 2020/09/24(木) 20:27:17.41

お前ほどではないよｗ

**デフォルトの名無しさん** · 2020/09/24(木) 20:32:02.13

こういうのに反応してくるのは雑魚と相場が決まってるからなｗ

**デフォルトの名無しさん** · 2020/09/24(木) 20:39:06.34

>>596
それがprintfのバッファーオーバーフローと何か関係あるのか？
ごまかすならもう少しうまくやれよw

**デフォルトの名無しさん** · 2020/09/24(木) 20:42:06.80

いや関係ないけど
どうせこいつもわかってないくせに人のこと煽ってるんだろうから
聞いてみたらやっぱ逃げた

**デフォルトの名無しさん** · 2020/09/24(木) 20:56:41.05

printfはバッファオーバーフローの脆弱性を産みやすい
printfはバッファオーバーフローの脆弱性を産みやすい
printfはバッファオーバーフローの脆弱性を産みやすい

煽りモードに入るならボコボコにしてやんよ

**デフォルトの名無しさん** · 2020/09/24(木) 20:59:32.71

>>610
どうぞご自由に
せいぜい頑張れよ無能なりに

**デフォルトの名無しさん** · 2020/09/24(木) 21:00:05.83

ここまで具体例を示した証拠も反論もなし。

**デフォルトの名無しさん** · 2020/09/24(木) 22:12:13.40

>>542
今日日のIDEなら書式文字列とパラメータの型の不一致を指摘してくれる
Visual Studioなら2015からそうなっているので安心、

**デフォルトの名無しさん** · 2020/09/24(木) 22:18:55.93

>>611
で、どこのバッファーがオーバーフローするのかな？w
黙ってりゃいいのにバカは無駄に吠えるしか能がないから無理だろうな

**デフォルトの名無しさん** · 2020/09/24(木) 22:50:51.72

sprintf()なら有り得る、
希ガス

個人的にはsprintf_s()しか使わないから無用の心配だが

**デフォルトの名無しさん** · 2020/09/24(木) 22:53:03.50

自分でバッファオーバーフロー言い出しといてなんやねん

**デフォルトの名無しさん** · 2020/09/24(木) 22:54:48.84

std::ostringstreamは未来
そんなふうに考えていた時期が漏れにもありました、

**デフォルトの名無しさん** · 2020/09/24(木) 23:04:17.15

https://code.woboq.org/userspace/glibc/stdio-common/vfprintf-internal.c.html#__vfprintf_internal
これかな。まぁ頑張って読んでくれ。

**デフォルトの名無しさん** · 2020/09/24(木) 23:05:16.99

しかしなんでスタックって高位側から低位側に伸びる実装なんだろうな
逆にしたらそれだけで外部入力依存のバッファオーバーフローでexploitされる危険性を半減できるはず…

**デフォルトの名無しさん** · 2020/09/24(木) 23:16:12.65

バイナリエディタ見てみろよ。アドレス高いほうが下だろ。
スタックはちゃんと下から積んでるんだよ。

**デフォルトの名無しさん** · 2020/09/24(木) 23:45:08.26

ﾎﾝﾏにprintf()でもやれるんや、
https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/c906.html

しかし%nはC++11で廃止されたとあるからモダンなC++ではprintf()は安心、

**デフォルトの名無しさん** · 2020/09/24(木) 23:46:33.93

安全なライブラリ=チェックが多く遅いライブラリ

C使う意味なくね？

**デフォルトの名無しさん** · 2020/09/24(木) 23:48:09.41

訂正orz、
誤： C++11
正： C11

**デフォルトの名無しさん** · 2020/09/25(金) 00:19:45.11

>>619
それは昔々、CPUが今よりずっと低能力で、malloc()などをする余力もない時代、
メモリー領域を、普通の変数のワークエリアと、call命令での戻り値アドレスの
記憶のためと、レジスタの保存、復帰(push,pop)用のためのエリアを逆方向
から使うことは、画期的なアイデアだったから。
データ領域は、アドレスの小さい方から、大きいほうへ伸ばして使っていくが、
そうやってるさいにも、call,push,pop命令は使いたいから、そのようにする
以外には当時の非力なCPUには非効率すぎて選択肢が無かった。
今なら、リンクリストや高速なmalloc()などを駆使すれば、別の方法も取れるかも
知れない。

**デフォルトの名無しさん** · 2020/09/25(金) 00:26:39.90

>>624
[捕捉]
今は、マルチスレッドプログラミングをする際、各スレッドに、それぞれ
別のスタック領域を割り当てるが、その領域の容量は固定サイズ。
固定サイズでも何とかなるのは、メインメモリーが非常に大きくなったためで、
大部分は無駄になっていても、なんとかなってしまうから。
たとえば、関数呼び出しの回数と、ローカルスタック変数の容量を
掛け算したような値を見積もってみれば、とても無駄なスタック領域の
割り当てをしているだろうが、メモリーがふんだんに余る位になっているので
それでも特に問題がなくなってしまった。
ところが、かつてはメモリーが足りなくてどうしようもなかった。
しかも、当然当時はシングルスレッドだった。
なので、データ領域は上から、スタック領域は下から伸ばしていけば、
お互いが衝突するまで使える。これは、ギリギリ限界まで無駄なく
メモリーが使えることを意味する。

**デフォルトの名無しさん** · 2020/09/25(金) 00:29:23.03

なんかデタラメがいろいろ混じってるぞ。

**デフォルトの名無しさん** · 2020/09/25(金) 00:30:59.73

>>624
どこらへんが画期的で効率的なのかkwsk、
普通の変数のワークエリアと逆方向からスタックを伸ばしたところで
使えるメモリが増えるわけでなし…
（スレッドが2本以上あればスタック領域は結局スレッド毎に固定サイズで割り当てるしかない

百歩譲って一つながりのメモリを上と下の両方から使っていったらすばらしいと思えたとしても、
なんでスタックを0番地から上に伸ばしてsbrkが最大アドレスから下に伸びる設計にしなかったのかの
説明にならない

**デフォルトの名無しさん** · 2020/09/25(金) 00:34:29.83

>>625
[もっと捕捉]
今は、MMUを使っており、実際に使ってない仮想メモリー空間には、物理メモリー
を割り当てない。だから、使うまでは物理メモリーは無駄にはならない。
もう一つは、(仮想)アドレス空間自体が飛躍的に大きく取れるようになったことで、
搭載している物理メモリー以上に大きなアドレス空間が使えて、各スレッド
のスタック用に大きめにアドレス空間を確保(commit)しておけるように
なった。
32BIT時代ですら、4GBの仮想アドレス空間が使えたから、アドレス空間自体の
不足は余りおきなくなった。積んでいる物理メモリーよりも大きな空の領域を
各スレッドのスタックに割り当てても、特に問題が無い。
今や64BIT時代。同時に実行するスレッドの個数も増えつつあるが、各スタック
領域の仮想アドレス空間上のサイズを大きくとってもどうってことは無い時代になった。
しかし、かつてはそうではなく、スタックは下から上に伸ばして行き、データ領域
と衝突するまで使うのが良い方法だった。

**デフォルトの名無しさん** · 2020/09/25(金) 00:47:42.60

>>627
picの変態仕様見れば分かる。汎用機もそうだけどスタック制限あるアーキテクチャが普通だった時代。
しかも0番地から伸ばすとかCPUの仕組みすら知らんレベルだな。割り込みベクタがあったり、プログラムのROMがあったり、
0番地にフリーのRAMなどたいていない。つまり空いてるRAMの下限は開発が終了するまで確定しないこともしばしば。
じゃあいつSP設定値いつ決まるのって話。決まらないんだから一番うしろにして前に進めるのが頭使わずに済む。
ちなみに8086はスタックセグメントあるから。便利だろw