C++相談室 part148

**デフォルトの名無しさん** · 2020/01/31(金) 20:54:06.26

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part147
https://mevius.5ch.net/test/read.cgi/tech/1576659413/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

**デフォルトの名無しさん** · 2020/02/12(水) 21:36:55.01

>>779
問題点はそこじゃない
移植時にコンパイラが問題点を見つけられないのが問題

**デフォルトの名無しさん** · 2020/02/12(水) 21:38:26.52

コンパイラが問題点を見つけられない例は他に山ほどあるが
だからといってわざわざ増やさなくても良い

**デフォルトの名無しさん** · 2020/02/12(水) 21:39:05.32

いや、問題があるなら移植する人が見つけろよ

**デフォルトの名無しさん** · 2020/02/12(水) 21:40:47.83

移植は完璧な人がする
なんて妄想は捨てた方が良い

**デフォルトの名無しさん** · 2020/02/12(水) 21:42:13.60

Cに移植する可能性が無いならどうでも良い
ちなみにキャストで警告が出る環境もある

**デフォルトの名無しさん** · 2020/02/12(水) 21:42:36.95

だからそれは移植する側の問題だろ。勝手にやれよ

**デフォルトの名無しさん** · 2020/02/12(水) 21:52:54.99

>>778
マクロとtypedefが被った場合どうなるか解ってる？

**デフォルトの名無しさん** · 2020/02/12(水) 22:12:26.79

もちろん

**デフォルトの名無しさん** · 2020/02/13(木) 00:16:13.58

>>733
Rustを少し見てみたけど、書き方が全くC/C++とは違っていて、
全く異なる文化圏の言語になれた人が設計した臭がした。
これがC/C++の代替になるとは考えにくい。
はっきり行って、これを使えといわれると辛い。

**デフォルトの名無しさん** · 2020/02/13(木) 00:26:27.60

テスト機能が標準で用意されてるのはいい

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/13(木) 00:45:52.57

個人的には Rust は好感触。
型システムは ML 系言語で実績があるものを基礎にしてることもあって、C++ のグダグダな歴史を背負ったものよりはまとも。
ML 系はやっぱり高級路線の言語だし、インデントでブロックを表す系統なのがしんどいけど、
Rust は上手く低レイヤ用 (としても使えるよう) に着地させてるし、 C 風の外観を踏襲してもいる。

C++ が Rust から取り入れられるものはそんなに多くないと思う。
C++ は良くも悪くも互換性についてかなり強い要求があるので、
Rust 的な、カッチリと保護された仕組みを後付けするのはどう考えても無理。
C++ が Rust を参考にすることは間違いなくあるとは思うが、
全体の思想がまるで違うので限定的な範囲でしか取り入れられない。

もし取り入れらたらそれは C++ の新機能として新しく学ぶので十分でしょ。

Rust を学ぶのは間違いなく有用ではあるけども、
Rust の知見が C++ に取り入れられる可能性がありそうだからという理由ならそんなに意味ない。

**デフォルトの名無しさん** · 2020/02/13(木) 01:02:46.91

C++の配列は長さの情報を持ってないってことになってるけど
長さを与えなくてもdelete[]できるんだから、メモリのどこかにその情報はあるよね？
なんでその情報をプログラマが利用できないようになってるの？

**デフォルトの名無しさん** · 2020/02/13(木) 01:06:29.86

rustがかっちり保護してくれるとか低レイヤー向けとか馬鹿ほど信じてるよね。
ありゃ帯に短し襷に長しの典型言語だわ。

**デフォルトの名無しさん** · 2020/02/13(木) 01:44:34.08

>>792
実際、Rustは、Cを簡単にするのではなく、Cを難しくしてしまっていて、Cのポインタが理解できない or 難しく感じる人には、Rustの特徴の核心たる所有権、借用などの部分はちんぷんかんぷんだと思う。

**デフォルトの名無しさん** · 2020/02/13(木) 01:48:50.73

