【初心者歓迎】C/C++室 Ver.104【環境依存OK】

**デフォルトの名無しさん** · 2018/12/28(金) 06:04:52.38

エスケープシーケンスやWin32APIなどの環境依存なものもOK
そのような質問は必ず環境を書きましょう
半角空白やタブでのインデントはスレに貼ると無くなります

コードを貼れる所
http://codepad.org/
https://ideone.com/

前スレ
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1530384293/

**デフォルトの名無しさん** · 2019/01/20(日) 21:20:28.02

はい誰もコード書かないw
お前らちっさいコードとか異常系の甘いコードしか書いたことないから例外マンセーなんだよ

**デフォルトの名無しさん** · 2019/01/20(日) 21:31:17.80

やっぱり例外機構はオカルトだった。皆が長い間この銀の弾丸を装った迷信に惑わされ疲弊した

**デフォルトの名無しさん** · 2019/01/20(日) 21:52:33.91

>>244
だから後出し条件出されると困るから戻り値スタイルでコード書いてくれ
って書いてあるだろ
例外とあまり変わらないんだから書けるよね？

**デフォルトの名無しさん** · 2019/01/20(日) 22:13:54.05

>>244
>>209

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/20(日) 22:17:29.98

あのなぁ、俺は他の機能についての話で何度か書いてるけど、
適切な場面で適切に使えってだけの話で、
どんな機能だってそんなに万能だと思ってるやつなんていねぇよ。

どうせ回復できない異常ならちまちまと返却値をとりまわして
上まで運ぶのはクソ面倒くせぇし、
その場で対処する必要があるようなものは
try/catch よりも if で書いた方が短くて簡単だし取りこぼしにくいってのはわかる。

どちらにするべきか判断を付けるコストの方がデカいわっていう場面なら
各プロジェクトのポリシーで一方に決めつけたって別にかまわん。

当たり前すぎて主張するのがアホくさいんだけど、
そんなことは場合によるとしか言いようが無いだろ。

**デフォルトの名無しさん** · 2019/01/20(日) 22:18:21.76

異常系の処理がシビアになればなるほど例外が有利になる
リターンコードスタイルは複雑化した分岐と大量の変数のせいでミスを誘発しまくる
例外ならば必要な時に必要なだけ異常系の処理を書けばいいので混乱することはない
例外スタイルにはまったく過不足がない
やりたいことをジャストそのまま書けばよろしい

**デフォルトの名無しさん** · 2019/01/20(日) 22:25:39.40

>>248
中身のない長文は要らんよ

**デフォルトの名無しさん** · 2019/01/20(日) 22:33:30.46

例外はその機構が重いから極端な異常系にしか使わないようにしてるのも今は昔の考え方なのかな

**デフォルトの名無しさん** · 2019/01/20(日) 22:36:51.24

>>250
ここ数10レスほど続いていた中身のない不毛なやり取りより>>248の1レスの方が有意義だと思うぞ

**デフォルトの名無しさん** · 2019/01/20(日) 22:39:23.56

>>252
お前もな～

**デフォルトの名無しさん** · 2019/01/20(日) 22:55:26.02

>>251
そもそも正常系では例外の方が速い

**デフォルトの名無しさん** · 2019/01/20(日) 23:31:58.94

>戻り値スタイルに慣れるとレイヤー境界がどこかも定義せずに例外変換をしてしまうようになっちゃうのかな

レイヤーの境界やエラーの粒度の違いに頓着しないのは、どっちかというと安直に例外投げれば良いと
考えている方のような気がするがな。
この一連の発言見ても、投げた例外が誤ってレイヤー境界を越えてしまわないようどう保証するかなんて
言及してた人いないでしょ。

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/21(月) 00:00:25.72

>>251
例外にもいくつかの方式があって、SJLJ ってやつは例外を投げないときもやたら遅いが、
他のほとんどの方式は例外を投げないときはゼロに近いコストのはず。

ただ、 SJLJ 以外の方法というのはデバッグ情報を使うためにツールチェインとの連携が必須だとか、
ハードウェアの機能を使うとかいった制約があって移植性に難があったりもするので、 SJLJ も滅びずに残ってる。

