ToHeart2 ほか AquaPlus/LeafのGPLゲーをいじるスレ

**名前は開発中のものです。** · 2005/12/13(火) 01:33:48

弊社製品のムービー再生にxvid.orgのムービー展開ライブラリを使用していた件について。

弊社製品、
『アルルゥとあそぼ!!（ランチャとRoutesミニシナリオのみ）』
『Tears To Tiara』
『鎖－クサリ－』
『ToHeart2 XRATED』
の４商品では、動画再生に http://www.xvid.org/ において公開されいるXViD再生エンジンを使用しております。

この動画再生エンジンのプログラムはGPL(GNU General Public License)に基づくソフトウェアとして公開されていますが、これを使用した場合、GPLに定められている通り、オファーがあればソースコードを公開する義務があります。

このGPLのソース公開義務に従い、弊社の上記４作品のソースコードを全て公開する事に致しました。現在ソースコード公開に向けて社内のソースコードのまとめを行っておりますが、２年ほど前のタイトルも含まれておりますので、多少時間がかかります事をご容赦下さい。

今後、XViDの開発元に弊社より謝罪を含め連絡をとり、GPLの基準に合致しているかを確認を行った上で、全ソースコードの公開を致しますので公開まで少々お待ち頂けるようお願い致します。

http://leaf.aquaplus.co.jp/xvid.html

**名前は開発中のものです。** · 2006/01/22(日) 19:11:57

>>482
俺がその書き込みをしたわけでは無いから、同じことを言ってるのかどうかわからんが
露骨にカード指定してある部分があるので、レスしてみる。
TtT起動時に
「RADEON 8500～9200を使っている（画面が崩れる場合のみ）」というチェックボックスがある。
そのチェック項目で

if(Avg._Radeon8500){
x = (int)(MapControl.px-ShakeDx);
y = (int)(MapControl.py-ShakeDy);
}else{
x = MapControl.px-ShakeDx;
y = MapControl.py-ShakeDy;
}

こんな構文がある。MAPのx,y座標を浮動小数点から整数に変えてあるな。
具体的にはわからんが
整数にしないと「画面が崩れる」＝「テクスチャ化け」ってことかな？

**名前は開発中のものです。** · 2006/01/22(日) 19:16:04

>484
8500持ってないしコードも読んでないが、x,yはfloatなんか？

だとすれば、テクセルとピクセルの対応が0.5ずれてるのを修正している
んじゃないのか、と妄言してみる。

**名前は開発中のものです。** · 2006/01/22(日) 19:45:14

乗り遅れた～
>190 が消えているので再アプお願いします。

**名前は開発中のものです。** · 2006/01/22(日) 20:05:48

↑
なにこいつ？

**名前は開発中のものです。** · 2006/01/22(日) 20:21:15

こーいうものこそWinnyでおとせばいいんでねーの？

**466** · 2006/01/22(日) 20:26:44

ソース無いので助かるっす

>>484-485
レスありがとうございます。ってことは8500～9200時のみ、
テクスチャを0.5ずらす必要がない(事がある)って事なんですかねぇ。

ちなみにうちの8500だと、0.5ずらして初めて、テクスチャが綺麗に表示されます(TL済みの場合)。

**名前は開発中のものです。** · 2006/01/22(日) 20:59:45

>489
それは大抵のグラボでそういう動作をする。
texelの中心とpixelの中心は0.5ズレてるのが普通。

つーことは、違うっぽいね。何のためなんだろう？

**名前は開発中のものです。** · 2006/01/22(日) 21:03:57

いや、テクセルの中央ずらしは他のオプションで制御されてる。
良くわからんな。

てか、確か8500－9200って全て同じコアでしょ。
しかも、8500が出た当時、海外のベンチマークやゲームでも、よくテクスチャ化け起こしてた。
9000でリニューアルされて以降、そういうのは聞かなくなったけど、そのへんかも。

**名前は開発中のものです。** · 2006/01/22(日) 21:43:21

