C++相談室 part157

**デフォルトの名無しさん** · 2021/08/09(月) 10:57:31.60

前スレ
C++相談室 part156
https://mevius.5ch.net/test/read.cgi/tech/1621389313/

**デフォルトの名無しさん** · 2021/08/19(木) 16:54:44.67

>>132
なるほど。確認だけど、
1. CPerson a{1,2,3};
2. CPerson a={1,2,3};
3. CPerson a=CPerson{1,2,3};
4. CPerson a(1,2,3);
5. CPerson a=CPerson(1,2,3);
は、どれも3引数のコンストラクタで受け取ることは可能ということでOk?
1. 2. 3. は、initializer_list を受け取るコンストラクタでも受け取ることが可能？
4. 5. は、initializer_list を受け取るコンストラクタでも受け取ることは不可能？？

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/19(木) 17:08:54.15

>>133
(initializer_list を受け取るコンストラクタが無ければ) いずれも 3 引数のコンストラクタが起動されるが、
5. は 3 引数のコンストラクタでオブジェクトを構築した上で a にコピーする。
(コピーコンストラクタ、またはムーブコンストラクタが起動する。)
ただし RVO が有効な状況ではコピーやムーブはが省略されるので 5. は 4. と同じ。

そしてこの場合には関係ないが、波括弧によるコンストラクタ起動では引数の暗黙の型変換を許さない
といった重要な違いがある。

(initializer_list を受け取るコンストラクタが有る状況でも) 4. と 5. は initializer_list とは解釈されない。

**デフォルトの名無しさん** · 2021/08/19(木) 17:14:28.81

>>134
1. 2. 3. は、initializer_list を受け取るコンストラクタでも受け取ることが可能？
4. 5. は、initializer_list を受け取るコンストラクタでも受け取ることは不可能？？
については？

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/19(木) 17:19:50.55

>>135
それが区別できるだけのルールは既に提示したつもり。

**デフォルトの名無しさん** · 2021/08/19(木) 17:21:53.70

>>136
すまん。もう一度明言してくれるとありがたい。

**デフォルトの名無しさん** · 2021/08/19(木) 17:27:44.09

template <int N> void test(std::bitset<N>& arg);

int main()
{
std::bitset<1ull> lvalue;
test(lvalue);
}

これ、Nが推定できないのはなんで？

**デフォルトの名無しさん** · 2021/08/19(木) 17:28:31.68

すまん、自己解決
unsigned long long Nが正解だった

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/19(木) 17:30:02.71

>>135
> 1. 2. 3. は、initializer_list を受け取るコンストラクタでも受け取ることが可能？
はい。可能です。

> 4. 5. は、initializer_list を受け取るコンストラクタでも受け取ることは不可能？？
はい。不可能です。

ところで >>134 で、オブジェクトを構築した上でコピーするのは 5. と述べたけど 3. もそうやな。

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/19(木) 17:33:59.90

>>138-139
正解は size_t だよ。
size_t が具体的にどの整数型に対応するかは処理系定義なので
もちろん unsigned long long と等価なこともあるだろうけど。

**デフォルトの名無しさん** · 2021/08/19(木) 17:40:36.29

>>136
念のため、その「述べた」はずのルールがどの文章だったのか教えてもらえれば
ありがたい。

**デフォルトの名無しさん** · 2021/08/19(木) 22:54:32.78

vector<long long>を取る関数にvector<int>を渡すと、その引数はvector<long long>にキャストされる
で、vector<int>を取る関数にvector<long long>を渡すのはNG

この理解は合ってますでしょうか

**デフォルトの名無しさん** · 2021/08/19(木) 23:03:24.64

間違ってる
vector<long long>とvector<int>には何の関係もない
intとstringに関係がないのと同じくらい関係ない

**デフォルトの名無しさん** · 2021/08/20(金) 11:13:55.26

pair<int, int> は pair<long long, long long>にキャストできるけど
vectorにそういうコンストラクタはないな

