C++相談室 part137

**デフォルトの名無しさん** · 2018/07/14(土) 17:53:02.14

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

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

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

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.102【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1509780815/

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

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

----- テンプレここまで -----

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

**デフォルトの名無しさん** · 2018/08/02(木) 21:22:49.70

コンパイラ読めないと話にならんのじゃないか？

**デフォルトの名無しさん** · 2018/08/02(木) 21:53:24.64

>>480
職場に何を頼るの？

**デフォルトの名無しさん** · 2018/08/02(木) 22:18:49.50

>>476
jpegが赤に弱いなんてのも
ギョーカイの人とのおつきあいで
ホーソレデ氏になった

**デフォルトの名無しさん** · 2018/08/02(木) 22:24:42.73

>>480
読んでばかりじゃなくて自発的に自分で実際に書いてみないことには、いつまでたってもたいして身に付かないだろう。
極めたいなら、言語仕様の一つ一つを実際に使ってみて具体的に役立つケースや制限、制約、限界を体感して、メリットデメリットを洗い出すくらいのつもりで試してみたら？

**デフォルトの名無しさん** · 2018/08/02(木) 23:26:26.75

>>482
嫌‥
>>484の言うとおり実践的な立場かな
>>484
それはもちろん分かる

**デフォルトの名無しさん** · 2018/08/03(金) 02:17:39.89

>>485
まずは仕事で使う自作ツールをC++で書くとか
千里の道も一歩から

**デフォルトの名無しさん** · 2018/08/03(金) 02:23:34.66

自作ツールはまず、スクリプト言語でやってみて、速度面などで不満があった時だけC・C++に置き換えるのがいいと思うけどどうなの。
スクリプト言語とコンパイル言語の使い分けを覚える良い機会になる。

**デフォルトの名無しさん** · 2018/08/03(金) 02:28:52.17

>>487
目的が自作ツールを作ることならそれで間違ってないが
C++を極めることが目的みたいよ

**デフォルトの名無しさん** · 2018/08/03(金) 07:41:26.05

極めると言うても、次の規格が出たらもう過去の知識だし、
いくら頑張っても到達できないゴールのような気がするなぁ。
規格を作る側に入り込めるなら話は違うかも知れんが。

C++は、自分より後ろにいる人をバカにするのが好きな人も多い感じだけど、
「そんな奴にはならん方がええ」

**はちみつ餃子** ◆8X2XSCHEME · 2018/08/03(金) 08:11:10.53

ある程度の言語機能しか使わない範囲でも使い物になるように C++ は設計されてる。
ある程度を学めばその範囲内でも実務に使える。
もちろん深い理解があればプログラムをよりよく構成できるので、
実務に使いながら平行して段階的に学ぶということが出来る。
このことは設計者が著した D&E に書かれてる基礎理念のひとつだ。

地に足の着いた、現実的なものとして設計されてるんだよ。
だから、言語としての C++ だけに偏って学ぶのはお勧めできない。
言語として不格好な部分も現実の中では相応の合理性があったりして、
それを学習するのに適しているのは現実のプログラミングだと思う。

ただ、余談だけど、段階的に学べるようにというのはスタート地点として C を想定しているように思う。
C が当然の基礎知識としてあった時代には
そこからシームレスに C++ を学んでいけるように設計するのは妥当な選択だったかもしれないが、
今の時代には C++ の中の C の部分は色々と足を引っ張ってもいるので
歴史が長いと泥臭い部分も積み重なっていくものだなぁと思いました。 (小並感)

**デフォルトの名無しさん** · 2018/08/03(金) 10:14:53.94

20年近く使ってるけど、ドラフトとか目にしても
「こんな機能来るんや！」ってwktkするだけだな
規格を知ってれば極めてる、みたいな風潮が最近あるけど間違いやで
言語はあくまで道具だから使ってなんぼ

**デフォルトの名無しさん** · 2018/08/03(金) 10:29:03.00