ソース読んだけど・・・フツーにウンコだなｗ
つーか、こいつメモリ管理（インスタンスの管理つったほうがわかりいい？）できてねぇよ。
あ、newとかdeleteの管理ができてないってことね。
どのタイミングでなんのデータを生成して、どのタイミングでなんのデータを削除するかってのがまるで見えてない。
これじゃバグ減らないだろうな・・・。
まあ、所詮はエロゲPGってとこで終了。データ削除。
洋ナシ、脳ナシ、魅力ナシ、領域の無駄ｗ
HDDから飛んでケー！ｗ

**名前は開発中のものです。** · 2006/01/22(日) 21:53:31

自慢厨ばっかで実際にプログラムできそうなヤツは居ないようだな
葉っぱ板のがまだ有効に使ってる

**459** · 2006/01/22(日) 22:34:29

>>469
>メモリリークの話なんかすんなよ。レベル低すぎ。
>そんなもんはつぶしてあるのが前提の話だろうが。
どうやって、その潰されているってのを保証するんだ？

>つーかさすがに俺もデストラクタは使うから、スコープを外れれば
>自動解放されるし、メモリリークはほとんど起こさんけどな。
インナーで使っているものはそれでいいかもしれないが、
外部からポインタをセットして貰って、その領域がいつの間にか解放されていたり、
内部のポインタをどこかに渡してそのままデストラクタが呼ばれた場合は？

>スマートポインタの使い方回りで変なバグ作りこむ方がやっかいだ。
それって質の悪いスマートポインタ使ってるんじゃね？
newだろうがmallocだろう自前のアロケータだろうがちゃんと解放出来て、
アップ・ダウンキャストが出来るスマートポインタじゃないとまともに使えないと思う。

>解放タイミングが見えにくいのも怖いし。
どこから参照されているか、ってのを常に考えながらプログラムを書く方が恐い。
人間だから、いつ忘れるかわかったもんじゃないからな。

>>470
>ソースからどうやってそんなこと読み取んだｗ　超能力者かｗ
Leafはシステム周りがあまり充実してるとは思わなかったからね。

>構造をウンウンうなって考えてるばかりでコード書かない奴
それは凄腕のプログラマとは言わない……。

**459** · 2006/01/22(日) 22:35:59

>>475
>そんな想像でしか分からない事考える方が無駄だと思うが。
確かにそうかも...。

>>476
>そのとおり、時間の無駄。働かないマニアを飼っとく余裕はない。
俺もそう思う。

>ベタコードで書いたって読める範囲のものを作るときはベタに書け。
だからってベタに書く必要は無い。
速く設計出来てバグのないプログラムを速く組めて、保守性が良ければいい。
とりあえず全部は無理にしても、それを目指すべきだろう。

>>478
こういった全部publicになってるようなソースはどこから何をされているか分かりづらいから、
安全性が保証されていることを立証するのが難しいんだよ。
だから「まだまだあるだろう」って書いた。

>>481
>普通は速くて安ければソース気にする上司や顧客は少ないけどな
上の人は保守性も気にして欲しいな...。

**名前は開発中のものです。** · 2006/01/22(日) 22:38:02

上記のRADEON8500対応みたいな部分こそ、枯れてるプログラムの美点だな。
あたまでっかちが幾ら「綺麗な設計」しても、環境が無ければ対応できない。

「ハードウェア/ドライバ側が対応すべきだ！」と寝言を言って
RADEONユーザを逃すか、AP側で対応して売るか。

**名前は開発中のものです。** · 2006/01/22(日) 22:40:42

>あ、newとかdeleteの管理ができてないってことね。

newもdeleteも使って無いようだけど…？

つーか、何人かは「C++使ってないからウンコ」と主張してるようだけど
そんなんで批判してるのはアホだよ？

Javaしか知らないJava厨に言わせれば「Java使ってないからウンコ」だろうね。
Lispしか知らないLisp厨に言わせれば「Lisp使ってないからウンコ」だ。

その次元と同じことに早く気づけよ。

**459** · 2006/01/22(日) 22:45:24

>>496
枯れてるプログラムというか、過去の蓄積では……。
そして本当の「綺麗な設計」は、その辺も丁寧に wrap 出来る設計だと思う。

**名前は開発中のものです。** · 2006/01/22(日) 22:48:03

さっきから「スマートポインタ使わないなんてバカじゃね？」

というような主張をしてるキミへ

スマートポインタ？なんでGC使わないの？バカじゃね？