>>793
Cの問題点を取り除いたと言うより、ほとんど全てのプログラミング言語が暗黙のうちに用いている代入の概念をなるべく使わないようにして変数束縛などの全く異なる独自概念を用いようとしている。
しかし、これは、手続き型言語と関数言語の違いに匹敵するくらいのプログラミングの概念の変更になってしまうため、手続き型言語の中で改良された次世代言語と言うものではなくなってしまっているとも言える。

**デフォルトの名無しさん** · 2020/02/13(木) 05:24:36.37

変数束縛って右辺値参照でしょ

**デフォルトの名無しさん** · 2020/02/13(木) 06:24:47.58

RustはC++なら簡単にできることをものすごく回りくどく書かないとコンパイル通らない感じだからとてもつらい

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

>>790
RustがC++に取って代わることがあるか、というニュアンスの質問でした
今C++でやってる仕事がRustに置き換わる可能性が高いなら今から勉強しとこうか、と

**デフォルトの名無しさん** · 2020/02/13(木) 12:35:22.33

>>797
断言してもいいが、RustはC++に取って代わることは無い。
なぜなら、普通の手続き型言語での枠組みにすら入ってない書き方を強要されるから。
手短に言えば、単にC/C++と書き方が大幅に違っているだけではなく、書き方が他のどんな減の範疇にも属していない。

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/13(木) 13:30:24.18

>>796
C/C++ でのオブジェクトの寿命の管理の難しさってのは
理屈が理解しづらいというよりはわかってても間違うという難しさなんだよね。
そして間違っていてもコンパイラは黙って通すことも多い。
C/C++ を長く使っていればそれを感じることって結構あるでしょ。
そういう部分のプログラムが正しいことはプログラマが保証しなくてはならんわけだ。
でも Rust では言語処理系の側でやってくれる。
C/C++ で面倒な部分を Rust では自動でやってくれる。
まわりくどいのは確かだけど、それで楽できるのも確かなので、
どっちを取るかって話だな。

オブジェクトをどこで後始末するか。
管理の主導権はどのモジュールに持たせるか。
そういうのって C/C++ でも考えてるよね。
C/C++ ではプログラムに書いてないだけで本来はあるはずのものなんだよ。
(C++ だとスマートポインタの導入で少し楽にはなったけど。)
自分が何を考えていたのか、そして何を考えられていなかったのが
明らかになるのはそれはそれで楽しいと思う。
まあ、それは俺が趣味でやってるからかもしれんな。

**デフォルトの名無しさん** · 2020/02/13(木) 13:34:58.25

おまえの設計がヘタクソなだけだろ

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/13(木) 13:45:30.52

>>800
そうだよ。
そんでもって大抵の人間は設計がヘタクソだし、
ヘタなところが検出されるなら検出されないより良い。

**デフォルトの名無しさん** · 2020/02/13(木) 14:01:13.64

>>799
変数束縛やら所有権や借用の概念が複雑すぎて、そっちの方が C/C++の
メモリ管理よりミスし易い。

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/13(木) 14:13:53.49

>>802
間違いなくミスし易いけどミスした箇所が検出できないということはあまりない。

**デフォルトの名無しさん** · 2020/02/13(木) 14:20:14.02

設計がヘタクソなヤツが書いたソースのメンテやらされるのは最悪だけど自分で組み上げるならC++以外有り得ない
各々の力量が顕著に表れやすい最高の言語には違いない
バカも容易に炙り出せるしな

**デフォルトの名無しさん** · 2020/02/13(木) 14:20:33.11

>>803
仮にあなたはちゃんと理解できても、一般のプログラマは変数束縛やら所有権や借用の概念を理解することが難しすぎるので、C/C++を置き換える言語にはならない。
それらの概念は学習コストが高すぎるどころか、一生理解できないプログラマが多いだろう。

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/13(木) 15:53:13.34

>>805
誤解のないように補足しておくけど、俺は Rust が C++ を置き換えるという主張はしてないからね。
C++ の重大な欠点を (実行コストをあまり払わない形で) 改善しているのは確かってだけ。
そんでもってそれが必要な場面は間違いなくあるってことも。

**デフォルトの名無しさん** · 2020/02/13(木) 19:21:34.29

>>791
わかる人いませんか？