みんな深いレスありがとう
ただ自分はどうしても諦めきれないので、仕事以外の時間は、C++に関するサイトや書籍やコーディングに費やすことになると思う
Pythonは学ぼうとは思ってるけどね

**デフォルトの名無しさん** · 2018/08/03(金) 10:49:41.39

ttps://github.com/python/cpython/tree/master/Python

今ならpythonのソースコードもオマケで学べるよ

**デフォルトの名無しさん** · 2018/08/03(金) 12:16:04.74

>>493
ありがとう
こういうのはいいですね

**デフォルトの名無しさん** · 2018/08/03(金) 15:41:42.81

スクリプト言語には、ハッシュテーブルやディクショナリなどと呼ばれるキーと値の組を保存するコンテナ機能が存在する。
一般に高速とされるC++だが、実は、ハッシュテーブルだけはスクリプト言語の方がアクセス速度が速かった。
ただし、C++におけるstd::mapだけがハッシュテーブルに該当した頃の話。

今は、std::unordered_mapがあるのでスクリプト言語と同等以上の速度でハッシュテーブルにアクセス可能になっている。

**デフォルトの名無しさん** · 2018/08/03(金) 18:32:37.47

mapはハッシュテーブルに該当しないだろ。
そういうときは辞書とかマップとか連想配列とかと呼ぶべきだ。

**デフォルトの名無しさん** · 2018/08/03(金) 18:52:42.14

mapは連想コンテナだが

**デフォルトの名無しさん** · 2018/08/03(金) 19:03:27.95

ハッシュテーブルじゃない

**デフォルトの名無しさん** · 2018/08/03(金) 23:13:28.65

クラス設計で悩んでいるんだが、みんなの意見を聞きたい
やりたいのは、いわゆるデザインパターン template methodを使ったクラス設計

class Parent {
public:
void execute() {
method1();
method2();
method3();
}
private:
virtual void method1();
virtual void method2();
virtual void method3();
}

子クラスのChild1, Child2でmethod1(), method2(), method3()をそれぞれオーバーライドして処理を分けている
ここで、Child3を追加しようと思うんだけど、method1()の内容はChild2::method1()と全く同じになる
これをどう実装しようかいろいろ悩んだんだが、どれもピンとこない。
そもそも最初の設計がおかしーんじゃねーの？とかこうしたらよくない？とかここおかしくね？とか意見あったら頼む
一応以下は自分が考えていること

①Child2, Child3の親クラスを抽出して、そっちに共通処理として書く
→実装のために継承関係を作るのはあまりよくない気がする
②別クラス（Utilクラス？）を作ってそっちにまとめる
→メンバ変数とか使ってると少し面倒かな。本質的でない気もする。
③Child3::method1()->Child2::method1()とコンポジション的にする
せっかく横のつながりができないようにしてるのに、ここでできるのはよくない
④親クラスに共通メソッドを作って、Child2::method1()とChild3::method1()はそれを呼ぶ
→しっくりこないけど、妥協点かな・・・
⑤しゃーないChild2::method1()コピペで！
→これはまあ論外かな、時間が全くないときの最終手段

**デフォルトの名無しさん** · 2018/08/03(金) 23:20:08.01

Child3をChild2の子にすれば？

**デフォルトの名無しさん** · 2018/08/03(金) 23:22:51.86

共通処理を継承関係と無縁なtemplate関数にできないか検討してみては？

**デフォルトの名無しさん** · 2018/08/03(金) 23:26:40.59

>>500
それは多分なんらか整列の問題でやりたくないんだと推測
俺なら４かな・・・

**デフォルトの名無しさん** · 2018/08/03(金) 23:28:34.49

４の改良？として
実装ファイルの無名スコープにvoid method1(const Parent& p)かな

**デフォルトの名無しさん** · 2018/08/03(金) 23:36:56.13

派生させるんじゃなくてメソッドの処理を別クラスにして移譲させるんじゃないの？

**デフォルトの名無しさん** · 2018/08/04(土) 00:12:06.53

