[過去ﾛｸﾞ] ToHeart2 ほか AquaPlus/LeafのGPLゲーをいじるスレ (833ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
347(3): 2006/01/20(金)04:15 ID:bWwH4+cX(6/11) AAS
これ、スレ違いすぎるから無視してくれてもいいけどさ。
new malloc派の人はBITMAPINFOの割り当てとかもnewでやるの？
p=(BITMAPINFO*)malloc(sizeof(BITMAPINFOHEADER)+(sizeof(RGBQUAD)*256));
こういう感じのものを書くとき、newで書くとあんまり直感的にならんような。
348: 2006/01/20(金)04:16 ID:bWwH4+cX(7/11) AAS
new malloc派→new delete派の間違いでした、ごめん。
349: 2006/01/20(金)04:24 ID:/uViAoEM(1) AAS
>>347
慣れの問題じゃないの？
特に直感とか言ってるし。
350(2): 2006/01/20(金)05:13 ID:evtcDsiT(3/4) AAS
>342
delete[]をdeleteとしても、デストラクタがなければ「大抵」正常に動作してしまう。
>346
STLのvector程度が使いこなせてないのは、難しいんじゃなくてただ不勉強なだけ。
STLの相性問題って、それはSTLの実装に依存した使い方が悪いと思うんだが。
>347
C++としてはBITMAPINFOのアクロバティックな構造は悪。
どうしてもと言うなら、そんなWindows臭いモノは、直接Win32APIでメモリ確保。
351(1): 2006/01/20(金)09:02 ID:H/DTUIYi(1) AAS
>>350の書いたソースコードが見たいぜ
352(1): 2006/01/20(金)09:34 ID:JrDuq+7M(1/4) AAS
>>346
向上心の無いおじさんの言い訳に聞こえるな。
「無駄に難しい」だの「単純」だのは主観でしかない。
逆に、「C的には正しい」がマクロ、関数ポインタを駆使したソースなんかは、
C++ を学んだプログラマから見れば無駄に難しく見えるだろう。
決して「単純」だなんて思われることはない。
>>347
そんなメモリ確保は new ではうまくいかないんだから malloc() 使えばいい。
new で問題ないケースで malloc() を使うのはデメリットが多い。
もちろん動的確保が必要なければ new も malloc() も使わなくていい。
省2
353: 2006/01/20(金)09:39 ID:Z8o3taxA(2/4) AAS
>>346とだけは一緒に働きたくないと思った俺ガイル
354(1): 2006/01/20(金)09:42 ID:Z8o3taxA(3/4) AAS
だいたい「ネスケですら(ry」って、一体何年前のコードに依拠してるんだか。
Firefoxのソースでも読んでみれば？
355(2): 2006/01/20(金)09:55 ID:bWwH4+cX(8/11) AAS
>350
vectorだけしか使わなくて、パフォーマンスに影響するほどデータ数が
多くないなら、自力で似た処理組んだほうが楽。
mapやmultimapに大量のデータ食わせるような場合には使いでがあるけど。
コンパイラの側が変な実装なせいでSTLがちゃんと読めないケースがある。
何かあったらSTLのソースを覗く羽目になるのも嫌だな。
GlobalAllocで確保したところでmallocと大して違うと思えんが。
mallocを消したという自己満足感が得られるだけのような。
ゲームなんて、そのWindows臭いコードが大量に出てくる分野なんだが。
>352
省6
356(2): 2006/01/20(金)10:01 ID:bWwH4+cX(9/11) AAS
>354
外に出すつもりで書いてたソースコードとそうでないコードの違いだろ。
357(1): 2006/01/20(金)10:16 ID:38QVjqGM(1) AAS
>>356
矛盾してるよ。外に出すならなおさら
>プラットホームによってはC++の対応が不完全なことも多い
なんてのはまずいでしょ。
だからMozilla Foundationは「C++ 移植性ガイド」を公開して
処理系に依存しそうな部分を禁止した上でC++を使ってるんじゃないか。
C++を使って、その上依存性のない最大公約数的なコードを書くことは可能。
358: 2006/01/20(金)10:18 ID:bWwH4+cX(10/11) AAS
あと、関数ポインタは結局DLL使うときに必要だしな。
C++的に悪だからって、APIの仕様を変更することは出来んのだから。
関数ポインタ利用部分をラップするようなinline関数書くなり
クラスを作るなりすれば済む話。
俺だってクラスは作るしコンストラクタ／デストラクタの恩恵には
預かるわけだが、継承とかは出来るだけやらないようにしてるな。
359(1): 2006/01/20(金)10:20 ID:bWwH4+cX(11/11) AAS
>357
>356はネスケのソースとFireFoxのソースの話ね。
ネスケの段階で既に一流の仕事なんだから、プログラマの腕が上がったと
いうよりは、単に心構えの問題にすぎんだろうと。
外に出すとケチをつける人が増えるから綺麗に書こうとすることになる。
Windowsのゲームプログラミングに移植性もクソもないし。
360(1): 2006/01/20(金)10:37 ID:JrDuq+7M(2/4) AAS
>>355
なんで既にできあがってるものがあるのに、自力で組んだほうが楽になるのかね？
実装がマズイ可能性も、ソース覗く羽目になるのもいっしょだろ。
むしろ実装がマズイ可能性は自力で書いたもののほうが高いし、
仕様だってあやふやなものになって、ソース覗く羽目になりやすいだろ？
自分で書いたものならそれでも問題になりにくいだろうけど、、、、
あ、もしかして一人でしか開発したこと無いのか？
それなら辻褄が合うな。
361(1): 2006/01/20(金)10:40 ID:JrDuq+7M(3/4) AAS
>>346
> プラットホームによってはC++の対応が不完全なことも多いし、
> STLで相性問題が起こることも多いしな。Cが一番確実。
>>359
> Windowsのゲームプログラミングに移植性もクソもないし。
なにこのダブルスタンダード。
362: 2006/01/20(金)10:55 ID:lg5noXKj(1) AAS
std::vectorごときでさえテンプレートメタプログラミングの初歩の
話になってくれば使った方が良いに決まってんだけどねえ
363(2): 2006/01/20(金)10:59 ID:Vm6Xgl5v(1/3) AAS
>360
自分で書いたソースを覗くのとSTLのソースを覗くのじゃ大違いだが。
スマートポインタの問題とかに深入りしだしたらキリないし。
楽になろうと思って返って疲れないか？
STLの利点は、楽さではなく、一応の標準性とパフォーマンスだと思うが。
俺のやってる規模の仕事なら一人で出来る。
言っておくがプロのゲームプログラマだぞ。
確かに自前のライブラリを他人に使わせようとは思わんがな。
そういうときは仕方ないからSTL使う。
>361
省3
364: 2006/01/20(金)11:17 ID:JrDuq+7M(4/4) AAS
>>363
やっぱり一人で開発してるのが前提だったのか。そりゃ話がかみ合わないな。
忠告したいことは山ほどあるが、これ以上続けても無駄そうだし、
スレ違いだし、もう消えることにするよ。
365: 2006/01/20(金)12:09 ID:OTKBdpZ5(3/4) AAS
そんなすごいよかよとFireFoxのソースみたが、言われてるほどじゃないなぁ
366(1): 2006/01/20(金)12:26 ID:i9y7MqMq(1) AAS
>>363
多分アンタは共同開発し出すと泣くことになると思うんよ。
上下前次1-新書関写板覧索設栞歴
あと 467 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.017s