要するに例外の処理速度は場合によるが、
普通のデスクトップコンピュータで SJLJ を使わざるを得ないようなみみっちいツールチェイン、ハードウェアって
ことはあんまりなかろうと思う。 (ある？)

**デフォルトの名無しさん** · 2019/01/21(月) 00:16:50.05

>>255
リターンコードスタイルはレイヤ境界どころか体系的にエラー処理を考えるということをしないからなぁ
例外スタイルの人はじゃあどこで処理すんのということもちゃんと考えてる

**デフォルトの名無しさん** · 2019/01/21(月) 02:42:47.97

例外でイベント発生させて、イベントハンドラで受けるのはど？

**デフォルトの名無しさん** · 2019/01/21(月) 06:13:04.33

>>255
> この一連の発言見ても、投げた例外が誤ってレイヤー境界を越えてしまわないようどう保証するかなんて
> 言及してた人いないでしょ。
保証は言語側でやってくれるから言及する必要がないだけのこと
そもそも例外は>>249の言う通りその場所で必要なものをキャッチして処理をすればいいだけ

**デフォルトの名無しさん** · 2019/01/21(月) 07:28:30.34

swith caseで分岐する場合もあれば、
関数へのポインタテーブル作って、ジャンプさせる場合もあるわけで、
例外も戻り値分岐も両方普通に使わないか？

C++てイベントとかイベントハンドラは環境とかboost任せで、言語仕様としては未だに確定してないのか？
C++11でようやくマルチスレッドや排他制御が仕様に盛り込まれたり、
テンプレートの仕様いじくるよりこっちの方がよっぽど大事なんじゃないのか？

**デフォルトの名無しさん** · 2019/01/21(月) 08:25:41.60

>保証は言語側でやってくれるから言及する必要がないだけのこと

保証なんてしないよね？catch忘れたらそのまま上まですっ飛んでいくだけ。
Javaのような検査例外ならそこに差異があることを意識されられるかもしれないけど。

>そもそも例外は>>249の言う通りその場所で必要なものをキャッチして処理をすればいいだけ

そこでプログラマが考える「必要なもの」から漏れた例外は上位へ渡されてしまう。
それを防ぐためには呼び出し先から送られる可能性のあるすべての例外を把握する必要があるが、
検査例外がないなら動的型付言語のように投げる側と受け取る側とで平仄を合わせてやるしかない。

**デフォルトの名無しさん** · 2019/01/21(月) 08:37:50.82

大前提が間違ってる
例外なんか最終的にはフレームワークが最上位で纏めてキャッチすりゃいいんだよ
途中でキャッチして処理するのはあくまでベターなオプションであり、それを必須とするような作りにしてはいけない

**デフォルトの名無しさん** · 2019/01/21(月) 08:55:24.27

>>261
> catch忘れたらそのまま上まですっ飛んでいくだけ。
闇雲にキャッチしたいならcatch(...)ってやればいいだけ w
> そこでプログラマが考える「必要なもの」から漏れた例外は上位へ渡されてしまう。
本来キャッチが必要な例外を漏らしているならそれはバグ
それは戻り値スタイルでも同じ話
違うのは例外はキャッチする必要の無い例外についてはそこで考慮する必要はない、自動的に上位に渡されるから上位の然るべき場所で考慮すればいいから
それが>>249の言う
> 例外ならば必要な時に必要なだけ異常系の処理を書けばいいので混乱することはない
ってこと

**デフォルトの名無しさん** · 2019/01/21(月) 08:56:49.38

>>262
半分同意。
結局のところエラーの種類に応じてきっちり対処するなら検査例外的な仕組みが必要になるが
そうでなければエラーの内容など見ずにlet it crash的に対処するしかない。
どっちつかずが一番ダメなやつ。

**デフォルトの名無しさん** · 2019/01/21(月) 08:58:29.41