>>499
> 実装のために継承関係を作るのはあまりよくない気がする
と言いつつ
> 親クラスに共通メソッドを作って、Child2::method1()とChild3::method1()はそれを呼ぶ
とか意味わからん
全然関係ないのにたまたま一緒になったと言うなら
> しゃーないChild2::method1()コピペで！
しかないと思うが

**デフォルトの名無しさん** · 2018/08/04(土) 00:38:11.84

コーディング規約で、引数や戻り値に参照型は使うな。わかりにくくなるから。ポインタで渡してポインタで返せ
ってことになってるんですけどこれ一般的な考え方なんですかね。生ポインタ使いまくりの方がよっぽどわかりにくいと思うんですけど

**デフォルトの名無しさん** · 2018/08/04(土) 00:53:09.47

そんなことよりﾒｿｯﾄﾞでｸﾗｽのｲﾝｽﾀﾝｽが変更されない場合
そのﾒｿｯﾄﾞにちゃんとconstつけろよ

引数でｸﾗｽ使う場合も、そのｸﾗｽのｲﾝｽﾀﾝｽが変更されない場合
その引数にちゃんとconstつけろよ

わかった？

**デフォルトの名無しさん** · 2018/08/04(土) 00:58:03.49

>>506
言ってることがわからなくはないが一般的ではないと思う
むしろ参照のほうが一般的な気がするな

**デフォルトの名無しさん** · 2018/08/04(土) 01:05:30.18

引数については、読み書きする引数は注意をひくためにポインタ渡しにして、読み取りだけの引数は参照渡しにするといいのでは。
戻り値については、失敗したことを意味するNULLを使えるのでポインタのほうがうれしいかも。

**デフォルトの名無しさん** · 2018/08/04(土) 01:06:58.94

>>499
execute が virtual でないってことは
Parentを基底にしてコレクションしなくてもいいってことでOK?

>>501 の言うように template で mixin 的に書いたら　こんな感じになったー
https://ideone.com/CcRHnO
ChildがKlassになって兄弟関係がなくなってる

**デフォルトの名無しさん** · 2018/08/04(土) 01:12:24.24

戻り値なんか全部intでいい
0未満ならすべて一貫してすべてｴﾗｰ
失敗がありえないﾌﾞｰﾘｱﾝだけはかろうじてあり

引数をﾎﾟｲﾝﾀで渡せないとNULLを渡して処理したい場合の処理ができない
そういうとき困るから全部ﾎﾟｲﾝﾀで

**デフォルトの名無しさん** · 2018/08/04(土) 05:12:55.60

素人ばっかりかw
「More Effective C++」の項目1 だろ

Effectiveも読んでいない奴が、プログラミングやってるのが不思議。
どの言語でも、Effectiveは、入門書の次に読む本やぞ

参照は、確実にNULL じゃない場合。
また、参照に再代入はしない事

**デフォルトの名無しさん** · 2018/08/04(土) 05:25:27.41

HRESULTも知らないヒヨッ子がいきってるな

**デフォルトの名無しさん** · 2018/08/04(土) 06:40:25.30

参照に再代入ってどうやんの

**デフォルトの名無しさん** · 2018/08/04(土) 07:29:12.24

cからのコードが多い場合は統一のために参照渡しにしないってのはあるかな。

**デフォルトの名無しさん** · 2018/08/04(土) 07:33:54.06

extern "C"に参照渡しなんかするかよ

**デフォルトの名無しさん** · 2018/08/04(土) 07:42:44.96

たかが参照にストレスを感じるようになったら、C/C++プログラマをやめた方がいい。引退時。

**デフォルトの名無しさん** · 2018/08/04(土) 08:00:44.90

>>506
C++を知らない老害が自分の為に決めた規約
積極的に逆らおう

**デフォルトの名無しさん** · 2018/08/04(土) 08:29:49.29

私見を言わせてもらうと、多様性を受け入れ状況に合わせて柔軟に合わせていくのもプログラマあるいは技術者の重要なスキルなので、
一神教的な偏狭な人は若年性認知症とまで言ってのける気はないがかなり情報処理能力が低くなっているはずなので、プログラミングをやめた方がいい。

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