**名前は開発中のものです。** · 2006/01/22(日) 22:52:04

GC使えばメモリリークがなくなると思ってる奴は素人

**名前は開発中のものです。** · 2006/01/22(日) 22:52:37

設計段階から、どんなワークアラウンドが必要かなんて
わからんよ。

**名前は開発中のものです。** · 2006/01/22(日) 22:57:35

スマートポインタでメモリリークが無くなると思ってる奴よりは玄人

**459** · 2006/01/22(日) 22:58:12

>>499
俺か？

GC のことを失念してた。
でも、GC は便利だけど、開発の規模が大きくなるから、
そんなの言語レベルで実装してくれないと厳しい気がする。

C++ で GC とか作れるレベルのプログラマにスマートポインタを必ず使えとは言えないけど、
malloc とかで領域を確保するぐらいならスマートポインタを使って欲しいね。

**名前は開発中のものです。** · 2006/01/22(日) 23:00:42

>>502
GC を自前で作れるﾔｼは玄人。
まじすげぇと思う。

**名前は開発中のものです。** · 2006/01/22(日) 23:01:30

つーか、マジ葉鍵板のほうがまともだな。
普通のプロジェクトに参加したことがあるならこれくらい普通だろ？
１００人クラスは参加したこと無いので分からんが。

もし自分が飛び込みで参加するとしたら吉里吉里とかよりよっぽど
今回のこのソースのほうが入りやすいと思うんだが。
それとも大手では本当に理想論的なプログラムを組んでるの？
最大でプログラマ１０人で、大作プロジェクトにはかかわったこと
無いので最大手などはどうやってるかわかんないですが。

あと、最後まで組み上げた事なさそうな理想論言う人多すぎ。

**名前は開発中のものです。** · 2006/01/22(日) 23:04:17

>504
GCは68k版のPalmOSにも載ってたな、そういえば。

**名前は開発中のものです。** · 2006/01/22(日) 23:19:54

あのう、鍵板の方のどのへんがマトモなんでしょうか。

**名前は開発中のものです。** · 2006/01/22(日) 23:26:02

現場も吉里吉里も知らない普通の趣味プログラマーだが、
ソース見た瞬間に糞っぽい雰囲気が漂ってきたぞ。

**名前は開発中のものです。** · 2006/01/22(日) 23:34:15

ＧＣでメモリリークがなくなると思ってるんですけど。。
なくならないんです？

あと、少しくらいメモリリークしてもいいジャンとか思ったり。。。

**名前は開発中のものです。** · 2006/01/22(日) 23:45:43

なにより目的が違うじゃん。
吉里吉里ってのはどんなゲームになるのかわからんから
汎用性やメンテ考慮するだろうけど、
これについては、ToHeart2っていう企画のゲームが
納期までに動けばいいんだから。

**名前は開発中のものです。** · 2006/01/22(日) 23:45:46

ガベージコレクション
http://www.kmonos.net/alang/d/garbage.html

**名前は開発中のものです。** · 2006/01/22(日) 23:47:52

最近はメモリなんて山ほどあるんだから、エロゲくらい静的配列でいいじゃん

**名前は開発中のものです。** · 2006/01/22(日) 23:48:28

>>511
やっぱりメモリリークがなくなるように見えるんですが
俺ってバカ？

**名前は開発中のものです。** · 2006/01/22(日) 23:50:53

>>510
ゲームプログラムの場合1作品じゃペイしないから
汎用性、メンテしやすさを考慮して、
数作掛けて元を取るのが最近のトレンドでないの？

**名前は開発中のものです。** · 2006/01/22(日) 23:51:33

>>513
いつプールするか指定できないからリークが発生する

**名前は開発中のものです。** · 2006/01/22(日) 23:52:01

>>509
循環参照してると、いつまで経っても解放されない。
もしくは自分は解放したつもりでも、スレッドマネージャとかの管理クラスが
いつまでも参照しているってこともある。

>少しくらいメモリリークしてもいいジャン
Windows ならプロセスの終了時に OS が解放してるから、
ちょっとしたリークなら大丈夫かもね。
でも、リークするルーチンが何度も呼ばれるようであれば問題。
スワッピング起こして動作が鈍くなって最終的には落ちる。