**デフォルトの名無しさん** · 2021/08/20(金) 12:13:09.91

>>103
VS6.0の頃は地獄だったよ
forループの変数は生キノコるわ例外出たら自動変数の破棄全部ぶっ飛ばすわでMSはクソの集大成だと確信していたわ

**デフォルトの名無しさん** · 2021/08/20(金) 12:42:32.36

例外処理が２系統、数え方によっては３系統あるのがね

**デフォルトの名無しさん** · 2021/08/20(金) 15:19:34.50

STOUT を STDOUT に空目してこそプログラマ脳

「ミロ」そっくりの缶ビール　子どもが誤飲し販売禁止に（豪） - Yahoo! JAPAN
https://article.yahoo.co.jp/detail/1a7b2e0b9ab108ebf156f22e654f60634c39c88b
子どものみならず大人にも大人気のココア味の麦芽飲料「ミロ」は、世界中で愛されている。このほどオーストラリアの企業が、
ミロにそっくりのパッケージデザインで缶ビールを製造したことにより「子どもが間違えて飲んでしまった」という苦情が届いた。
これにより同製品の広告使用禁止が言い渡されたことを『news.com.au』などが伝えている。
問題の缶ビールは、豪ビクトリア州にある企業「Howler Brewing Company」の「Chocolate Milk Stout」というチョコレート風味の黒ビールだ。
缶のデザインは有名な麦芽飲料「ミロ」を真似たもので、お馴染みの緑色を背景に製品名や販売会社を示す文字の色やフォントまで同じデザインとなっている。
同社はこれまでにも、Instagramや炭酸飲料「スプライト」など認知度の高いロゴデザインを真似た製品を作り出している。

**デフォルトの名無しさん** · 2021/08/20(金) 17:52:50.79

関数オブジェクトじゃなくて関数を記述するメリットってなんかある？
テンプレートは近々関数オブジェクトの方でも使えるようになるんでしょ？

**デフォルトの名無しさん** · 2021/08/20(金) 19:08:22.19

>>149
タイプ数が少ない、くらいかね。

**デフォルトの名無しさん** · 2021/08/20(金) 20:12:20.52

>>150
じゃあそのうち「関数はレガシーな書き方なので関数オブジェクトを使用するようにしましょう」とか言われるようになるの？

**デフォルトの名無しさん** · 2021/08/21(土) 00:32:59.41

>>149
複数の関数から呼ばれる関数どうすんのさ
グローバル変数や引数にいちいち入れるの？

**デフォルトの名無しさん** · 2021/08/21(土) 00:37:37.24

>>146
forの変数スコープは回避策あったやん
98年発売なんでもうちょっとどうにか出来たのではとも思うが

**デフォルトの名無しさん** · 2021/08/21(土) 00:45:38.19

あ、すまんラムダじゃなくて関数オブジェクトか
確かにタイプ数くらいしか思いつかんけど
テンプレートは既に使えるのでは？関数テンプレートに出来て関数オブジェクトに出来ないテンプレートの使い方あったっけ

**デフォルトの名無しさん** · 2021/08/21(土) 10:46:43.63

>>148
日本でも煙草を真似したデザインのチョコレート菓子があったけど
間違って煙草食った子供が死んだとか裁判になったとか聴かないな
おそらくあったんだろうな

**デフォルトの名無しさん** · 2021/08/21(土) 12:15:51.53

>>154
実体化の制御かね。
関数テンプレートは使用されない限りエラーにならない。
SFINAEもそうじゃなかったっけ？

**デフォルトの名無しさん** · 2021/08/21(土) 13:42:38.53

クラステンプレート内の普通のoperator ()だとそうだね
operator ()がテンプレートの場合ならほぼ関数テンプレートと同じ事出来るとは思うけど
文法上、明示的にテンプレート引数指定する際、関数と共通の書き方には出来ないな・・

**デフォルトの名無しさん** · 2021/08/21(土) 20:47:50.56

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しでView types参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴
著者：アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、Cのソースコードを吐き出せるのでC言語でリモートワークされ
ている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