プログラミングがどうこういうより国語を勉強しろ。

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

柔軟なのと規約を決めないのはまた別だけどね。
多様性といって新しい言語使って同じ過ちを繰り返している人を何人も見てると
色々バカバカしくなるってところはある。
老害と同じくらい歴史を見ない若造も有害という現実を見るのも良い。

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

まあ少なくとも>>506が老害であるのは確か
実務経験が少ない若者が多いのも当たり前

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

老害なんて言っている奴、10年後に自分がそう呼ばれるって事気がついてないのかな・・・

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

老人全てが老害になるわけではない
害があるから老害と呼ばれる

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

>>521
歴史？

過去発生した問題点や注意点を伝えるのは上司や先輩の役目

言語自体の歴史、CPU自体の歴史なんか
興味があるヤツだけ勉強すれば良い

**デフォルトの名無しさん** · 2018/08/04(土) 10:02:32.30

数人のグループで開発しているなら、あえてコーディング規約を設けずしても出来るだろうが
100人、1000人規模で開発しているなら、工業製品としての品質管理として必要になるでしょう

**デフォルトの名無しさん** · 2018/08/04(土) 10:03:35.96

>>525
ぼくがしらないのはまわりがおしえないから
さすがゆとり

**デフォルトの名無しさん** · 2018/08/04(土) 10:08:29.90

ん？
おれは伝える側の人間だが

**デフォルトの名無しさん** · 2018/08/04(土) 10:11:50.81

100人規模1000人規模のソフト開発で
若者に言語の決定権があるってのは
すごい会社だね

**デフォルトの名無しさん** · 2018/08/04(土) 10:20:39.15

おかしくはない

好きにやれ動くブツだけもってこい

**デフォルトの名無しさん** · 2018/08/04(土) 10:27:14.97

いや別に好きにすればいいとは思うのだが
勝手に自分で選んだ言語固有の問題にぶち当たって
人に泣きつくなっつー馬鹿みたいな話があまりに多いんで。
>>525
まともに聞いてくれれば問題ない。

**デフォルトの名無しさん** · 2018/08/04(土) 10:54:42.16

出来たばかりの最新規格の機能ならともかく
C++98以前からずーっとある言語の基本機能を大した理由もなく縛ってるのは阿呆でしょ
（「大した理由」があるなら縛ってもいいのよ、本当に大した理由ならな）

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

>>460
横だがDLLにstd::stringとかSTLのオブジェクトを渡したり返したりする設計ェ、、、
std::string程度なら現実には動くが、STLの内部動作のバージョン間の整合を誰も保証してくれない以上、
そういう設計をされるともはや誰も動作を保証できなくなる

STLに限らずOpenCVやCRT絡みのオブジェクトでもそう、
というわけでこういうライブラリのバージョンの統一を担保できない状況ではchar[]の登場と相成りぬ、

**デフォルトの名無しさん** · 2018/08/04(土) 11:20:42.46

char[]を使う関数をDLLにして、その関数をstd::string版関数オーバーロード的なラッパーをヘッダーに記述するでしょ、普通。
というか、std::string専用である必要はなく、template関数にしとけばSTLportだろうかstdだろうかEASTLだろうが対応可能になる。

**はちみつ餃子** ◆8X2XSCHEME · 2018/08/04(土) 11:23:58.97

バイナリでの保証を考えると STL を使いにくいってのは確かにあるよな。
COM のような形式を使えばオブジェクト指向をバイナリレベルで管理することも出来るが、
それはそれで別の規約に縛られてしまうわけで。

どんな規約にするにせよ不満は有るよ。
一貫した規約が無い不満よりは規約に不満を持つ方がマシな世界になりがちなのが現実。

**デフォルトの名無しさん** · 2018/08/04(土) 11:33:14.55

そんなもん文字列のﾎﾟｲﾝﾀ渡せばしまい
頭悪いのって悩む必要がないどーでもいい事で悩むからな