(検査例外とかいうJava自身も認める失敗作は論外として、)例外機構は正しく使えばエラー処理に対する関心の分離に有効なんだよ。
ところがC++では例外を煩わしいノイズと見做す人が多い。これは即ち関心の分離ができてないわけだ。
その一番の原因は、例外型がロクに標準化されてないことだろうね。
最上位での集約処理を実現するには、下位の全てのコードが制御下になければならない。
これは膨大な既存資産と貧弱な標準ライブラリを持つC++においては非現実的な前提である。

**デフォルトの名無しさん** · 2019/01/21(月) 08:58:39.64

すべての例外を把握する必要はない
回復可能かつ回復が要件に含まれるなら個別に処理すべき
それ以外はアスペクトで処理すればいい

**デフォルトの名無しさん** · 2019/01/21(月) 09:04:47.90

>>247
だからさ、比較できるように例外スタイルで一度きちっと異常系対応して
かつスーパーエレガントなのを書いてくれよって言ってんの
お前のは体よく異常系の処理全無視してるだけじゃん

catchしたい人が必要なところでcatchすればとか言うんだろうけど
例外発生場所から遠くなればなるだけ何が原因で例外が発生して、
その回避はどうすればいいかが不明瞭になっていくってのは
散々語られてる例外の欠点

リターンコードは泥臭いが下層からくるエラーをどう処理してるかはコード見れば一目瞭然
エラーを上位に伝搬させるか、リカバリーするか、その場でクラッシュさせるか
ローカルに記述が完結できてる
APIとして外部に公開するときもインタフェースの仕様にきっちり責任持たせることができる
ちなみにプルリクでレビューする文化があればエラー無視してるような雑はコードは突き返されるだろう
見ればすぐわかるんだから
大規模な開発を経験したことない人はこういう観点でソフトウェア開発を
考えられないんだよ

最後にもう一度言っておくけどおれは例外を完全否定してるわけじゃねーから
使える場所は限られるって意見ね

**デフォルトの名無しさん** · 2019/01/21(月) 09:07:50.76

>>262
> 大前提が間違ってる
> 例外なんか最終的にはフレームワークが最上位で纏めてキャッチすりゃいいんだよ

これがど素人の意見
ソフトウェアの品質について考えたことがない

**デフォルトの名無しさん** · 2019/01/21(月) 09:11:48.87

「不正な入力です」
「ネットワークでエラーが発生しました」
「書き込みに失敗しました」

こういう情けないダイアログが表示させて終わりのアプリを作るやつね

**デフォルトの名無しさん** · 2019/01/21(月) 09:19:18.64

>>269
それでも正常に回復できてるならそれでいいケースは多い
例外の最大の利点は例外安全さえ死守できていればアドホックな例外処理が必須でなくなることで、
より丁寧な処理が必要になれば後から追加すればよい
まあ組み込みとかやってる人には馴染まない考え方だろうね

**デフォルトの名無しさん** · 2019/01/21(月) 09:35:09.59

まあC++開発者が未処理例外=クラッシュと短絡的に考えてしまう気持ちはよく分かるよ
呼び出し階層の途中に一つでも if (hoge() != SUCCESS) errorhandle(); があれば例外安全は破綻するわけで、あまりにも非現実的

**デフォルトの名無しさん** · 2019/01/21(月) 09:54:05.98

>>267
仕様は>>218が決めるんだから>>218がコードを提示すべき
>>236みたいに後出しの条件出されても困るからな

**デフォルトの名無しさん** · 2019/01/21(月) 10:02:59.35

>>267
> 例外発生場所から遠くなればなるだけ何が原因で例外が発生して、
> その回避はどうすればいいかが不明瞭になっていくってのは
> 散々語られてる例外の欠点
それ戻り値スタイルでも同じだろ

> リターンコードは泥臭いが下層からくるエラーをどう処理してるかはコード見れば一目瞭然
だからそれはすぐ上位で処理することが前提になってるだろ
上位に何度も伝搬したら例外と同じになる上に伝搬するコードをそこら中に書く羽目になる

> ちなみにプルリクでレビューする文化があればエラー無視してるような雑はコードは突き返されるだろう
例外処理を書かないことはエラーを無視するんじゃなくてそのまま上位に伝搬してるだけ
書かないと無視してると取るのは例外をきちんと理解してないってこと