**デフォルトの名無しさん** · 2020/02/13(木) 19:29:34.59

>>807
new TYPE[] のようにしてヒープから配列として確保されたメモリは確かに
要素数の情報を持っている。
しかし、new TYPEのように配列ではない場合は、高速化のために情報を
持ってない処理系もある。そのために前者では delete[] を、後者では
deleteを使うことになっており、間違った組み合わせを使った場合には
不具合を生じる。

また、ポインタは、ヒープから確保された配列ばかりをポイントしているとは
限らず、例えばスタック上のローカルオート変数や、グローバル変数をポイント
していることもあり、その場合には、要素数の情報は全く持っていない。

さらに、Cの場合、関数の引数に TYPE buf[] のように配列を書いても、
TYPE *buf に自動修正される仕様となっている。
そのため、配列を受け取るのは、必ずポインタということになる。
しかし、ポインタで受け取るということは、そこには、&a のように、
ローカルオート変数も実引数として指定して呼び出すことも出来る。
その場合には要素数が無いので、あなたの望みをかなえる高速な
一般的方法が存在しない。

望みをかなえるためには、言語の拡張が必要となる。

**デフォルトの名無しさん** · 2020/02/13(木) 19:33:05.83

Rustっていろいろ清々しいよね
関数型言語に必須じゃねえのと思うリスト関係がぽっかり抜けてるのは不満だけど

**デフォルトの名無しさん** · 2020/02/13(木) 19:57:05.87

>>807
https://ideone.com/DfYRYS

**デフォルトの名無しさん** · 2020/02/13(木) 20:01:17.55

>>808
ヒープに確保した配列の要素数はやはりメモリ上にあるんですね
手段がないのは文法として一貫性をもたせられないからということでしょうか
なるほど、回答ありがとうございます

**デフォルトの名無しさん** · 2020/02/13(木) 20:08:49.19

delete [] pと同じように
sizeof [] pを用意すりゃいいのにね
pがnew []されてなかったら誤動作するって挙動ならdeleteと同じだろうに

**デフォルトの名無しさん** · 2020/02/13(木) 20:15:32.26

言いたいことは分かるが構文がきもい

**デフォルトの名無しさん** · 2020/02/13(木) 20:17:34.65

欲しいなら作れば？
それができるのがc++じゃん

◆QZaw55cn4c · 2020/02/13(木) 20:36:41.73

>>791
＞C++の配列は長さの情報を持ってないってことになってるけど
＞長さを与えなくてもdelete[]できるんだから、メモリのどこかにその情報はあるよね？

new したときは、その領域サイズが実行時にユーザーのみえないところに保存される、というだけなのでは？
C/C++ の配列は長さ情報を（自分でそう書かないかぎり）持たないとおもいますよ

**デフォルトの名無しさん** · 2020/02/13(木) 20:38:39.62

ちゃうねん。

**デフォルトの名無しさん** · 2020/02/13(木) 20:50:05.52

設計がダメな場合コンパイラにいくら指摘されようと根本的には治らんのだが、
（たいていそういう馬鹿はコンパイラ通すためにmut,RefCell,unsafeを使いまくる）
そういうのを少しもわかってないバカがrust推しなんだよなぁ。
構造体を１から作り直さなきゃならんかったり根本的に間違ってる。

**デフォルトの名無しさん** · 2020/02/13(木) 21:00:18.27

>>808
new TYPE[]するとき内部的にサイズ情報を持つ保証ってあったっけ？
例えば自前でoperator new []を実装するとき、予め2^nバイトのブロックを所定の数用意しておいて、要求サイズに応じて必要十分な大きさのブロックを返すなら、割り当て時に要求されたバイト数または要素数の情報を保持しないという実装も可能かと思う。

**デフォルトの名無しさん** · 2020/02/13(木) 21:18:32.64

>>811
いえいえ

**デフォルトの名無しさん** · 2020/02/13(木) 21:37:18.24

>>818
デストラクタ呼ぶ必要ある

**デフォルトの名無しさん** · 2020/02/13(木) 21:39:24.09

デストラクタ呼ぶ必要ない型だと、size情報持ってないと言うことなんだろうね

