C++相談室 part152

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

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

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

sprintf_s()と_countof()をセットで標準にしてﾎｽｲ

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/23(水) 01:40:34.94

>>497
C だと _countof に相当するものは欲しいなと思うが、
C++ 的には std::size か std::extent を使いたまえ。

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

>>493
>元からイケてない変数宣言の文法を部分的にどうにかすっきり見せる
一般的なポインタを表現するためには、どうしても、宣言子の中にも型の一部を
書くべきだったので、文法がそのように選択され、
int* a;
ではなく、
int *a;
と書く方がその記法と統一感がある。
数学者や物理学者は一般性や統一性がある方が美しいと感じる人が多いと
言われており、通常、数物の世界で「美しい」というのは、統一性のある
書き方。
なので、C/C++の型でも、後者の方が美しく感じるのが数物系の才能がある
人の感覚。

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

>>496
どんな判断だよ
libfmt使えばいいじゃん

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

>>499
ポインタだけでなく、配列も、
int a[3];
の様に書く。これも、人気言語であったBASIC言語の
DIM a(3)
と似た感覚となっている。
配列はもちろん型の一部ではあるが、これを
int[3] a;
と書いて分かり易いとは限らない。というのは、
配列を使う場合には、BASICの場合ではa(i)、Cの場合では、a[i]のように書くので、
これも、宣言に置いても、BASICやCの書き方の方が分かり易いと思うのも自然。
それに
int *ptr_s[3];　　// (100)
のような場合に、分かり易く型を全て左に書くのは難しい。
書くとすれば、
int*[3] ptr_s;
となるが、これが果たして分かり易いかと言えばNoだろう。
使う場合には、ptr_s[i] が int へのポインタになるのだから、
(100)の記法は至って分かり易い。

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

>>499
> どうしても、宣言子の中にも型の一部を書くべき

それを前提とするならそれと一貫させることを俺は否定してない。
でも前提とできないよねという話をしてるんだから
なんで「べき」なのかを説明しないとなんの主張にもなってないよ。

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

>>501
さらにいえば二次元配列の場合、宣言は、
int a[3][2];　//C。使う場合は a[i][j]
DIM a(3,2);　//BASIC。使う場合は、a(i,j)
となるが、もしCで型を全て左に書くとすれば、
int[3][2] a;
となると思うかもしれないが、これは、数学的な統一性からすれば
間違いで、正しくは、
int[2][3] a;
となり、前後を逆に書くのが「正しい」。
これが即座に理解できる人が数学的才能が有る人で、
教えてもらわないと分からない人才能が無い。

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

>>502
Cの記法は、物理学で言うところの「組立単位」に相当する「組み立て型」を
一般的に表現するためには、かなり美しく正しい選択をしている。
int *a[10];　// (1)
int (*a)[10];　// (2)
と
は、物理学のように言えば、int-ptr-array-aとint-array-ptr-aの違いを
表しているが、Cの表現はとても理にかなっており非常に分かり易い。
これらの型を全てまとめて左に書こうとすれば、書くことは出来て、
int*[10] a;　// int-ptr-array-a, (10)
int[10]* a;　// int-array-ptr-a, (11)
となるが、果たしてこれが分かり易いかどうかと言う問題となる。
それぞれを使う際の a[i] や、*a の表記と(1), (2)に上手く対応しているので、
(10),(11)よりも統一が取れており、数学的には「美しい」状態となっている。

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

>>502
それは、>>503 や >>504 のようなことがあるから。

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

>>502
C言語のように「書くべき」ことが分かる一番分かり易い例は、Cで
int a[1][2][3][4];
と書くものが、全部左に型を書く記法だと
int[4][3][2][1] a;
と書かないと、組み立て型(物理学における「組立単位」に相当)における
一般性を失うが、それだと、使う際の a[i1][i2][i3][i4]と要素数の指定とが
直感的に逆さまになってしまう問題が起きる。

もし、
int[1][2][3][4] a;
のように書くと、一般性を失い、組み立て型としては破綻しまい、その場しのぎの
記法となってしまう。
もしこれが理解できないのなら、悪いけど、数学的才能や、コンパイラを設計する才能が無い。

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

どうでもよい

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

じじいはこういう語りつくされた古い話題しか話せないからな

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