> 見ればすぐわかるんだから
お前の能力がな w

**デフォルトの名無しさん** · 2019/01/21(月) 12:21:37.48

>>267
例外を使いこなせていないね

例外の型とパラメータをみれば何が起こったかはっきりわかる
おそらく君は例外の種類を使い分ける習慣がないだろ？
あったとしてもせいぜい標準ライブラリの例外をなんとなくふり分ける程度だろうね
でないとこんな発言はしないから
まずは例外を定義するところから初めてごらん

それと大規模開発をしたことがないのはそちらだろう
関数コールするたびにずらずらと変数や分岐を書かれたらあっという間に管理不能になる
大規模だからこそ標準的なコード、必要十分なコードというのが大切になる

**デフォルトの名無しさん** · 2019/01/21(月) 12:52:23.62

リターンコードスタイルをレビューに出すと袋叩きにされるぞ

・ノイズが多すぎて正常系のレビューが不可能
・同じくどのエラーが上位伝達、エラー変換、共通対応、個別対応なのか見てすぐにわからない
・同じく要件漏れを見落としやすい
・正常系、異常系、判断、伝達などあらゆる要素が密集して強く結合しているため仕様変更があった場合の影響が大きすぎてレビューしきれない

**デフォルトの名無しさん** · 2019/01/21(月) 13:00:29.05

>>275
考え方自体には同意するけど、>>271で示したように例外安全が破綻しているケースについてどう考える?
エラーコードを前提にクリーンアップ処理が記述されているコードが混入しているような場合ね
あくまでC++に限った話だけど、大規模開発で完全な例外安全を維持するのは極めて困難だか実際には絵に書いた餅と思ってる

**デフォルトの名無しさん** · 2019/01/21(月) 13:01:15.22

>>276
訂正
極めて困難で、実際には絵に描いた餅

**デフォルトの名無しさん** · 2019/01/21(月) 13:05:57.47

レビュアーの経験値不足って感が否めない

**デフォルトの名無しさん** · 2019/01/21(月) 13:14:15.22

>>276-277
必要なら直せばいいだけ
非常に稀な事象についてまで例外安全を遵守する必要はないでしょ
そもそもそういう変なコードが混入してる体質の組織で何を言ってるんだよ？って話だと思うけど

**デフォルトの名無しさん** · 2019/01/21(月) 13:20:41.40

>>279
文化と素養の問題だよ
例外の是非でこれだけ荒れる現状を見てれば、例外のスルーなんて怖くてできねえよ
そりゃあんたが全てのコードをレビューしてマサカリ投げまくってくれるなら別だけどねえ

**デフォルトの名無しさん** · 2019/01/21(月) 13:46:08.82

>>280
ごめん、言ってることがよくわからん
そもそも
if (hoge() != SUCCESS) errorhandle();
なんてコードがあったら戻り値スタイルでもどうしようもない
例外は魔法の杖じゃないんだから何でもかんでも例外使えば解決するわけじゃなくて戻り値スタイルより楽にできるというだけの事だよ
プログラムがデカくなるほどその差は開くけど

**デフォルトの名無しさん** · 2019/01/21(月) 15:00:28.97

>>281
result = hogehoge();
if (failure(result)) エラー処理();
リソース解放();
これhogehogeが例外起こしたらリークするだろ

**デフォルトの名無しさん** · 2019/01/21(月) 15:09:35.03

>>282
スマートポインタ使うなりcatchしてリソース解放して例外再送出するなりいくらでもやりようはあるだろ…
ちょっとレベル低くね？

**デフォルトの名無しさん** · 2019/01/21(月) 15:25:30.15

>>283
だからそれが例外安全だよ
勉強になったね

**デフォルトの名無しさん** · 2019/01/21(月) 15:27:04.68

流石に恥ずかしくね？ w

**デフォルトの名無しさん** · 2019/01/21(月) 15:51:37.78

>>283
基本的にデストラクタやリソース開放系は例外投げられると大変なことになる
catchしてなんて簡単にいってるけどもcatch(...)をそこに入れることになるのはわかるかね