**デフォルトの名無しさん** · 2020/02/13(木) 21:40:36.17

>>820
デストラクタの実装も、返ってきたアドレスの値でどのサイズの領域か(割り当て要求されたサイズではなく、自分で区切ったブロックのサイズ)が分かるようにしておけば大丈夫でないかな？

**デフォルトの名無しさん** · 2020/02/13(木) 21:41:24.98

>>822
すまん、勘違いでした。全部忘れてください

**デフォルトの名無しさん** · 2020/02/13(木) 22:02:22.87

はい忘れました。

**デフォルトの名無しさん** · 2020/02/13(木) 22:06:16.93

アドレスだけじゃなくて長さも受け渡しするインターフェースにしましょうとしか。

**デフォルトの名無しさん** · 2020/02/13(木) 22:36:33.13

シリアル化の王道ってありますか？

**デフォルトの名無しさん** · 2020/02/13(木) 22:45:19.55

オブジェクトならCORBA、データ構造だけでいいならASN.1とか。

**デフォルトの名無しさん** · 2020/02/13(木) 22:54:55.06

>>822
TYPEがデストラクタを持つclassの場合に、ptr = new TYPE[n] で確保されたメモリ
を delete[] ptr とすると、正確に n 回デストラクタを呼び出す必要がある。
new が n * sizeof(TYPE) より大きめのブロックを確保した場合でも、
delete[] ptr 時に正確な n の値を割り出す方法が必要となる。
なので、n の値は ptr の値さえあれば知ることが出来ることが必要条件となる。
つまり、少なくともデストラクタを持つ TYPE の場合に TYPE の配列をヒープから
確保した場合には、配列の要素数を必ず配列の先頭のポインタの値から「知る」事が出来る。

**デフォルトの名無しさん** · 2020/02/13(木) 23:01:33.00

>>827
もうちょっと簡単なのないですかね。
型情報要らないんで。

**デフォルトの名無しさん** · 2020/02/13(木) 23:09:58.23

型情報が無けりゃデシリアライズしても使いようがあるまい。

**デフォルトの名無しさん** · 2020/02/13(木) 23:12:32.63

それがあるんですよ兄さん。

**デフォルトの名無しさん** · 2020/02/13(木) 23:12:57.71

双方向mapって何使うのがいいですか？boostのbimap？
それともこのくらいは自作してる人のほうが多いですか？

**デフォルトの名無しさん** · 2020/02/14(金) 00:05:24.00

双方向Mapって何に使えるんですか？

**デフォルトの名無しさん** · 2020/02/14(金) 01:54:24.23

型情報ないならそもそもデシリアライズできないし
型情報なしで成り立つ、つまり型情報を事前に知っている前提なら
バイナリでそのまま送ればいいだろ

**デフォルトの名無しさん** · 2020/02/14(金) 02:05:36.33

型がわかっててもコンテナはそのままではバイナリで送れない

**デフォルトの名無しさん** · 2020/02/14(金) 02:11:15.54

>>834
そのやり方教えて。
あめさんあげるから。

**デフォルトの名無しさん** · 2020/02/14(金) 07:52:45.40

ちゃんとやるならPODに詰め替えてからchar配列へreinterpret_cast

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/14(金) 09:19:01.22

>>826
シリアル化ってのにどういう要件を置くかだな。
同じ環境でデシリアライズ出来ればよいのであれば >>837 で十分だろうし、
データ形式が決まってて (あるいはデータ形式の側を中心に策定したくて)
それのシリアライズとデシリアライズを (それぞれ別の環境で (ときには言語も違うかも)) やりたいということなら
protobuf などのツールを使うのはよい案だと思う。

**デフォルトの名無しさん** · 2020/02/14(金) 13:35:07.90

boostにあるじゃないですか
googleのなんか使うんじゃありません

**デフォルトの名無しさん** · 2020/02/14(金) 13:41:23.49

>>791
>>807
実装依存だと思うけど hoge[-1] あたりに格納されてた

**デフォルトの名無しさん** · 2020/02/14(金) 13:49:57.91

