【初心者歓迎】C/C++室 Ver.105【環境依存OK】
■ このスレッドは過去ログ倉庫に格納されています
エスケープシーケンスやWin32APIなどの環境依存なものもOK
そのような質問は必ず環境を書きましょう
半角空白やタブでのインデントはスレに貼ると無くなります
コードを貼れる所
http://codepad.org/
https://ideone.com/
前スレ
【初心者歓迎】C/C++室 Ver.104【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1545944692/ >>792
お前は俺の言うことがわからないということがわかった。 htmlも昔の方が良かったって人なんだろうね
cssとか理解できないんだろう 使い物になるだけD3Dの方がまし
OpenGLは初期のAPIデザインひきずって最後までマルチスレッド対応できなかった
拡張性が高いとか言われてるけど
ベンダ依存多くて互換性なんかほとんど期待できない
初心者が一ヶ月学んで卒業するための
教育用の価値しかない
こんなのにしがみついてどうする >>792
glBegin/glEndがdeprecatedになって、VBOを使うようになってわかりにくい、という主張はわかるけど、
2.0だと初期設定だけで200行必要というのと1.0は初期化の後はglBegin/glEndでポリゴンが書けるというのは、
対応してないところを比較している気がしてしまう。
それに、GLFWなんかを使わずに素のOpenGL APIを使って初期化するなんてこと今どきある?
2.0になってややこしくなったのは、世界が複雑になったのだから仕方のないことだと思うんだけど。
OpenGLの一番良くないところは、ハンドラが引数になくて、操作されるコンテキストがどれかということが
見えない状態になってしまっていることじゃない? シェーダーとかなしで
グラフを書くだけの用途だから OpenGL1.0でごりおしだな
※ glBegin の対の glEnd を忘れて頂点バッファ漏らすのを ラッパークラスで回避する程度 GLFWなんて使うのは試作や使い捨てツールとかくらいだと思ってた。 つーか昔はフレームバッファに書きこんだところにドットが表示されてすっきりしてわかりやすかった
今は全部GPUにふくざつなめいれいを送らないとドットひとつ打つのも大変だから昔のほうが良い
みたいな議論 できることが増えただけで今でも昔のやり方をしたいなら(それで事足りるなら)、昔ながらのやり方をすればいいだけだと思う imx6でframebuffer上にcv::Mat作って直接弄ったら表示されたときはなんかすごく懐かしかったよ >>801
>OpenGLの一番良くないところは、ハンドラが引数になくて、操作されるコンテキストがどれかということが
>見えない状態になってしまっていることじゃない?
ほんそれ
python の matplotlib にも同じ違和感を感じる(重箱) >>804
オレオレルール上は glut までですね判ります >>808
さすがにそういう30年ぐらい前のAPIデザインはいけてないってことで
direct state accessが導入されたんだけど、中途半端でぐだぐだ 教えてください。
三項演算子
auto a=1;//なんでもいい
a?return 0:return -1;
なんでコンパイルエラー? >>811
return は文であって式ではない。 あっ被った
なので解決策書いとく
return a ? 0 : -1; ありがとうございました。
式と文がまだわかっていませんでした。
>>814
なーるです。 windows環境でC++のスタティックライブラリを作りたいんだけど、公開するシンボルを選択することって出来ます? 無名の namespace でくるめば内部リンケージにはなるけど なるほど 確かに消えるけどextern "C"付けると残りますね 公開する気が無いものまでexternしたらだめだぞ VC++からXboxゲームバーを起動するサンプルどこかにありませんか? pow関数が遅いというのは今もそうで今後も変わらなさそうで
できるだけ使うべきではないですかね? >>823
何も前提条件を定めず「遅い」とか「使うべきか」とか議論しても無意味だよ。
例えば他の関数と比べて100倍遅い関数があったとして、それを使ったプログラムの実行が1msで終わるものなら、通常は別に問題ないだろう。
その遅い関数がどのくらいの回数呼ばれるのか(数回、数万回、数億回)、許容される時間はどれだけなのかによって異なってくる。
とりあえず使っとけ、問題が起こりうるケースならそのとき考える。
そもそもpow関数が必要ならそれを使うしかないんでないの? それに変わる同等な処理を自前で実装できるとは思えないから、powの頻度を減らした別のアルゴリズムを考えるか、同じ計算が繰り返し行われるなら覚えておくかするしかないと思う。 元の式で数学的に最適化してしまえるケースは多い
何も考えずにコーディングだけしてると無駄な計算量が増える ホワイトボードで式の変形を何種類かやってテストくらいはしないとな 整数回のべき乗なら最適化も可能だしこだわるならやってみればええ
でも数値演算ライブラリはFPU使って並列処理させてるだろ
わざわざCPU資源使って計算させるほどでもない
無駄なことして他の処理が遅くなることもあり得るからの >>823
pow(a,b)
aが同じ値でbのみ変わる事が多いなら
log(a) をとっておいて exp(log(a)*b) とする
取りうる値がわかっていて多くないなら
log(a)をテーブルにしておく
bが整数なら乗算や除算を組み合わせる
bが整数+0.5ならsqrtを組み合わせる
大量にpowを計算する必要があるなら
SIMDやGPUを使う
なと色々と工夫の余地はある 色々ありがとうございます
遅いので工夫しろというのが常識らしいですね いや、必要なら工夫しろ、必要なければ余計なことはするな、だろう。 速い遅いは実際に書いてるコードの中での相対的なものによるから自分のコードで観測しろ ってことだ すみません
他スレでJavaでdirectXやるにはCをやれといわれてココに来ました
CでdirectX出来るそうなので始めたいんですが
何をインストールすれば良いのですか?
Windows10Pro64bitですよろしくお願いします ウソってことはないはずだけど、よう分からん。
DirectX のスレッドなら確実じゃないかな。
【C++】 DirectX初心者質問スレ Part41 【C】
https://mevius.5ch.net/test/read.cgi/tech/1521786252/
ってのが見つかった。たらい回しにするみたいで気が引けるが。
なお、そちらのスレッドは見てないので紹介が適切かも分からない。 >>835
すみません
マルチプラットフォームで3Dやる言語には
JavaでCを呼び出してdirectXをいじるのではなく
UnityでJavaScript言語という結論にいたりました。
ありがとうございました。 jsはもうサポート終了宣言してるからc#にしとこうな よくわからないですけど
Unityの内部で使う動作スクリプトがC♯記述一択で
ゲームパッド入力はDirectXのC++で
AndroidスマホのタッチイベントはJavaだし
書き出すときはWebGLだからJavaScriptに変換されるという事かな〜意味不明だ >>828
exp って pow よりどの程度速いの? powは内部的にはexp(log(a)*b)
当然環境次第だけど
おおよそ半分くらいかな
もちろんlog(a)のテーブル検索に時間がかかるようだと
素直にpowを使う
>>828は
powがパフォーマンスに影響を与えているという前提のチューニングの話で
ほとんどの場合はそんな事はないので
ほとんどの場合はそのままpowを使うべき y = a * pow(x, 3.0) + b * pow(x, 2.0) + c * x + d;
って糞コードを見たことがある 速度、精度、見やすさ、コードサイズ、ライブラリ使用
全ての面で糞コード
pow(x,y)が電源ボタンxをy回押す
という別の関数だということは無いとして こうか?
y = ((a * x + b) * x + c) * x + d; 元の数学的な式を素直にコードに落とし込んだ感じはあるけどな。
「xの3乗」を「pow(x, 3.0)」と「x * x * x」との
どちらで書くのを自然に感じるかという話だが。 クリティカルでないものならどう表記しようが別にどうでもいいがな
1億回計算したところで時間差は感じないだろうよ
んなことよりべき乗扱う上で大事なのは桁あふれと有効桁数の処理
必要精度のはっきり定義された科学計算用のライブラリ使ったほうがマシ 精度的には加減乗算の方がはっきりしてる
普通は無限精度で求めた後に丸めたのと同じ値になる
つまり誤差最小 >>849
たとえばJIS規格に則った計算方法てのもある
測定値を足し合わせるだけでも±有効桁/2を混ぜ込まなきゃならなかったり計算ごとに有効桁に丸めこまなきゃならなかったり
乗算の場合は有効桁を減らしたりとかまあいろいろ
無限精度で計算して最後に丸め込んだら×もらう仕組みになってたりする 精度的にpowを使うことで解決することなど無いと思うが >>841
y = ((a * x + b) * x + c) * x + d; いわゆるスパコンなんかだと式の変形してがんばらずとも pow そのままで速かったりするのかな? c++使う理由ってなんですか?
2dゲームにおいてもc++が必要でしょうか? ゲームと言うよりゲームエンジンでした
すみません
テクスチャの描写にすらC++は必要なのかなと
ポリゴンならもちろnC++一択でしょうけど 必要=必ず要る
という意味なら答えは分かってそうな気がするが
別の意味ならもっと日本語をうまく使った方が良い 基幹部分の話ならC++使わずにCで書くって方向性もあるかも。 可能かどうかで言えばテクスチャの描写はすべての言語でできると思います
ただRPGメーカーやウルフエディタはC++です
ここに理由はあるのかなと疑問に感じました
2dでもopenglなどを使うのですか? 奥の方では2dでも使ってるよ
今どきのコンピュータならインタプリタでも速度は足りるけどc++を使うのはまあそれが一般的で資産があるからだと思うよ GUIのOS画面「🐴🦌🦋」
CUIのOS画面「AAA」 ライフゲーム「•|•/•-•\•|•/•-•\」
7行テトリス
7行オセロ
10行ぷよぷよ
はじめてのゲームプログラム「荷物君」 >>864
RPGメーカーもウルフエディタもさわったこと無いけど、RPGツクールみたいなものでしゅ。つまりただの2Dゲームではなく、ユーザが作成した(場合によっては膨大な大きさの)データを編集するツールと、そのデータを読み込んで処理しながら2D RPGとして動かすプレイヤ(仮想ゲーム機)のセットみたいなもの。
ただの2Dの描画ならマシン性能は大して求められないけど、膨大なデータを効率的に保持して動的な変更に耐えうるような仕組みを作るなら、処理速度が速くメモリ効率も良いC++を使うメリットはあると思う。特にスイッチや変数、イベントなどをユーザが定義して処理するなら、処理速度が遅いとかなり厳しいと思う。
で、結論を言えば、マップエディタが作りたいだけならわざわざ学習コストの高いC++に手を出して挫折する可能性を高める必要はない。他の使いやすい言語やフレームワークを使っとけ。 >>869
>>859> 2dゲームにおいてもc++が必要でしょうか?
C++をディスってるのが分からな🐗? >>872
おお、またやってしまった。
以前会社の上司にも似たような誤字を送ったことがある。いまだにスマホのフリック入力は慣れない... Unityスレにもいた人だけどなんでこんな少ない情報で最適な言語を求めるんだろうか?
別にC++でもC#でもjsでも実現可能だし、大差ないと思うけど
COBOLとかならやめとけって言えるけど 答えというか、一般論を知りたいです
例えばエレクトロンでピクセルの操作は出来ますか? 一般論なら、Unity
他には、Electron, React Native
サーバー側が、Ruby なら、Rails もある。
ただし、GUI は、HTML, CSS/SASS, JavaScript になる ゲームではなく、タイルエディタでもunityという選択なんですか? 一般論なら使い慣れた言語でいいんじゃね?程度だと思うよ
実現したい機能の実装が不可能で無い限り関係ない
利用者の多い言語のほうがフレームワークやライブラリの面で開発は楽になるかもしれない
electronは言語ではなくフレームワークだけどなんで言語と比較してるの?
electronの質問は該当スレへ
今の質問もスレからずれてると思うけど すみません。
既存のエディタがなぜc++なのか知りたかったのです。 いや、unityスレでも言われてたけど作った人に聞け以外に答えは無いよ
ウルフエディタを触ったことは無いがやってることはC++でもC#でもjavaでもできるはず
他言語は俺じゃわからんが画像を任意座標へ表示するようなことができる仕組みさえあれば大抵のことはできるだろう 初学者なら兎も角、熟練者が少人数で使う分には言語による開発効率の差なんて大差ない
手足となるライブラリが一通り揃って使い方知っていれば、c++だろうがサクッと作れる ごめんなさい
じゃあpyqtでやります
比較的pythonに慣れているので そもそも、Tiled Map Editor を使うから、作るのは無駄だと思うが >>882
>任意座標へ表示
ここでポインターが便利ってことになるんだよな
線引いたり塗りつぶしたりといったプリミティブなことを自分でやるならポインター使えなきゃやってられない
ここまでくるとアセンブラの威力まざまざと見せつけられるわけだけども次点でC/C++ 競技プログラミング始めたいんだけど、どうやってcpp勉強すれば良い?
Cはある程度わかるからcpp特有の文法を勉強したい
変数みたいなのに>>みたいなのいっぱいついてて何がなんだかわからん とりあえず解いて他人の回答をみる
知らない内容があればググる
これの繰り返し >>887
普通に本屋で入門書買ってきてやればいいだろう。
それとC++をcppと呼ぶのはやめれ。 >>887
細部を観る前にまずオブジェクト指向を理解するべき 競技プログラムでまずオブジェクト指向?
順番が違う気がする あくまで競技プログラミングありきで C++ を導入したいってことならオブジェクト指向の考え方はそれほどいらんわな。
ただ、競技プログラミングで書かれてる C++ のコードってかなり汚いのばかりなので、
そこに特化しちゃうのはあまりオススメしないよ。
頻繁というほどではないが using int = long long; くらいのクソはちょいちょい見かける。
まともな書き方をわかった上で割り切り方を考えるとか、言語のトリッキーな部分に踏み込んでみるとか、
逆に言語はどうでもよくてアルゴリズムだけが大事とか考えてるなら競技プログラミングでスタートするのもありかもしれんが、
ちょっと C に毛の生えたくらいの C++ で競技プログラミングを始めると変なクセが付いちゃう。 おっと using int = long long; は出来ないな。
#define int long long の間違い。 競技プログラムに特化
いいじゃない
何からはじめても
どうせ将来業務や集団でコーディングすることになったら
文法以外に色々と勉強しなきゃならん ■ このスレッドは過去ログ倉庫に格納されています