**デフォルトの名無しさん** · 2019/01/21(月) 16:15:33.27

で、そんな当たり前のことを言って何が言いたいの？
聞きかじりの知識を披露してるとしか思えないんだが… w

**デフォルトの名無しさん** · 2019/01/21(月) 18:01:37.80

例外機構は宗教
多くの人が正しいと盲信しているに過ぎない

**デフォルトの名無しさん** · 2019/01/21(月) 21:32:31.75

戻り値でイベント投げるという選択肢がない言語使用自体くそじゃね？

**デフォルトの名無しさん** · 2019/01/21(月) 22:06:05.18

Cにそんな機能あったっけ？
それとも別の言語の信者が折伏に来ているの？

**デフォルトの名無しさん** · 2019/01/21(月) 23:00:01.73

>>265
そう、検査例外を正しく使うのはしばしば困難で批判も多いな。ただ、呼び出す処理がどのような
例外を返すか、静的な型検査による保証を与えてくれる仕組みとしては他に無いのも事実。

検査例外を否定するのであれば例外型に頼らない(>>264の後者)か、プログラマの努力で
整合をとってやる(>>261の最後)カウボーイ的プログラミングになる。
>>265はあくまでも例外に型を期待しているようだからカウボーイの方なんだろう。

◆QZaw55cn4c · 2019/01/21(月) 23:52:35.55

>>291
＞プログラマの努力で整合をとってやる(>>261の最後)カウボーイ的プログラミングになる。

…
…
これって「カウボーイ的」と形容されるべきものだったんですか？

catch の引数は値ではなくて、「型」だから、
テキトーな super class ERROR の下に個別エラー用派生クラスを列挙しておき、
臨機応変に catch (ERROR &e) を噛ましています…

>>256
一応例外を投げておくけれども、まじめにサポートする気はさらさらなく、
そもそもやる気は皆無・全くゼロであることを、ただ、それだけを全心全霊で表現するためだけに

throw 13;

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/22(火) 02:54:09.24

例外の処理速度については、こういう提案もある。

https://ezoeryou.github.io/blog/article/2018-07-10-static-exception.html

要するに、投げるオブジェクトが条件を満たすときは、
暗黙の返却値のような形で例外を伝播する仕組み。
バイナリレベルの取り扱いも ABI を決めさえすれば済むだろうし、
互換性も確保しやすそうに思う。

**デフォルトの名無しさん** · 2019/01/22(火) 07:12:53.52

どう見ても例外否定派の方が宗教がかってる…

**デフォルトの名無しさん** · 2019/01/22(火) 08:50:21.38

環境の方の質問NGなら完全スルーでお願いします

Windows8.1 64bit のうえで Windows98SE でも動く C のバイナリを作ろうと思ってるのですが
LSI C 試食版以外に何か良い方法がないかなあと…

Windows98SE の方に Visual C++ 6.0 & SP6 をインストールしても良いのかも知れませんが
DLL の整合性とか不安
VC++ 2005 は iso 持ってるだけ…Windows98SE で動くバイナリが生成できるとか何とか

**デフォルトの名無しさん** · 2019/01/22(火) 09:09:13.74

業務で使った経験は一切ないです
使い捨てレベルのものを書くのが目的です

**デフォルトの名無しさん** · 2019/01/22(火) 12:47:22.45

TEST::TEST()
{
　うんたら
}

ってコンストラスタがあって、このクラスにパラメータ付のコンストラスタを追加したいとき
C# だったら
TEST::TEST(int param) : this()
{
　増やす機能
}
みたいに書きますが C++ の場合はどうやって書きますか

**デフォルトの名無しさん** · 2019/01/22(火) 13:28:39.91

TEST::TEST(int param) : クラスのパラメータ(param)
{
　増やす機能
}

**デフォルトの名無しさん** · 2019/01/22(火) 14:01:29.45

>>297
委譲コンストラクタでググると出てくると思う。
たしかC++11で追加された機能。

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/22(火) 14:03:25.02

