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(日) 12:35:44

>>452-454
自演をしてるつもりなのかそれとも単なる2ch初心者なのか…

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

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

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

>>454
単なる暇つぶしだろ

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

>>455
単なる暇つぶしだろ

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

>>456
だが、その稼働のためにどれだけの（無駄な）時間を使ったのか考えて欲しい。

ちゃんとした設計の出来る、凄腕のプログラマがやれば、
もっと融通の利くスクリプトが、短期間でLeafに渡されるだろう。

機能を追加したりする場合、今のソースだと、
ある変数を使うと、どこまで影響が及ぶのか想像が付かない。
ある程度設計をしていれば、それも手軽に出来るようになるだろう。

このソースを見る限り、ディレクターは「こうしたい！」っていう機能があったにも関わらず、
それをプログラマによって諦めさせられているような気がする...。

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

> ちゃんとした設計の出来る、凄腕のプログラマがやれば、

貴重種です。

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

上がプログラムを軽視してるんだろう。
似たような内容で量産するならプログラムに金（出来る人、時間）掛けた方が
絶対いいのに。

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

高給取りが必ずしも優秀とは限らないのが
プログラマーの世界
なにしろプログラムの「長さ」で給料が決まるからね

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

ゲームでそれはないでしょｗ
受け入れ試験すらみたことないよ。

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

経済を無視してる香具師が多いな
仮に出来が良くても高くて時間がかかるものなんて売れないんだよ

俺みたいな低賃金orzデジタル土方が手早くそれなりに文句も言わずに動くものを作る方が需要がある
特にエロゲみたいな技術水準が低いものではな

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

ヒント：Leafは利益を上げ続けているエロゲ業界最大手の一つである。

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

>>426
ごめん、ちょっと詳しくおながいします

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

揚げ足とりで煽り愛ですか？

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

>>459
「頭でっかち名無しの空論・べき論」乙。

>ちゃんとした設計の出来る、凄腕のプログラマがやれば、
>もっと融通の利くスクリプトが、短期間でLeafに渡されるだろう。

こう言えばあらゆるプログラムを否定できるなｗ

お前の携わったモノも、誰かが陰口叩いてるんじゃね？
「>459じゃなく、もっと凄腕のプログラマがやれば、
もっと効率がよく、短期間で出来た」
ってな。

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

>445
ソースを綺麗に書いても、検証が足りなきゃ信頼性は低い。
洋ゲーみたいに、動かないのはユーザの環境が悪いと言えたり、
コンシューマみたいにマシン環境が一定したりしてないからな。
バグ修正で金がもらえるようなヌルい仕事してねえよｗ

>451
メモリリークの話なんかすんなよ。レベル低すぎ。
そんなもんはつぶしてあるのが前提の話だろうが。
つーかさすがに俺もデストラクタは使うから、スコープを外れれば
自動解放されるし、メモリリークはほとんど起こさんけどな。

スマートポインタの使い方回りで変なバグ作りこむ方がやっかいだ。
参照カウンタタイプのものは自分では一切使わないな、俺は。
解放タイミングが見えにくいのも怖いし。
所有権（と解放責任）の委譲なんかするからバグの元になる。

>452
今まともにプログラム勉強してればその辺の知識は手に入る。
あえて使おうとも思わんだけだろうと思うんだが。

>462
コードの長さで金もらったことないな。

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

>459
>このソースを見る限り、ディレクターは「こうしたい！」っていう機能があったにも関わらず、
>それをプログラマによって諦めさせられているような気がする...。
ソースからどうやってそんなこと読み取んだｗ　超能力者かｗ
これだけベタなハードコーディングしてるところをみると、逆に、
構造をウンウンうなって考えてるばかりでコード書かない奴よりは、
アドホックな対応を期間ギリギリでやってくれそうだがｗ

>464
>要求水準
ソースの構造設計や再利用性に関する要求水準が低いのは、
別にエロゲに限ったこっちゃねえな。コンシューマでもそう。

459と同じで、ソースコードの構造に頭をひねり作りこむのと、
実際の動作で要求に答えることとを混同してないか？

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

>>470
うん？、要求水準なんて書いてないが

コードの構造なんて考えるのは時間の無駄
手慣れた書き方で早く作るのが肝心

要求が増えたら継ぎ接ぎで増やすだけ

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

お互い「俺はこう思う」の応酬で歩み寄りがないからいつまでたっても平行線
なんでLeafのソースをだめだと言われたぐらいで怒る奴が居るのかがわからん
そういう人は同業者としての自分が責められてるような気がするのか？

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

俺には数字の見えない年収自慢にしか聞こない。

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

１０年より少し前までは当たり前のように
プログラム行数で金額を請求していた。

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

>だが、その稼働のためにどれだけの（無駄な）時間を使ったのか考えて欲しい。
そんな想像でしか分からない事考える方が無駄だと思うが。

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

>471
ごめん、一行目は技術水準の間違いだった。
で、設計に対する要求水準と成果物の技術水準を混同するなということを
言いたかったわけだ。

そのとおり、時間の無駄。働かないマニアを飼っとく余裕はない。
ベタコードで書いたって読める範囲のものを作るときはベタに書け。

>472
ダメだしがいかにも頭でっかちだから突っ込んでるわけだが。
たとえばライブラリが再利用性なさそうで、ライブラリと言えないとかの
批判は妥当だと思うし。

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

「仮想凄腕プログラマ」を使えば、世の中のソフトウェアに纏わる問題は全て解決できるな(藁

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

「表に出てきていないだけで、恐らくまだまだ」あったらいいな、
ってな仮想バグを使えば、どんなプログラムでもけなせるしなｗ

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

>477
でも、実際の仕事の段階で『無能大口プログラマ』にオーバーライドされるから、
あまり意味は無い。

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

ここはマ板でつか？

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

アルゴリズム創り出せるくらいの能力があるならともかく、
普通は速くて安ければソース気にする上司や顧客は少ないけどな

凡人はソースの美しさに時間を掛けるより、デバッグに時間を掛けた方がバグは少ない
美しさ気にしなければバグ直すのも速いし

**466** · 2006/01/22(日) 18:53:06

誰か教えてくれー、8500でゲーム作ってるのでもの凄い気になる

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

>482
全ファイルを8500などで検索してみろよ。

**名前は開発中のものです。** · 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

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