>>840
VC++の場合、ptr = new TYPE[n] で確保された場合は、確かに
ptr[0] == n
になっていた気がする。
「確かに」というのは言葉のあやで、厳密には覚えてないが、
VC++の new で使われる組み込み関数のライブラリのソースコードを見ると分かる。

**デフォルトの名無しさん** · 2020/02/14(金) 13:50:28.63

>>841
すまん、
ptr[-1] == n
の間違い。

**デフォルトの名無しさん** · 2020/02/14(金) 14:03:39.33

>>807
>>841
OSやコンパイラで違うんでしょ
https://ideone.com/DuTmC5

**デフォルトの名無しさん** · 2020/02/14(金) 15:26:11.39

>>842
あ、すまん、正しくは、大体、
　((DWORD *)ptr)[-1] == n
だ。
ptr[-1] だと、sizeof(TYPE)分、アドレスが戻ってしまうし、
結果の型も DWORD とかではなく、TYPE 型になってしまう。

**デフォルトの名無しさん** · 2020/02/14(金) 15:28:19.59

>>843
言っておくが、new char[n] とかでは、駄目な可能性は有るよ。
話は、「TYPEがデストラクタを持つとき」のnew TYPE[n]に限定。

**デフォルトの名無しさん** · 2020/02/14(金) 17:17:51.62

一時オブジェクトの寿命について、ご教示ください。
例えば、以下のようなコードがあった時、

void foo(const char* c); // 外部ライブラリの関数につき変更不可とする
void main()
{
const std::string s = "aaa";
foo((s + "bbb").c_str());
}

一時オブジェクトstring(s + "bbb")の破棄が行われるのは、
関数foo()を呼ぶ前でしょうか、呼んだ後でしょうか。
調べた範囲では、「完全式の終わり」という話が出てきたのですが、
どこまでが完全式なのか判断できませんでした。

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/14(金) 17:22:07.67

>>846
この場合はその行の終わり。
セミコロンのところだと思っていい。

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/14(金) 17:34:07.49

すごくどうでもいい話なんだけど、
JIS では完結式という用語を使ってるのに完全式って言葉の方がよく使われているよね……。

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/14(金) 17:59:01.70

>>846-847
式の一部であるような式が部分式で、
そうでないような式が完結式って言う。

**デフォルトの名無しさん** · 2020/02/14(金) 19:29:16.13

>>837-838
ありがとん。

**846** · 2020/02/14(金) 19:44:55.13

>>847-849
ご回答ありがとうございます。
大変勉強になりました。

**デフォルトの名無しさん** · 2020/02/14(金) 20:52:54.21

おいCぺろぺろ

**デフォルトの名無しさん** · 2020/02/14(金) 20:58:59.55

>>851
いえいえ

**デフォルトの名無しさん** · 2020/02/15(土) 10:34:21.20

newって意外と速いんだな。
アクセスは不利かもしれないけど。

**デフォルトの名無しさん** · 2020/02/15(土) 12:11:39.70

>>854
速いよ。
高速なゲームでも普通に使える。

**デフォルトの名無しさん** · 2020/02/15(土) 12:12:59.04

でもスタックは常にキャッシュに乗ってるから、そこらへんでどう変わるのかな。

**デフォルトの名無しさん** · 2020/02/15(土) 13:19:54.61

キャッシュに乗るくらいの量だったらそもそもクリティカルな重さにはならんだろ。
newで問題になるのは10万とかそのくらいのオーダーをがっつりfor文で呼ぶとかそれくらいのことする場合。

**デフォルトの名無しさん** · 2020/02/15(土) 13:21:27.11

スタックは常にキャッシュに乗ってる。

**デフォルトの名無しさん** · 2020/02/15(土) 13:23:13.35

>>857
風邪が騙りかけます

**デフォルトの名無しさん** · 2020/02/15(土) 14:11:39.55

>>857
VC++の場合、コンストラクタが無い場合、new が必要とする時間は 170クロック。
3.0GHz の CPUの場合、1.7 * 10^7 回(1,700万回)くらい new してやっと一秒
位。
だから、問題になるのは、1万回ループではなく、100～1000万回くらいのループ。