>>295-296
LSI-C試食版って Windows 用どころか MS-DOS (16bit) の、しかもスモールモデルしか作れないじゃん。
使い捨ての、いいかげんな富豪的プログラミングしたらすぐメモリ足りなくなるぞ。

ワイとしては Open Watcom C++ を推すやで。

**デフォルトの名無しさん** · 2019/01/22(火) 14:11:32.02

>>295
https://bellard.org/tcc/
https://en.wikipedia.org/wiki/Tiny_C_Compiler
https://dyama.org/2012/11/tiny-c-compiler/
https://github.com/TinyCC/tinycc

**デフォルトの名無しさん** · 2019/01/22(火) 15:51:04.50

LSI-Cとかなっつｗ
昔の勉強用コンパイラといったらこれだったな

**デフォルトの名無しさん** · 2019/01/22(火) 16:10:30.87

LS愛ちゃん

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/22(火) 16:47:15.38

>>302
Cマガの付録CDに常に収録されてたよな！

**デフォルトの名無しさん** · 2019/01/22(火) 17:01:23.17

LatticeCとかBDS-Cとか使ってたわ

**デフォルトの名無しさん** · 2019/01/22(火) 17:22:22.39

>>298-299

TEST::TEST(int param) : TEST()
{
　増やす機能
}

で出来ました。ありがとうございました。

**デフォルトの名無しさん** · 2019/01/22(火) 18:21:52.81

bcc32c でコンパイルしたバイナリが Win98SE 上で動くことを確認…
Win98SE 上だと Turbo C が動くことを確認…

Open Watcom C++ というのは存じませんでした
確認してみます

**デフォルトの名無しさん** · 2019/01/22(火) 18:30:45.76

森公一郎さん、4年前に亡くなってる

**デフォルトの名無しさん** · 2019/01/22(火) 18:51:51.72

>>295
> VC++ 2005 は iso 持ってるだけ…Windows98SE で動くバイナリが生成できるとか何とか
なんで試さんの？

**デフォルトの名無しさん** · 2019/01/22(火) 20:54:28.21

DLL hell に躊躇

**デフォルトの名無しさん** · 2019/01/22(火) 23:43:17.99

LSI-C試食版ｗｗｗ
懐かしいなあ
あの頃はものすごくCPU遅かったよね
486にして感激したからな
もうC言語でプログラムはしたくない
C++だ・・・

**デフォルトの名無しさん** · 2019/01/23(水) 03:50:30.92

コメントに//が使えない時点でもうダメだな俺はw

**デフォルトの名無しさん** · 2019/01/23(水) 06:49:23.93

古いOSでも動作させたいけど、ソースは新しい規格で書きたい、
と言うのは要望としてはありうるな。

>>295 はLSI-C試食版(C89相当だっけ?)を使ってるようだから、
そのクチではないのかも知れんけど。

**デフォルトの名無しさん** · 2019/01/23(水) 07:14:34.51

>>310
今時なら仮想マシンでやればいいだけだろ

**デフォルトの名無しさん** · 2019/01/23(水) 08:57:06.72

>>312
コメント前に // つけるより
/*
コメント
*/

あるいは

#if 0
コメント
#endif

のほうがすっきりしないか？

**315** · 2019/01/23(水) 08:57:45.81

コメントが複数行にわたる前提ね

**デフォルトの名無しさん** · 2019/01/23(水) 09:18:31.94

だから何？
それに同意しようがしまいが単一行コメントのときに面倒なのは変わらないよね
個人的にはエディタがコメントの一括付け外しに対応してるなら複数行でも//の方が見やすいと思ってるけど

**デフォルトの名無しさん** · 2019/01/23(水) 09:36:35.20

C言語の a=b;　って
アセンブラで言うと、メモリ→レジスタ→メモリって移し替えてるのと同じ？
メモリ→メモリにデータコピーする時って、必ずレジスタを経由しないとだめなのかな？
アセンブラ勉強初めたばっかで何言ってんだこいつ的な感じだったらごめん。

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/23(水) 10:06:54.98

>>318
CPU の種類による。