それぞれの完結したﾓｼﾞｭｰﾙでどのﾊﾞｰｼﾞｮﾝのSTL使おうが関係ないからな

string ahoをaho.c_str()で渡すだけ

**デフォルトの名無しさん** · 2018/08/04(土) 11:50:08.73

>>534
ﾜｶﾙ
それは全く普通の設計でおすなあ、

**デフォルトの名無しさん** · 2018/08/04(土) 11:54:01.62

頭悪いｼﾛｳﾄほど可変長の文字列ｸﾗｽをいちいち使いたがるからな

**デフォルトの名無しさん** · 2018/08/04(土) 11:57:27.88

もしかしてvectorとかもいちいち自分で全部ﾗｯﾌﾟしってんの
とにかく頭が悪すぎるわ

**デフォルトの名無しさん** · 2018/08/04(土) 11:59:57.25

ここで問題なのは可変長の文字列クラスを使いたがる類の素人なのではなくて、
DLLのcallerとcalleeでSTLやCRTのバージョン相違しているケースを想像できない類の素人なのでは…

**デフォルトの名無しさん** · 2018/08/04(土) 12:07:08.58

このｽﾚにいるような知恵遅れがどんな作り方しても
ぜんぜん問題にならない

STL ver baka
void bakabaka(char const* aho_) {
　std::string baka("shine");
　ahoaho1(baka.cstr());
}

STL ver aho つかったdll
void ahoaho1(char const* aho_) {
}

なにが問題になるわけ？
もうね知恵遅れのいうことは意味が分からないわけ

**デフォルトの名無しさん** · 2018/08/04(土) 12:08:24.92

>>484
極めて同意
仕事だと、過去のしがらみや、コーディングルール等に縛られて、思い通りにできない。
自分で地道に実験してゆくしかない

**デフォルトの名無しさん** · 2018/08/04(土) 12:16:41.91

いやほんと
呼び出し元と同じ完結したモジュール内で定義された関数にはconst std::string& ahoやconst std::vector &vecで渡し、
DLLで定義された関数にはaho.c_str()や&(vec[0])で渡す、と区別すればwrapperは要りませんなあ、
いやはや>>541は便利なやり方をいろいろご存知ですなあ、、

◆QZaw55cn4c · 2018/08/04(土) 12:54:24.58

>>519
「～なので、～なので、○○だ」
読んでとまどいを覚える日本語文ですね

◆QZaw55cn4c · 2018/08/04(土) 12:56:26.35

>>532
K&R2 の世界の人にとっては、十分に未知な領域なのでしょう…
私は K&R2 自体がすでに「堕落したもの」と考えております

**デフォルトの名無しさん** · 2018/08/04(土) 13:59:14.93

>>506
某エディタにこの宗教にご執心の開発者がいるな

**デフォルトの名無しさん** · 2018/08/04(土) 18:05:43.06

ポリモーフィズム(多態性)を可読性を下げる欠点ではなく、可読性を上げる長所と考えるのがC++プログラマとしての信仰の基本なので、
様々な記述方法を許す多態性を嫌うのなら、C++を棄教せねばならないでしょう。
演算子オーバーロードを耐えられる情報処理能力があるなら、参照渡しにも耐えられるはずで、参照渡しだけ目の敵にするのはただの原理主義ですね。

**デフォルトの名無しさん** · 2018/08/04(土) 18:58:53.47

原理主義なんて高尚なもんじゃなくただのバカ

**デフォルトの名無しさん** · 2018/08/04(土) 20:01:37.83

>>547
なのでなのでは？

**はちみつ餃子** ◆8X2XSCHEME · 2018/08/05(日) 00:20:51.12

>>547
言葉のニュアンス的には原理主義というより教条主義と言った方がこの場合は近いかも

**デフォルトの名無しさん** · 2018/08/05(日) 05:07:56.69