**デフォルトの名無しさん** · 2020/02/15(土) 14:15:19.79

もちろん、スタック変数で済むならスタック変数の方がいい。
ただ、スタックは容量に限りがあるので全部スタックという訳にもいかない。
ヒープにも限りはあるにはあるが、それは OSやマシンの限界。

**デフォルトの名無しさん** · 2020/02/15(土) 14:25:57.86

そこでgotoなんですよ。

**デフォルトの名無しさん** · 2020/02/15(土) 14:43:25.87

コレクションがソートの有無でだいぶ変わる。
trie_base_benchmark__sorted_words_1
trie assign.
409ms
size : 466551
words : 466551

trie insert.
762ms
size : 466551
words : 466551

std::set insert.
69ms

std::unordered_set insert.
149ms

(assigned) trie find.
24ms

(inserted) trie find.
25ms

std::set find.
194ms

std::unordered_set find.
63ms

**デフォルトの名無しさん** · 2020/02/15(土) 14:44:57.19

trie_base_benchmark__random_words_1

trie assign.
2034ms
size : 466551
words : 466551

trie insert.
2026ms
size : 466551
words : 466551

std::set insert.
490ms

std::unordered_set insert.
146ms

(assigned) trie find.
158ms

(inserted) trie find.
169ms

std::set find.
477ms

std::unordered_set find.
62ms

**デフォルトの名無しさん** · 2020/02/15(土) 14:46:37.02

挿入速度が変わるのは仕方ないとしても、検索速度が変わるのは、キャッシュじゃないかと思うんだけど。

**デフォルトの名無しさん** · 2020/02/15(土) 14:49:41.43

std::sort: 306ms, (466551count).
先にソートしてから挿入したほうが速度的にお得っぽい。

**デフォルトの名無しさん** · 2020/02/15(土) 16:03:09.29

>>854
速いといっても
単純な演算と比べれば劇遅

**デフォルトの名無しさん** · 2020/02/15(土) 16:18:40.81

>>867
とにかく、足し算/引き算が1クロック程度、new が170クロック程度だからね。
使い方を間違えなければ劇遅とはいえまい。

**デフォルトの名無しさん** · 2020/02/15(土) 16:32:01.46

auto hentai = SM(std::move(羞恥心));

**デフォルトの名無しさん** · 2020/02/15(土) 17:12:18.08

newより+のほうが速いってことか。

**デフォルトの名無しさん** · 2020/02/15(土) 17:25:57.34

+と-ならどっちが速いんだろう。

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/15(土) 17:49:06.00

>>871
回路はほぼ共有してるんじゃないの？
2の補数を使うのもそれが理由なんだろうし。
少なくとも Pentium 時代まではクロックは同じだったはず。

近頃の事情は知らんけど
GCC あたりで強い最適化をかけてみても引き算か足し算を特に避ける様子もないので、
まあだいたい同じなんでしょ。

**デフォルトの名無しさん** · 2020/02/15(土) 18:01:50.38

>>870
C++の場合、+ひとつだけでも裏でどんなコードが動くか油断ならない。

**デフォルトの名無しさん** · 2020/02/15(土) 18:13:26.25

>>871
+ と - で速度が違うCPUは見たことがない

- は順番が関係あるので
処理によっては遅い事がある

b = 1 + b
b = 1 - b

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/15(土) 18:14:19.52

整数だけの話じゃなくてってことか。
ある程度の常識的判断が出来る場合もあるけど、
基本的には実装次第だわな。

**デフォルトの名無しさん** · 2020/02/15(土) 18:19:46.61

組み込み型じゃなけりゃそりゃね
+ でミサイル発射とか

**デフォルトの名無しさん** · 2020/02/15(土) 19:02:33.35

>>870
new より + の方が 170 倍速いと言うことだ。

**デフォルトの名無しさん** · 2020/02/15(土) 19:04:43.75

>>874
一度bをnegateしてから足す処理系があるかもな

**デフォルトの名無しさん** · 2020/02/15(土) 19:30:46.15

>>874
確かに引き算には順序があるので、足し算より最適化に不利になることがある。