アセンブラはアセンブラという言語の規格があるわけではなくて、
各コンピュータの機械語の単語を便宜的に読みやすい書式に置き換えた
ものの総称なので、使える命令は各アーキテクチャのデザインに従うし、
書式のバリエーションもある。いくつかの伝統的な習慣はあるけれど。

データの移送にレジスタを経由しなければならないようなデザインの CPU もあるし、
そうでないものもある。
メモリアクセスをする命令とその他演算の命令を明確に分離するようなデザインの
アーキテクチャを特に Load?store architecture と呼んでる。

https://en.wikipedia.org/wiki/Load%E2%80%93store_architecture

コンピュータの設計の根本を左右する方針の違いなので、
理解があやふやとはいえ、ここに引っかかりを感じたというのは才能を感じる。

**デフォルトの名無しさん** · 2019/01/23(水) 15:54:30.09

>>319
自分が勉強してたCPUがたまたまレジスタ必要とするものだったということですね。ありがとうございます。

あと、intelとryzenは、どちらのCPUであっても殆どのソフトは動作しますが
この2つのCPUのアーキテクチャオペランドは同じということでしょうか？
ゲームなんかは高速化の部分でアセンブラ使う場所も頻繁にあるんじゃないかなと思うのですが。

**デフォルトの名無しさん** · 2019/01/23(水) 16:07:56.74

すみません自己解決。
x64ですね。

**デフォルトの名無しさん** · 2019/01/23(水) 22:57:36.31

>>317
wwww
逆に、だから何？
エディタが/* 入力と同時に
*/ を自動挿入してくれるなら全く変わらないだろ
それともおまえのエディタは / 入力で
もひとつ/ を自動挿入するように設定でもしてるのか？
ゆとりもここまで来るとどーしよーもねーな。

**デフォルトの名無しさん** · 2019/01/23(水) 23:18:56.27

>>318
>>319
状況によるが、
a = b;
はメモリを介せず、できるだけレジスタ間コピーになるように最適化される。

んでメモリ to メモリを許すのはCISCと相場が決まってる
RISCはメモリ to メモリは命令にない。命令セットを減らしてるからこそ reduce
このおかげで回路が簡単になり、所用クロック数をほぼ等しくして、クロック(Hz)をあげることができた。
このタイプはメモリ→レジスタ→メモリとせざるを得ない

今は、パイプラインを深くして、CISCでもクロックをあげられるようになったのでRISC/CISCはあんまり関係なくなった。
CICSの代表はx86なのでメモリ→メモリ命令セット調べてみ。
CISCの歴史的な経緯がわかるのは、これもCISC代表のx68kやH8は、命令セットごとに大幅に所用クロック数が違う。
それに対してx86の流れをくむ最新設計のRL78だとほとんどの命令セットが1クロックとなって。RISCと変わらない上に、
メモリ to メモリが可能となってる。それでもメモリ to レジスタに比べて1クロック増えてる。
メモリ to メモリとレジスタ to メモリを同クロック数で実行しようとするなら、バスラインがもう一組(例えば32bit)必要になった上に、
2ポートメモリが必要になってしまうwwww

**デフォルトの名無しさん** · 2019/01/23(水) 23:20:08.21

アンカー違い
× >>319
○ >>320

**デフォルトの名無しさん** · 2019/01/23(水) 23:21:30.54

>>322
自分で複数行が前提だと言っときながら何言ってんの君

**デフォルトの名無しさん** · 2019/01/24(木) 00:07:57.67

>>325
*/の自動補完は複数行だろうが単一行だろうが関係ないだろが。
おまえがエディタ支援による入力補助を持ち出したから応じてやっただけだろゆとり
入力の手間はむしろ/* */の方が楽なんだよお馬鹿さん

**デフォルトの名無しさん** · 2019/01/24(木) 00:17:17.17

>>325
それとさ俺が複数行限定といってるのに
>>317
>単一行コメントのときに面倒なのは変わらないよね

また単一行の話をしてるのはそっちだろーが。
おまえは朝鮮人か？それともボケてんのか？

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/25(金) 04:31:55.12

まあ例えばインテルアーキテクチャでも、
機械語の命令列を内部で μop に分解して最適化してから実行したりするので、
機械語のレベルなんてまだまだ高級な層。