だれかたすけてください。
https://dotup.org/uploda/dotup.org1602882.zip
こういうプロジェクトを作ったんですよ。
一応、ゲームっぽいものですが本質はそこじゃなくて。
えーっと、前方参照の解決がよくわからないので直し方教えてください。
普段小さなコードしか扱ってないのでソース分割あまりしないのでわけがわかりません。
コンパイルが通るにはどうしたらよいでしょうか。

お願いします。

**デフォルトの名無しさん** · 2018/08/05(日) 08:56:46.93

ツッコミどころはいっぱいあるけど
とりあえずGameIssue.hの中でRougeStageの定義が見えてないからincludeしろ

◆QZaw55cn4c · 2018/08/05(日) 17:21:41.90

>>506
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html
「変数を参照しているのか逆参照しているのかがいつもわからなくなる、だから必ずポインタを使う。アスタリスクが思い出させてくれるから」

C++ の参照は、呼び出し元の記述では参照として渡しているつもりなのか、実体を渡しているのかは区別できず、
呼び出し先の宣言で、はじめて参照か実体かがわかるんですね

個人的には C# のように、呼び出し側でも参照渡しを明示するのがスマートだと思います
そのコーディング規約は良心的だと思います

**デフォルトの名無しさん** · 2018/08/05(日) 17:44:24.77

>>553
参照渡しを明示、とは具体的にどんな方法でしょう？

**デフォルトの名無しさん** · 2018/08/05(日) 17:48:52.51

ref とかoutとかじゃね？

◆QZaw55cn4c · 2018/08/05(日) 17:55:52.90

>>554
https://ideone.com/FMEesh
呼び出し側にもキーワード "ref" を記述します

**デフォルトの名無しさん** · 2018/08/05(日) 18:07:51.68

ゲーム的にはコレか？

Rog-O-Matic - Wikipedia
https://en.wikipedia.org/wiki/Rog-O-Matic

**デフォルトの名無しさん** · 2018/08/05(日) 18:26:33.87

>>556
C#ではなくC++での方法を聞きたかったのですが (^_^;)

**デフォルトの名無しさん** · 2018/08/05(日) 18:32:14.36

>>506
constなしで参照渡しするなっていうコーディング規約ならgoogleも採用してるよ

**デフォルトの名無しさん** · 2018/08/05(日) 18:34:25.86

立てました。移動はご自由に。

C++相談室 part138
https://mevius.5ch.net/test/read.cgi/tech/1533459756/

**デフォルトの名無しさん** · 2018/08/05(日) 18:35:44.95

>>558
お前はC++とかより日本語の勉強しなよ…

**デフォルトの名無しさん** · 2018/08/05(日) 18:56:17.20

単純にc++だけで閉じてれば参照で統一ってのもありだろうけれど
c++ってそういう言語じゃないんだよね。
大抵大規模なコードは過去のcソースとごっちゃになってる。

**デフォルトの名無しさん** · 2018/08/05(日) 19:04:35.58

>>551
まずは非常にどうでもいいことだが、AddBug(SharedItem I)　こういうモノがあると非常に縁起が悪い

他、小姑みたいなスペルミスの指摘は以下

Sheld盾の綴りはshield　（Fieldと同じ原理）
Acsessとaccess、
CollectoerとCollector
TyleとTile
InfmationとMakeTemporaryInfomationとinformation
Initilaize、Initialize
PraramA、parameterA

RougeStage.hとRogue

**デフォルトの名無しさん** · 2018/08/05(日) 22:24:16.29

いい加減な方法でビルドはできるようにしたのに遊べないよ！
なんとかしろ、作者

GameIssue.h 12行目付近の
class TemporaryInfmation;
をいかに書き換える。
//class TemporaryInfmation;
template <typename RougeStage> class TemporaryInfmationTmpl;
using TemporaryInfmation = TemporaryInfmationTmpl<RougeStage>;