**名前は開発中のものです。** · 2006/01/22(日) 23:52:04

>>514
よくしらんけど、Leafのゲームって
バカ売れしてるイメージがあるんだけど違うんでしょうか

**名前は開発中のものです。** · 2006/01/22(日) 23:58:37

ガベコレだと有名なのはBoehm辺りかな。
だれか趣味じゃなくてプロジェクトで使った事ある人居る？

**名前は開発中のものです。** · 2006/01/22(日) 23:59:31

>>515
そのうちプールされるんじゃないんです？

**名前は開発中のものです。** · 2006/01/23(月) 00:02:38

>速く設計出来てバグのないプログラムを速く組めて、保守性が良ければいい。
>とりあえず全部は無理にしても、それを目指すべきだろう。
とりあえず君が夢見がちなアリスちゃんって事は分かった。

**名前は開発中のものです。** · 2006/01/23(月) 00:07:30

>>520
だから「目指すべきだろう」って言ってるじゃん。
俺なんか変なこと言ってる？

**名前は開発中のものです。** · 2006/01/23(月) 00:09:55

>>521
shamin乙

**名前は開発中のものです。** · 2006/01/23(月) 00:58:12

結論：LeafユーザのPCのべ数十万台での稼動実績　＞＞＞＞＞＞＞＞＞＞　頭でっかち名無しの空論・べき論

**名前は開発中のものです。** · 2006/01/23(月) 01:42:48

俺は、>484のようなのがもっとたくさんあるならいいなあと思っていた
わけだが、なかなかそういうもんでもないようだな。
>494
>どうやって、その潰されているってのを保証するんだ？
さて、どこから突っ込んだものやら。
>495
publicだのprivateだのでバグが増えるほど複雑なソースでもないだろ。
君の理論だと、Cソースであるだけで潜在的バグを疑われることに
なるんだが？　C++以前からやってるプログラマを舐めすぎじゃないか？

mallocがリーク云々の元だとか行って毛嫌いしてる奴は、
Win32APIの取得／解放系は一切使わないのかねえ？

**名前は開発中のものです。** · 2006/01/23(月) 01:52:39

メモリリークのバグとか聞くのはたいていCのプログラム。
Javaプログラムのメモリリークなんて聞いたこともない。

**名前は開発中のものです。** · 2006/01/23(月) 01:57:28

だったらエロゲだけじゃなくてFPSやネットゲーもJavaで開発すればいいのにね

**名前は開発中のものです。** · 2006/01/23(月) 01:58:09

>525
リークしにくいのがJavaの売りのひとつなんだから当然。ないわけではないが。

C++でもリークするようなコードはいくらでもかけるぞ。
Cのリークは、どこかで解放すりゃあそれで終わるようなことだが、
下手に作りこんだスマートポインタやGC周りでリークが起きたら
デバッグしんどいぞ。

**名前は開発中のものです。** · 2006/01/23(月) 02:04:52

>Cソースであるだけで潜在的バグを疑われる
そういうことになるな。
だからこそ C++ や C# という言語が出てきたと思っているんだけれども...。

>C++以前からやってるプログラマを舐めすぎ
俺もCからやってるよ。
でも、Cは必要のない管理（機械的に出来る処理）を迫られることがよくある。
俺は、機械的に出来る処理は、出来る限り機械に任せるべきだと思っているんだが、
そう思ってる人は少ないのかな？

>Win32APIの取得／解放系は一切使わないのかねえ？
スマートポインタをセットするときに、解放するための functor を一緒に登録しておく。
そうすれば、どんなアロケータだろうときちんと解放できる。

**名前は開発中のものです。** · 2006/01/23(月) 02:08:54

別にCだってカプセル化はできるしスマートポインタだってできるでしょ。
C++ほど実装が自動化できないというだけで。

**名前は開発中のものです。** · 2006/01/23(月) 02:11:59

>>529
Cでデストラクタの自動実行を実現する方法があるなら教えてくれないか？

**名前は開発中のものです。** · 2006/01/23(月) 02:24:21