大工が金槌はこうでなくてはならない（家を作ったことない）

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

この手の輩はいないほうがいい
邪魔

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

クソみたいなマウント合戦を繰り広げる老害であることを自覚しろ

**はちみつ餃子** ◆8X2XSCHEME · 2020/09/23(水) 02:59:44.49

>>504
数学的・物理的な美しさを (仮に (あくまでも仮に) その主張が妥当だとしても) C++ スレで根拠にするのが不思議。
そんな美しさなんてどうでもいいもの。

こちらの主張は

宣言の文法が型名とは別にある
→ その時点で一貫性なんてないよ
→ どちらを軸にすることもありうる
→ でもまあ C++ の発展の様子からすると型名を軸にしたさが見えるね

って話で、現時点で無い文法を導入したいとか思っているわけでもないし、
存在する文法を絶対に駄目だというわけでもない。

とはいえ (話の大元に戻るが) 現在の C++ が typedef を冷遇しているので、
なるべく using を使ったほうがいいよねってだけ。

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

わしのFormatterは
int* a;
int *a, *b, c;
のように整形しよる。これが落とし所として妥当であろう

◆QZaw55cn4c · 2020/09/23(水) 05:07:59.09

>>500
https://github.com/fmtlib/fmt
でしょうか？github になれてなくて、これを使う方法もよくわからないし…
20年使っている sprintf() でもういいや…って妥協してしまいました
手元のコンパイラは g++17, 職場のは g++11 だけれども、セキュリティが堅くて「無断で」cygwin をアップデートさせてもらえない…
必要に迫られて徹夜して間に合わせたけれども、プログラミングへの集中力はずいぶんと落ちてしまいました…

コメントありがとうございました

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

>>506
auto signal(int, void(*fp)(int)) -> decltype(fp); //こう書かれたら「破綻」で読めなくなるのか？　おまえさんは
それこそC++11のグラマーが読めない、つまり数学的才能に乏しいことになるぞ

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

>>512
あいつ結局Cの文法と設計思想を説明してるだけだよな
それをC++11の文法と設計思想を否定する根拠にしようとしているようだが
筋違いというか脈絡がない

ぼくはusing使いたくないんだーtypedef使うのを邪魔すんなー
僕はものすごく数学と物理に詳しいんだーセンスないやつうるせー

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

数学や物理学は、2000年以上も続く巨大なエコシステムを持っており、
それ以上簡潔にならないくらいな表現方法を発明済み。
それとは別の表現をしてもそれらを超えることはまず不可能で、文系の人達の
自己満足に過ぎない。

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

思っクソ関係ない
話せば面白そうな気がしたがそっちへ行くのね
あーあ残念

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

最近の「モダン」言語は、既存のものを知らずに新しいものを作ろうとする傾向が目立つ。
彼らは、今までの理論などそのメリットが理解出来ておらず、効率の悪い、
分かりにくい、整合性の無い、その場しのぎで、一般性が無い記法を導入する。

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

つまんね

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

>>503
えっ？
そもそも
int a[2][3];　//C。使う場合は a[j][i]
DIM a(3,2);　//BASIC。使う場合は、a(i,j)
じゃないのかな

>>499 は支持する

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

>>506
ここもおかしい

元々
int a[4][3][2][1];
と書くべき

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

分かりにくい文法で自爆ってダサすぎるなw
そもそもC++なのに素の多重配列使うって
センスなさすぎだし

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

>俺は数学が好きで、学生時代、ほぼ満点だった。

数物系が得意な人が、こんな馬鹿っぽくて曖昧な書き方するのかね？
この情報でどうやってお前の能力を推し量れと

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

正直マジレスするアホが居るとは思いもよらなんだ

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

>>493
なんでもテンプレートに書き直せばいいってもんでもない

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

CでもそうだけどC++を使うからにはC++らしく使いたいね
C訛りのたどたどしいC++からは早く脱したい

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

Cで憶えたことがとりあえず使えるのがC++に用意された入りやすい門ではあるけどね
そこは振り出しでしかないんだよ

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

>>493みたいなのをC++らしい、と思ってるならだいぶアレだけどな

**デフォルトの名無しさん** · 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
じゃあメモリ破壊とバッファオーバーフロー
でリターンアドレスの書き換え方が
どう違うのか説明してみ