**デフォルトの名無しさん** · 2021/08/21(土) 22:35:53.53

質問です。
std::array ary = { 1, 2 };

↑の{}で初期化すると、
要素数を自動推論できるようにするにはどう実装すればいいんでしょう？

**デフォルトの名無しさん** · 2021/08/21(土) 22:55:48.18

推論補助だと思う

https://cpprefjp.github.io/reference/array/array/op_deduction_guide.html

**デフォルトの名無しさん** · 2021/08/22(日) 01:17:33.04

>>155
食ったところで飲みこまずにペッペッて吐き出すだろ

**デフォルトの名無しさん** · 2021/08/22(日) 04:31:26.04

g++ -std=c++17

**デフォルトの名無しさん** · 2021/08/22(日) 12:59:29.57

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

**デフォルトの名無しさん** · 2021/08/22(日) 18:45:30.76

std::chrono::time_point::time_since_epoch()が返すエポックタイムの原点はいつですか？
もし具体的に規定されていないとしても、
ミリ秒パートが0であることは保証されていますか？

**デフォルトの名無しさん** · 2021/08/22(日) 19:20:25.99

ある意味自己解決しますたorz
https://cpprefjp.github.io/reference/chrono/system_clock.html
>C++17 以前の場合、system_clock のエポックがどの時間を指しているかは未規定だが、ほとんどの処理系は UNIX 時間（1970年1月1日0時0分0秒)を指している
>C++20 以降の場合、system_clock のエポックは必ず UNIX 時間（1970年1月1日0時0分0秒)を指す
しかし（特にC++17以前において）ミリ秒パートが0が保証されているのかどうかがはっきりしませんぬ、

**デフォルトの名無しさん** · 2021/08/22(日) 19:28:39.82

生年月日をUNIX時間で表現できないオッサンはこのスレにどのくらいいるの？

**デフォルトの名無しさん** · 2021/08/22(日) 21:27:04.43