>>529
>スマートポインタ
確かに出来る。
ただ、例えばポインタ同士をイコールで結ぶたびに、参照カウンタを増やすための
関数を呼び出さなければならないっていう（無駄な）ルールが出来てしまう。
もしその関数を呼び出すのを忘れたらカウントが狂ってしまう。
smart_equal みたいな関数を作ったとしても、可読性がすごく悪くなる。
さすがに俺もそこまでして C でスマートポインタを使おうとは思わない...。

C++ であれば、operator=() を使えば解決できる。
可読性も落ちない。参照カウンタを間違えるミスもしない。

>C++ほど実装が自動化できない
俺はそこが一番の問題だと思ってる。
忘れるってのは人間だからあること。
ちょっと忘れただけで重大なバグが出たりすると、目も当てられない。
しかもそのデバッグするコストを考えると、出来る限り自動化したいと思ってる。

**名前は開発中のものです。** · 2006/01/23(月) 02:32:00

C++は学習コストが高い。
俺はかなり上達したが、思い返せば確かに複雑なルールが多すぎる。

それを思えば、使える人が多いCで開発することもしょうがないと考える。

クラスを作る時のビックスリーの約束事、ちゃんと知ってる人が何人いるか。

**名前は開発中のものです。** · 2006/01/23(月) 02:35:40

>しかもそのデバッグするコストを考えると、出来る限り自動化したいと思ってる。

はぁ。ならC++を使うのもやめたらどうだろうか。
もっと自動化できるよ。

**名前は開発中のものです。** · 2006/01/23(月) 02:48:17

>>533
うん、今は C# を勉強してる。

ところで、これは純粋な疑問なんだけど、
>もっと自動化できる
自動化しても構わない部分を自動化するのに何か問題があるの？

**名前は開発中のものです。** · 2006/01/23(月) 02:54:37

勝手にすればいいんじゃないの？お前がどうしようと自由だ。

**名前は開発中のものです。** · 2006/01/23(月) 02:57:47

>>535
了解。おやすみ。

**名前は開発中のものです。** · 2006/01/23(月) 03:36:21

単純に、２人で開発しるとします。
１人はC++を完全に使いこなせる。C的に書くことも出来る。
１人は、C専用。
この環境で、C++で組むことが望ましいか？
・・・んなわけない。

それだけの話だと思うんだが。
このコード、明らかに２人以上の手が入ってるし。

**名前は開発中のものです。** · 2006/01/23(月) 03:54:11

そしてそのうちの1人はC++を完全に使いこなせないのに
無理してC++使うアフォだな

**名前は開発中のものです。** · 2006/01/23(月) 04:08:19

お前らつまらない事で争ってないで仲良くデスマーチしてなさい

**名前は開発中のものです。** · 2006/01/23(月) 04:55:19

>537
betterCとしてC++で組みながら、徐々に学習/教育していく。

年がら年中マスターアップ前じゃ無いんだから、
余裕のある時に、言語の学習やらライブラリの整理やらをしてるのか？って話だと思う。

**名前は開発中のものです。** · 2006/01/23(月) 07:06:40

お前ら、エロゲプログラマはプログラマでもさらに底辺の存在なんだよ
これ基本

これで糞コードも、低レベルプログラマ擁護厨も説明がつくだろ？
まともに付き合ってると感染るぞ

**名前は開発中のものです。** · 2006/01/23(月) 07:40:25

>>537
C++使えない人間を採用しなきゃいいじゃん
同人じゃあるまいし…

**名前は開発中のものです。** · 2006/01/23(月) 08:41:02

>>542
お前直前のレスが読めないのか？
エロゲなんて同人と大して変わんないんだよ。

>C++使えない人間を採用しなきゃいいじゃん

普通のゲーム求人でもC++必須と要求しとる会社なんぞ少ないわアホ！
社会でろ！

**名前は開発中のものです。** · 2006/01/23(月) 08:43:05

両方使える奴を採用すればいい。

**名前は開発中のものです。** · 2006/01/23(月) 09:01:25

面接で忘れてはいけない最も重要な点はここにある
　―優良な候補者を誤ってはじいてしまう事は不良な候補者を誤採用するよりはずっとマシ―　
不良候補者の不手際を修正するために、ゆくゆく多大なる優秀な人々の時間、
ひいては会社のコストを犠牲にしなければならなくなる。
少しでも不安要素があれば不採用だ。