RougeStage.hの3行目付近の
class RougeStage;
~
TemporaryInfmationTmpl(RougeStage* RS) {
をいかに書き換える。
template <typename RougeStage>
class TemporaryInfmationTmpl {
public:
TemporaryInfmationTmpl(RougeStage* RS) {

StatusCollector.hのStatusクラスの
SetDirection()が2個定義されているのでどちらかを消す。

**551** · 2018/08/05(日) 23:51:00.40

こんにちは。色々ご指摘ありがとうございます。
これまだ、脳内コーディングでシステム組んだだけでコンパイルが通って無いように、デバッグさえしてません。
なんとなーく、ローグのAI書いたら面白いんじゃないかと思って書き始めたのですが、沼にハマってしまいました。
とりあえず、前方参照の件は解決したみたいです。
その後大量のエラーと格闘していますが、支離滅裂なエラー（？）が大量に出ていて吐きそうです。

とりあえず、この件については閉めます。
ありがとうございました。

**デフォルトの名無しさん** · 2018/08/06(月) 00:29:53.59

>>553-556
/* ref */

引数内で、コメントを使えば？

**デフォルトの名無しさん** · 2018/08/06(月) 04:28:30.45

>>559
templateの右辺値参照もダメとか
さすがに修正が必要だな

**デフォルトの名無しさん** · 2018/08/06(月) 11:34:49.72

>>567
別の項にmoveコンストラクタ、move代入演算子、perfect forwardingするときは右辺値参照使ってええよって書いてあるから、右辺値参照は対象外なんだと思う。

>>565
できたら遊ばせてねー

**デフォルトの名無しさん** · 2018/08/06(月) 12:01:58.56

aiでautoってことは遊ぶんじゃなくて遊ばれちゃうのか…

**デフォルトの名無しさん** · 2018/08/06(月) 13:00:05.48

Googleコーディング規約は古臭くてオワコンだからみんなはISOで作ってる規約を使おうね！
って禿先生が講演で言ってた

**551** · 2018/08/06(月) 18:02:56.58

>>596
ステージ生成してAIに解いてもらおうと。
そのAI書かないといけないんですけどね。

**デフォルトの名無しさん** · 2018/08/06(月) 18:04:44.92

しかし、ロジカルなことしたいのに、それ以外のエラーで死にかけるのは困ったなぁ。。。

**デフォルトの名無しさん** · 2018/08/06(月) 18:26:13.93

>>572
アルゴリズムの間違いの発見や修正に比べたら、コンパイルエラーの解消なんてコンパイラさんが親切に教えてくれてるんだから、簡単なことだよ。
ロジカルなことしたいなら、コードの記述もロジカルに頑張れ

**デフォルトの名無しさん** · 2018/08/06(月) 19:18:24.62

はい。がんばります。

**デフォルトの名無しさん** · 2018/08/06(月) 19:34:04.04

>>570
今現在コード書いてないオワコン禿げのいう事のが信用ねーわ。
江添とかも同類。
コードをまともに書いてないやつが言語仕様決めてるってのがc++のクソなところ。

**デフォルトの名無しさん** · 2018/08/06(月) 19:45:02.37

>>575
コードがマトモに書ける人は書く方が忙しいので仕様どころではないって割とありそう

◆QZaw55cn4c · 2018/08/06(月) 22:20:17.51

ryzen threadripper 2950X 16C32T 3.5GHz～4.4GHz !!
なんだか最近急にすごくなっていませんか？

**デフォルトの名無しさん** · 2018/08/06(月) 23:09:33.16

今までのAMDが怠けてただけだよ！

**デフォルトの名無しさん** · 2018/08/06(月) 23:12:22.15

floatのゼロ割りって、infになるものの、別にそれ自体が問題ではなくて、
それがクラッシュに繋がるような演算を行うことが問題であって、
例えば条件分岐で一定の大きさ以下の場合のみ参照するようにしているなら問題ないですよね？

**デフォルトの名無しさん** · 2018/08/06(月) 23:30:48.85

ゼロで割り算したい意図は？

**デフォルトの名無しさん** · 2018/08/06(月) 23:38:20.39

>>579
うん
>>580
ゼロで割りたいなんて一言も書いてない