生年月日ならミリ秒まで言える必要は無いが
ログの時刻を極力正確に（WindowsのGetLocalTime()と同じ時刻で）記録したいのでつ∀`；)

**デフォルトの名無しさん** · 2021/08/23(月) 04:13:32.16

1970年以前生まれの50代以上のオッサン

**デフォルトの名無しさん** · 2021/08/23(月) 16:50:49.24

B.C.
A.D.
B.E.

**デフォルトの名無しさん** · 2021/08/23(月) 22:05:26.78

B.E.って何ですか
UCとSEとかRCとかじゃないの

**デフォルトの名無しさん** · 2021/08/23(月) 22:52:48.51

ていうかsystem_clockはC++17以前からtime_tと相互変換できるのに（system_clock::from_time_t()、system_clock::to_time_t()）、
エポックがどの時間を指しているかは未規定とかおかしくね↑？

**デフォルトの名無しさん** · 2021/08/23(月) 23:20:43.35

別におかしくない
変換時にエポックの差の分ずらせばいいだけだろ

**デフォルトの名無しさん** · 2021/08/23(月) 23:31:13.03

そんなことよりなんでtime_tは符号なしなん？
64bit拡張するときに符号ありにしとけば166みたいな煽りを受けずにすんだのに

**デフォルトの名無しさん** · 2021/08/24(火) 00:03:00.26

符号なし使うのは総じてセンスないよね

**デフォルトの名無しさん** · 2021/08/24(火) 07:17:43.25

符号付き整数はwrap aroundしたときの挙動が処理系依存か何かだったはず……
ハードウェア例外を生じるやつがあるらしい

**デフォルトの名無しさん** · 2021/08/24(火) 07:52:57.66

>>173
純粋にプログラミングスキルの話と受け取った>>167に謝れ

**デフォルトの名無しさん** · 2021/08/24(火) 08:21:39.19

>>175
オーバーフローしたときにラップアラウンドさせる使い方が数値計算としては特殊だからねぇ。

**デフォルトの名無しさん** · 2021/08/24(火) 15:27:02.85

>>167
ntp使え

**デフォルトの名無しさん** · 2021/08/24(火) 17:48:36.53

>>174
time_tを符号なしにしたやつはアフォだと思うが
それをもって符号なしを使うやつ全員が例外なくアフォというのは
早まった一般化という誤謬だ

**デフォルトの名無しさん** · 2021/08/24(火) 22:08:27.39

>>160
なるほど！ありがとうございます

**167** · 2021/08/25(水) 00:50:22.37

そういやーまだご存命の方もいらっしゃるんでしたね

>>179
符号付きにしたら2038年問題が2004年問題になってた
人類は間に合わなかった

**デフォルトの名無しさん** · 2021/08/25(水) 07:34:23.44

３０年も猶予があったのにな

**デフォルトの名無しさん** · 2021/08/25(水) 10:43:26.33

ヒトラー「2036年、人類と云われる者は居なくなっている」

**デフォルトの名無しさん** · 2021/08/26(木) 16:49:35.75

関東大震災だって100年も猶予があっても何もしない國ですし

**デフォルトの名無しさん** · 2021/08/26(木) 21:09:02.54

色々やってるぞ
庶民を助ける政策をやってないだけで

**デフォルトの名無しさん** · 2021/08/27(金) 17:50:19.96

https://twitter.com/cpp_akira/status/1430779310885859330
最近はC++の発表資料を公開すると「Rustでいいじゃん」というコメントがたくさんつくのか…。
Rustへの言及とか一文字も書いてないのに。
普及活動だと思うけど、さすがに嫌がらせチックに見える。

https://twitter.com/moriyoshit/status/1430795812552863744
C++の件に限らず、旧来からある言語の長所短所を理解せずに、
表面的に新言語を推す発言を見ると、
果たして当人は新しい言語の方も理解できているのだろうか、
という疑念をもってしまう...
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2021/08/27(金) 19:27:10.45

>>186
Rustはいらんけど、制約を強化してコンパイルエラーを増やしたc++--は欲しいなぁ。

スライシングはすべてコンパイルエラー、ダウンキャストはメンバー関数とフレンド関数のみ使用可能
new deleteはメンバー関数とフレンド関数のみ使用可能（global operator new/deleteは廃止）
といったメモリ周りの制約強化は欲しい。

**デフォルトの名無しさん** · 2021/08/28(土) 14:03:18.97

Rustを使って欲しいなら、そう言えばいいのに
人のすることを小馬鹿にするような態度で来るから敵と見られるんだよ
コミュ障にも程がある

**デフォルトの名無しさん** · 2021/08/28(土) 18:35:03.00

インテルコンパイラの-fastには-staticが含まれてるけど、なんでスタティックリンクは速いの？

**デフォルトの名無しさん** · 2021/08/28(土) 18:49:01.71

ライブラリ使うときのロードの手間がなくなるからね

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/28(土) 23:41:54.59

スタティックリンクにすると最適化の情報が増えるというのもあると思う。

C/C++ では翻訳単位ごとにコンパイルしてからリンクするという工程を踏むから、
コンパイル時には他の翻訳単位の情報を知らず、他の翻訳単位の情報を利用した
最適化が出来なかった。

今では LTO が当たり前になって、リンク時にあらためてコンパイラに戻して最適化
させる仕組みがあるんだけど、バイナリ自体が別物だとその仕組みを使えない。

**デフォルトの名無しさん** · 2021/08/29(日) 13:13:16.45

std::threadってスタックサイズを指定できないってﾏｼﾞ？
仮想メモリを使えない組み込み用途だとどうすんじゃ……

**デフォルトの名無しさん** · 2021/08/29(日) 13:20:14.34

native_handle()関数で環境に応じたスレッドハンドル(linuxならpthread)を取得できるから、スタックサイズを設定するところだけ環境ごとに用意して切り替えればいいよ

**デフォルトの名無しさん** · 2021/08/29(日) 13:28:41.66

Windowsみたいにスレッドハンドルを生成したときはスタックサイズ指定済のとき、みたいな
組み込み用OSがあったらどうすんじゃ……

**デフォルトの名無しさん** · 2021/08/29(日) 13:46:08.60

とわいえμITRONのcre_tsk()は
>cre_tsk でスタック領域を明示しない場合のタスクのスタックや割込みハンドラ/割込みサー
>ビスルーチンのスタックは、OS が用意する「スタック用メモリ」から割り当てられます。
>スタック用メモリのサイズを定義する STKMSZ の標準値は 0 で、この場合、main 関数が使って
>いる処理系のデフォルトのスタック領域(スタックセクション)を、OS のスタック用メモリとし
>ます。この場合の実際のスタックサイズは、リンカでのセクション設定とスタートアップルー
>チンでの初期スタックポインタ値で決まります。
みたいなことが書いてある
C/C++界隈はみんな頭おかしい……

**デフォルトの名無しさん** · 2021/08/29(日) 13:55:46.65

ｺﾞﾒ勘違いcre_tsk()（IDがOSが自動割り当てのやつはacre_tsk()）は
第2引数に与えるT_CTSK構造体でタスクごとにスタックサイズを指定できたわ；；；
なんでstd::threadではできないんじゃ……

**デフォルトの名無しさん** · 2021/08/29(日) 14:18:20.52

コイツ前スレでも連レスしてたムーブ全く理解してないバカだよね？
NGしたいからトリップつけてください

**デフォルトの名無しさん** · 2021/08/29(日) 14:25:04.60

>>192
標準じゃ無理でしょ
全てのスレッドを変えたいならリンカのオプションとかで指摘できる環境もあるけど

boost::thread使って
boost::thread::thread_attribute::set_stack_size()
で設定するがよろし

>>193
native_handle()関数でハンドル取れると言う事はスレッド開始してる
開始済みスレッドのスタックサイズを変えられる環境って聞いたことない

**デフォルトの名無しさん** · 2021/08/29(日) 14:30:52.45

>>196
ほんと組み込み屋は馬鹿だな

**デフォルトの名無しさん** · 2021/08/29(日) 16:52:45.64

>>197
完璧な理解をサンプルコード付きで示したやろうが；；；

論点はなんでムーブに置き換えられるケース（明示的にstd::move()したら明らかに効率的なコードになる
において最適化でムーブにならないのか？なのだが高度すぎるのか文盲か故に>>197が付いてこれていないだけ
>>197はブーメラン

**デフォルトの名無しさん** · 2021/08/29(日) 16:54:56.72

もっとも天才の漏れは答えにたどりついたがな
ムーブコンの実装がコピコンの実装より効率的である保証が無い以上、
置き換え可能なケースであってもコピコンからムーブコンへの機械的置き換えは正当化されない

**デフォルトの名無しさん** · 2021/08/30(月) 14:34:41.72

天才のインフレ

**デフォルトの名無しさん** · 2021/09/01(水) 16:43:13.53

Rustみたいにコンパイル時にいちいち参照のチェックするんじゃなくて
C++で最終的に完成したバイナリに対してメモリサニタイザーを一回動かす
ってのではだめな理由ある？

**デフォルトの名無しさん** · 2021/09/01(水) 20:16:57.41

>>203 動かしたフロー以外のフローについて不安が残るし、サニタイザーの精度がどれほどかという問題もありそう。

**はちみつ餃子** ◆8X2XSCHEME · 2021/09/01(水) 23:35:30.93

>>203
ものによって賢さの程度が違うから一概には言えないけど
基本的にはサニタイザは実際に起こった問題を検出するものなので
入力値次第で問題が有ったりなかったりするようなケースを検出できなかったり、
言語仕様上で未定義なものがたまたま問題ないアクセスになってしまうようなケースも
検出できないかもしれない。

問題が起こっていて再現条件が分かっているときに検証するツール、つまりデバッグ用のツール
としてはサニタイザは有用だし、ごく基本的なテストツールとしても使えるけど、
Rust のライフタイムチェックほど網羅的ではない。

**デフォルトの名無しさん** · 2021/09/02(木) 05:18:49.53

一言でまとめると動的試験てことだな

**デフォルトの名無しさん** · 2021/09/03(金) 09:16:16.79

MozillaのFireFoxの場合、わざとクラッカーがセキュリティーホールを見つけ出して
そこを付いてくるから、普段の実行テストでは一度も発見できなかった
メモリーバグが問題になるが、普通のアプリの場合、ユーザーがわざとバグを
付くことはないから、そのようなホールはあまり関係ないと思う。
テスト駆動開発とかアジャイル開発とかも、普段使いで問題が無いかをテスト
することで大部分のバグが無い状態で開発していこうとする考え方。
それでもほとんどのメモリーバグは無い状態になっている。
メモリーバグがあると、普段使い的なテストをしても発覚することが多いから。
昔から言われているメモリーバグの問題点は、再現性が有る場合でも、バグが
ある行とそれが発覚した時期とがずれていることがあるから。
デバッグモードでコンパイラが自動的にチェックするコードを入れていれば、
それはなくなるはず。
Rustはその意味で、経験法則的にFireFoxみたいな特殊なものでは意味があるが
一般アプリでは余り意味が無い。ブラウザの特殊性は、世界中のクラッカーが
セキュリティーホールを探してわざとその穴を付いてくること。一般アプリでは
それがないので、隠れたバグは隠れたままになっていることが多くて、
テストで出てこなかったバグは実際問題的には余り問題となら無い事が多い。

**デフォルトの名無しさん** · 2021/09/03(金) 09:22:40.61

>>207
例えば、ダングリングポインタ(Use After Free)は、ptrがどこかでまだ使用中なのに、
free(ptr)としてしまうこと。しかし、そのfree()をした時点ではアプリはダウン
しないし、ptrに対して読み書きした段階でもまだ発覚せず、ptrが指すメモリー
アドレスを別の目的で使用してしまって、お互いに読み書きがある種の干渉を
起こしてしまって、データがめちゃくちゃになり、それによってどこかで不具合
が生じた時点で発覚する。
なので、バグの根本原因であるfree(ptr)を実行した行がどこかを探し出しにくいと
される。
しかし、このバグの場所とバグが起きた場所のずれは、デバッグビルド時に速度を
落としてチェックすれば本当は防げるはず。

**デフォルトの名無しさん** · 2021/09/03(金) 09:24:49.55

>>208
チェックと言っても人間が手で書く必要は無く、コンパイラがチェックコードを
自動生成できるはず。

**デフォルトの名無しさん** · 2021/09/03(金) 10:00:52.25

根拠のない決めつけばかりで気持ち悪い。

**デフォルトの名無しさん** · 2021/09/03(金) 10:16:16.17

>>207
世の中にはテスターという職種の人がいてだな

**デフォルトの名無しさん** · 2021/09/03(金) 10:46:20.27

>>207
任意のファイルを読むアプリはファイルのパーサーの脆弱性をついてユーザ権限でコードを実行される可能性がある
どちらかと言えばアプリよりサーバとしてアクセスを受け付けているプログラムの脆弱性をつかれて攻撃コードの実行を許してしまうことが多い
さらに上のような場合でも、アプリやサーバのプログラム自体に脆弱性があるのではなく、使用しているOSのAPI側の実装の脆弱性をつかれる可能性がある

こういうアプリやサーバやOSのコードの脆弱性にMSやGoogleは悩まされている

**デフォルトの名無しさん** · 2021/09/03(金) 11:00:44.84

Valgrind と言う動的解析ツールを調べて見るといい
うちはC++のプログラムは基本これを通すことになってる
商用ならもっといいツールもあるかも知れない
そういうのを利用しても充分でないから静的解析するRustが注目されている

**デフォルトの名無しさん** · 2021/09/03(金) 11:27:43.59

商用の静的解析ツール使ってると、正直メモリ関係のバグなんてありえないと思えるくらいいろいろ見つけてくれるよ

**デフォルトの名無しさん** · 2021/09/03(金) 11:44:23.16

コンパイル時間に糸目を付けなければ、静的解析はもっと出来る。

**デフォルトの名無しさん** · 2021/09/03(金) 11:47:10.63

> メモリ関係のバグなんてありえないと思える

lintの副作用がモロに出てるなｗ

**デフォルトの名無しさん** · 2021/09/03(金) 15:20:21.54

言うまでもない事だが完璧なメモリチェッカーは存在し得ない
停止問題と同値だからな

**デフォルトの名無しさん** · 2021/09/03(金) 15:50:45.07

完璧無理っておまえの毛髪の量がプログラム停止に与える影響が読めないとかそういう話だろ？
限定的な範囲で正しけりゃ十分だよ

**デフォルトの名無しさん** · 2021/09/03(金) 16:54:40.55

ゴールポストは動かしちゃダメだよ

**デフォルトの名無しさん** · 2021/09/03(金) 17:38:29.50

無限遠のゴールを設定するのはアホだべ

**デフォルトの名無しさん** · 2021/09/03(金) 17:51:18.36

スクリプト言語も普通にクラッシュすることあるから

**デフォルトの名無しさん** · 2021/09/03(金) 17:52:37.20

OSのコアダンプ出力とリブートに救われる手のひらの孫悟空

**デフォルトの名無しさん** · 2021/09/03(金) 18:28:35.67

rustでもメモリアロケーション失敗するとパニックになる、てリーナスが突っ込んでいたろ。
c++の場合はどうなんのかな。

**デフォルトの名無しさん** · 2021/09/03(金) 20:13:28.89

CoverityとVectorCASTは使ったことあるけど検知レベル最高にしても見逃すリークや二重フリー, ダングリングはそれなりにある (そもそもコードの構造が悪い場合も多いが)
検知レベル上げ過ぎると逆にFalse Positiveも増えるし

**デフォルトの名無しさん** · 2021/09/04(土) 07:59:49.00

無限遠のゴールポストを動かすって
こいつ文系か？

**デフォルトの名無しさん** · 2021/09/04(土) 08:08:40.61

まあ見つからないのは間違いなく書き方が悪いよな

**デフォルトの名無しさん** · 2021/09/04(土) 19:04:52.86

∞の概念が理解できるならそいつはもう文系ではあるまい

**デフォルトの名無しさん** · 2021/09/04(土) 19:11:19.50

ε-N論法

**デフォルトの名無しさん** · 2021/09/04(土) 22:28:42.31

超久しぶりにC＋＋の参考書買った。
いまってC++20までいってるんでしょ？

時代遅れもいいところだから勉強しようと思ってw

ただ読む気がおきない。
「pythonでいいか」って思いが・・・ww

**ハノン** ◆QZaw55cn4c · 2021/09/04(土) 23:52:57.58

>>223
https://tabesugi.net/memo/2009/1a.html
C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。

C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:

- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)

- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。

言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。

**デフォルトの名無しさん** · 2021/09/05(日) 00:05:05.82

バカが使いこなせる言語ではないからな

**デフォルトの名無しさん** · 2021/09/05(日) 00:27:52.33

linusに言われると返す言葉もないが、その後の文脈にある

『もし C++ で書かれた VCS が欲しいのなら、Monotone を見てみるといい。
ほんとに。連中は「本物のデータベース」を使っているよ。
「素敵なオブジェクト指向ライブラリ」も使ってる。「ナイスな C++ の抽象化」も
使ってる。そして率直なことろ、一部の情報系の人間が喜びそうな
これらすべての設計上の決定のために、できてきた結果はゲロゲロで
保守不可能なカオスだ。

でもあんたはきっと git よりも気に入るだろう。保証するよ。』

な感じでC++を気に入って、夢を見ていたいんだろうね。