**名前は開発中のものです。** · 2006/01/23(月) 12:20:59

>528
>>Cソースであるだけで潜在的バグを疑われる
>そういうことになるな。
あきれ果てた。少しはまともな奴かと思ってたのに。
>でも、Cは必要のない管理（機械的に出来る処理）を迫られることがよくある。
そういうところだけC++を使えばいい。デストラクタとかね。つまりbetter C。
なんでも自動化しようとしすぎてドツボにはまるのがC++マニアの限界。
>スマートポインタをセットするときに、解放するための functor を一緒に登録しておく。
>そうすれば、どんなアロケータだろうときちんと解放できる。
いつ解放されるのかタイミングを制御しにくいけどな。
解放順でエラーが出るとめどい。だから、MFCとかは明示的に解放できるように
Create Destroyメソッドが付いてんだよ。実質malloc freeと変わらん。
>532
>それを思えば、使える人が多いCで開発することもしょうがないと考える。
そゆこったな。俺だってその気になればC++使えるけど、デバッグ時に
いちいち参考書読んで調べながら、なんてやってられんだろう。
硬くて単純なCライクなソースを好むのはそういうことだ。

**名前は開発中のものです。** · 2006/01/23(月) 12:26:24

「潜在的バグ」の作りやすさという点ではＣが劣るかもしれないが、
悪質さという意味ではＣ＋＋のほうが劣る。継承元やテンプレートの
細かい実装部分に由来する不具合を追うのは大変だ。ソース上に現れない
関数呼び出しが多いからな。
Ｃ＋＋は元々ある程度大きなプログラムを集団作業で作るために開発された
言語だ。大して大きくもないシステムを一人で保守するために、あんまり
大げさな設計をする必要はない。ベタでいい。

**名前は開発中のものです。** · 2006/01/23(月) 12:30:42

つーか、今読み直してみたけど、XvidもＣソースだぞｗ
これも潜在的なバグが疑われるのか？

**名前は開発中のものです。** · 2006/01/23(月) 13:27:57

C++叩くやつって大きく分けて２種類いるよな。
C++理解できないやつと、C++使いすぎて問題点が目に付くようになったやつと。

前の会社で前者の上司がいて大変だったぜ。

**名前は開発中のものです。** · 2006/01/23(月) 13:59:39

趣味でならSTLもBoostも触ってみたことがあるし、Modern C++なんか
パズル的に大いに楽しませてもらったけどな。
仕事で使うってことは、また別だからな。

**名前は開発中のものです。** · 2006/01/23(月) 14:03:29

なんか2ちゃん初心者みたいなのがいるね。

**名前は開発中のものです。** · 2006/01/23(月) 14:06:35

2ちゃん熟達者って、なんかの自慢になるのか？

**名前は開発中のものです。** · NG

すみませんが誰かソースを再うｐしていただけませんか。

**名前は開発中のものです。** · 2006/01/23(月) 16:38:49

使う人間の能力が追いつかなくてバグの温床になるような言語は要らない。

**名前は開発中のものです。** · 2006/01/23(月) 16:39:21

この板のWikiの専用ページに置いてあるだろうに

**名前は開発中のものです。** · 2006/01/23(月) 17:01:14

ここすか？
http://gamdev.org/w/?%5B%5BToHeart2%A4%DB%A4%ABAquaPlus%2FLeaf%A4%CEGPL%A5%B2%A1%BC%A4%F2%A4%A4%A4%B8%A4%EB%A5%B9%A5%EC%5D%5D#content_1_1

なんか不具合があるような報告があるんだけど、
ビルド＆実行できるんかいな？

**名前は開発中のものです。** · 2006/01/23(月) 18:18:50

saerchはなあ。ちょっと恥ずかしいなあ。
世の中結構つづり間違ってるソースあるけどさ。日本人はその辺弱い。

**名前は開発中のものです。** · 2006/01/23(月) 18:37:56

で、リファクタリング済みのソースUPはまだですか？
　＞設計が汚いとか実装がヘボイ云々言ってる賢い人々

#「１から作り直した方が早くて楽」であるなら、
#同じ機能を作り直したソースでも構いませんが…

**名前は開発中のものです。** · 2006/01/23(月) 18:53:40