内側では RISC 的なデザインとも融合していて
正直言って、そこで何が起きているのか正確に理解するのは無理。
(結果に影響しない範囲で) 命令を並べ替えることすらあり、
しかし、マルチスレッドと絡むとわけわかんなくなりがち。

Z80 の牧歌的な世界を知ってると隔世の感がある。
実際、演算能力で言えば何百倍とか何千倍とかいう規模で違うもんな……

**デフォルトの名無しさん** · 2019/01/25(金) 04:48:14.16

Z80Aで、おおむね4Mhzだったような
無印Z80は知らない

日本人だとZ80AよりμPD870Cの方が普及？？？

**デフォルトの名無しさん** · 2019/01/25(金) 05:29:09.86

>>329
μPD780C-1な。870だと電卓チップになってしまう。

詰めが甘いな :-P

**デフォルトの名無しさん** · 2019/01/25(金) 09:28:14.11

>>328
自分もこの結論に達した

**デフォルトの名無しさん** · 2019/01/26(土) 10:50:23.69

初心者です
関数の引数の1つとして3種類の構造体を受け入れたいという場合オーバーライドで3つ書くのよりスマートなやり方ありますか？

**デフォルトの名無しさん** · 2019/01/26(土) 11:07:13.35

オーバーロードで3つ書く方がスマートですよ

**デフォルトの名無しさん** · 2019/01/26(土) 11:19:38.97

関数テンプレートというものが一応存在する。

tempate<class T> void func(T arg)
{
...
}

このように記述すると、型に応じたオーバーライドをコンパイラが自動で作成してくれるという機能。
ただ、実際に呼び出すコードを書かないと（型が確定してないから）コンパイル対象にならなず限定的なエラーチェックしか行われない、
エラーが出た時に問題が関数内なのか呼び出し元なのかが分かりづらい、エラーメッセージもわけわからない、という欠点があるので、
あまり初心者向きとは言えない。すごく便利なんだけどね。

**デフォルトの名無しさん** · 2019/01/26(土) 13:38:51.24

>>333-334
ありがとうございます
オーバーロードでしたね＾＾；

**デフォルトの名無しさん** · 2019/01/26(土) 17:08:07.75

>>335
Variantが使えるならVariant
対照的にunionはおすすめしない

**デフォルトの名無しさん** · 2019/01/26(土) 18:04:32.62

結局中で分岐だろ

**デフォルトの名無しさん** · 2019/01/27(日) 04:46:54.79

>>336
variant勉強します
ありがとうございます

**デフォルトの名無しさん** · 2019/01/27(日) 23:53:20.30

投機実行がセキュリティホールになるなんて
当時の技術者は予見できたのだろうか

**デフォルトの名無しさん** · 2019/01/30(水) 21:22:57.38

いやー
論文ネタに困った情報系の役にたたん学者がひねり出したネタだろ
投機実行を攻撃に使った実例なんてあるのか？

**デフォルトの名無しさん** · 2019/01/31(木) 10:11:52.05

煽ってたら論文ネタに困った情報系の役にたたん学者が投機実行を攻撃に使った実用法をひねり出したらどうすんだ

◆QZaw55cn4c · 2019/01/31(木) 23:01:04.87

>>340
手元にようやく SandyBridge(IvyBridge) を確保しましたのでいろいろ試してみようと思っています

**デフォルトの名無しさん** · 2019/01/31(木) 23:07:28.54

Googleだったっけ、見つけたのは？
役に立たない暇な部門があったんだ

**デフォルトの名無しさん** · 2019/02/02(土) 08:27:42.12

C++って未だにasync,awaitがないんだな？
江添とかtemplate使えないC++プログラマはポインタを使えないCプログラマと同じゴミとかいってるんだが、
templateは確かに面白いし頭の体操になるけど、templateはひな形があれば、泥臭くエディタちょい編集して使い回したり、
yacc/lex使うとか、ループのアンロールはスクリプトで展開するとかいくらでも手段はあるので、
どう考えてもasync,awaitあたりの実装の方が重要だと思うけどな。