じゃあ俺がreserveをresizeに直したのをUPするよ。

**名前は開発中のものです。** · 2006/01/23(月) 19:50:15

>>558
通りすがりが川を見て「汚い川だな」と言ったからって
その通りすがりがドブ掃除までするはずが無いだろう。

**名前は開発中のものです。** · 2006/01/23(月) 20:31:04

>>559
あの箇所はそれだけじゃ解決しないじゃん・・・。え、いや、もちろん
気がついてらっしゃると思いますけど

**名前は開発中のものです。** · 2006/01/23(月) 20:37:33

>560
所詮口だけってことだな。

**名前は開発中のものです。** · 2006/01/23(月) 20:41:17

>>560
最高に笑ったw

**名前は開発中のものです。** · 2006/01/23(月) 20:43:38

>>560
座布団3枚

**名前は開発中のものです。** · 2006/01/23(月) 20:45:45

自分から「キボンヌキボンヌ」と騒いでドブ川へ我先にと飛び込んでおいて、
「汚い川だな、服が汚れちまった、俺んちの池のほうが綺麗だぜ」とか
騒いでるようなもんだな。しかも、本当にそいつんちの池が綺麗なのかは
誰も知る由もないｗ

**名前は開発中のものです。** · 2006/01/23(月) 20:47:19

じゃあ、あれのソースはキレイなのかってぇとそうでもない気がするんだが。

**名前は開発中のものです。** · 2006/01/23(月) 21:19:31

やるか？　吉里吉里のコードレビュー

**名前は開発中のものです。** · 2006/01/23(月) 21:39:57

汚いソースのゲームだとウン万本売れるってことだ。
綺麗なソースだと売れないってことだ。

**名前は開発中のものです。** · 2006/01/23(月) 21:44:52

それが結論かも。
要は動くモノを送り出せばいいだけで、きれいにすることに時間かけることなんか
たいした意味がないということかも。

**名前は開発中のものです。** · 2006/01/23(月) 21:56:54

そゆことだな。コードの美しさなんか誰も評価してくれないし。

**名前は開発中のものです。** · 2006/01/23(月) 22:02:38

俺は汚いソース書いた部下を許さない

**名前は開発中のものです。** · 2006/01/23(月) 23:32:15

>>546
>なんでも自動化しようとしすぎてドツボにはまるのがC++マニアの限界
設計のやり方だろうな。下手な奴がやるとむしろよけいに汚くなる。
>解放順でエラーが出るとめんどい
出るのか？
どこからか参照されてる限り解放されないんだから、NULL にアクセスってこともないだろ？
あと俺は MFC 嫌い...。
>>547
>細かい実装部分に由来する不具合を追うのは大変
確かに。それは同意できる。
>大げさな設計をする必要はない。ベタでいい。
大げさな設計をする必要はないと思うけど、だからってベタにする必要はないんじゃね？
デザインパターンは結構小回りが効く設計だと思うんだけど。
>XvidもＣソース
いまだに C でプログラムを書かないといけないって現状を考えると、
こういったものは C で書くしかないんじゃね？

**名前は開発中のものです。** · 2006/01/23(月) 23:36:07

>>557
文字が前後逆になるtypoは日本に限らずありがちだと思うけど。
http://www.google.com/search?num=50&hl=en&q=saerch&btnG=Search

でも以前 ge-mu ってフォルダを見た時は切なくなった。

**名前は開発中のものです。** · 2006/01/24(火) 00:13:09

>>572
いいや、ベタにする必要はある。
際限なく汎用化、抽象化し、簡単なはずの物事を難しくしようとする設計厨にはわからんのかもしれんがな。

**名前は開発中のものです。** · 2006/01/24(火) 00:20:15

>>559
UPまだぁ～？

**名前は開発中のものです。** · 2006/01/24(火) 00:45:32

>>574
>際限なく汎用化、抽象化
そこまでは言わないよ。
俺も１回しか使わないようなソースであればベタで書いた方がいいと思ってる。
さすがに何度も使うような部分であればちょっと考えるけど。

**名前は開発中のものです。** · 2006/01/24(火) 01:25:54

YAGNI >>>>>>>>>>>>> OO

**名前は開発中のものです。** · 2006/01/24(火) 01:27:12

>572
そら上手い奴が上手くやればなんでも上手く行くけどな。
解放「順」が問題な。あと、リソースをこまめに節約しようと思うと、
どうしても手動で取得／解放する形になるなあ。目に見えるところで
制御したい。まあ、君がMFC嫌いだというのは分かる気がする。
デザパタは確かに有意義かもしれんが、あんまし今回関係なくない？
対応コンパイラがVC++とgccなんだから、C++でいい気がするが。

**名前は開発中のものです。** · 2006/01/24(火) 01:48:11

>>578
>上手い奴が上手くやればなんでも上手く行く
だね。ほんとそういう人たちを尊敬する。
>手動で取得／解放する形になる
null をセットすれば事足りるけど、確かにそれだと
どこかに残ってる可能性があるから怖いね。
でもどこかに残ってるってことは不正アクセスの可能性があるわけで……。
まあそんなプログラムは C だったら組まないか……。C++ だからありうる話だね。納得。
>あんまし今回関係なくない？
大がかりにならない設計を考えると、まず最初にデザパタの一部が思い浮かんだんだ。
考えてみれば、デザパタも小さいとは言えないかもしれない。
>C++でいい気がする
C しか使えない or C の方が使いやすいって人が多かったってことなのかな。
もしくはやっぱり多くの人に使ってもらうためとか。

**名前は開発中のものです。** · 2006/01/24(火) 02:19:15

>575
これかな？
ttp://gamdev.org/w/?%5B%5BToHeart2%A4%DB%A4%ABAquaPlus%2FLeaf%A4%CEGPL%A5%B2%A1%BC%A4%F2%A4%A4%A4%B8%A4%EB%A5%B9%A5%EC%5D%5D#contents_1

**名前は開発中のものです。** · 2006/01/24(火) 08:59:51

米国で単語の綴りがちゃんとかけない人ってのは多いらしいけどな
日本でも漢字は危ういことになっているみたいだが

**名前は開発中のものです。** · 2006/01/24(火) 10:06:52

>>580
それ、
＞じゃあ俺がreserveをresizeに直したのをUPするよ。
が入ってない。多分元のまんま。

引き続き、リファクタリング済みソースUPまだぁ？

**名前は開発中のものです。** · 2006/01/24(火) 11:42:49

>>547
> Ｃ＋＋は元々ある程度大きなプログラムを集団作業で作るために開発された
> 言語だ。大して大きくもないシステムを一人で保守するために、あんまり
> 大げさな設計をする必要はない。ベタでいい。

んあー、C++で同人シュー何本も１人作ってるけどどう見ても便利です。本当に（略）

MSX時代や98時代にグダグダと低レベルな実装してたのがSTLやboostで一撃で済むようになったし、
自作ライブラリの再利用や書き直しはすんなり行くようになったし、
コードの影響範囲が絞れるから原因不明のバグで１日つぶれるようなことも皆無に近くなったし、
ありがたいことこの上ないんですけど。
むしろこんなに楽になったらプログラミングの労働価値なくなるよなとか危機感抱きはじめてる。

そりゃC++の習得には結構な時間投資したし、C++自体は欠陥だらけの言語だと思うけど、
いったん作法が身についてしまえば、１人だろうがチームだろうがこれ以上の道具はないと思うけどなあ。
（WindowsではもしかしたらC#が来るのかもしれんけど）
最高ではないが最良の武器ってやつ。少なくともCなんてもう馬鹿馬鹿しくて使ってらんない。

つーか、何か仮想的を想定してない？　不必要に仰々しいOOP論者とか。そゆのは俺も嫌いだし。

>>546
> 俺だってその気になればC++使えるけど、デバッグ時に
> いちいち参考書読んで調べながら、なんてやってられんだろう。

いくら複雑な言語とはいえ、いちいち本開くようでは使いこなせていないにもほどがあるでしょ。
単にキミがC++初心者なだけでは？　C初心者の頃もそんな感じじゃなかった？

アドバイスすると、C++を使う上での原則やよく使うAPIをテキストファイルにでもまとめとくといいよ。
参考書がでかいなら圧縮しなさい。難しい問題に対するのに、ノートを取りもしない人間が多すぎる。
学生時代に一体どうやって勉強していたのか。