＠＠前向きに、Linuxの改善点を語ろう　２ ＠＠

ソースコードが書けなくたっていいじゃないか。
初心者なら初心者なりの「ここが使いづらい」という意見、
上級者なら上級者なりの意見を交わしましょう

論破されたことを悔しがった負け犬に荒らされた前スレ
http://pc8.2ch.net/test/read.cgi/linux/1024241941/l50

誰も使うなとは言ってないわけだが？

なんでこう、バカというのは捏造したがるのか。

ちゃんと書いてある「使いたきゃ使え」

>>156
それは違うと思うよ。
C++ 風に書くなら、メッセージの伝播はインターフェースベースになるはずで、
具体的には純粋仮想関数を使って実装することになるんじゃないかな？
で、 MFC も実際そうしているんだけど、そこで何故メッセージマップが
必要になるかというと、Windows が C++ を想定していないからだ。
メッセージマップですり合わせる必要性はそこから生まれる。

あと、独自の関数があるだけと君は書くけれども、
Windows はメッセージパッシングという手法を基本にしている。
これは、OO の考え方だ。
そして、Windows はシステム全体が OO の手法で出来ている。

>>158
MFC は、そうだね。
>>152 は、Windows について書かれているから。

何がメッセージマップなのか。
Windowsのメッセージは所詮コマンド的なもの

これがあればC++ではないのか。
ならば独自関数があるとC++ではないとでもいうのか。

「考え方」はC++。

>>162
簡単に書くとね。
MFC について書くなら、まず、MFC を使ってみたほうが良いんじゃない？
こういうことを書いてるんだよ。
知らないものについて語っても無理があるでしょ。
背伸びしないで良いんだよ。

>>163

簡単に書くとね。
MFCも知らないバカは帰れってことなんだよ。


140 名前：login:Penguin ：2006/06/02(金) 23:52:46 ID:u+6aL2LC
>>137
書き込みの意味がわからないんですけど？



こんな、MFCも知らないようなバカが背伸びして書き込めるスレはいいスレだなあ。

メッセージマップだの、知らないバカが知ったかで語るが

「あって何が悪いのか」

と言う点に尽きるな。
それがあることでWindows独自の体系とはなるかも知れないが、
だからといってC++ベースの考え方まで変化するか
というと、しない。単なるメッセージの割り振りを決めるためのもの、
働きなんざコマンド的なもの。

知らないものについて語っても無理があるでしょ。
背伸びしないで良いんだよ。

だいたい、Microsoft が積極的に C++ をサポートする API を出したのって
Gdiplus が初めてじゃないの？
COM で提供される API が C++ 向けとは思わないし。
C++ を主にサポートするって意味でね。

誰か、そろそろLinuxの話をしたくなってきた奴はいない？
俺は寝るけど。

>>167
したい。
特に Lynx Desktop の可能性について。

これもしかしてこの前のVisualStudio自慢オヤジと
いつもの池沼の対決？
板違いな話なんだからsageてくんね？

そもそも何が言いたいのか分からない。



MFCは便利なクラスライブラリ
↓
便利なもんで使うなと言うアホもいる (使う使わないは個人に任せろ)
↓
140 名前：login:Penguin ：2006/06/02(金) 23:52:46 ID:u+6aL2LC
>>137
書き込みの意味がわからないんですけど？



MFCは便利なクラスライブラリ
なもんで嫌う奴がいる


これが間違いだとでもいいたいらしいが
それそのものが大間違いだと言うことにさえ気づかず
挙句にゃ「メッセージマップ」

そのうちキューがあるとC++じゃないとか言い出しそうだ

とりあえず>>168はLynxという超有名ブラウザがあると
知った上で言ってるんだよな？
かけてるにしても意味分からないんだけど

>>170
使ったことも無いのに「便利なクラスライブラリ」とか書いても
説得力無いだろってことだよ。

>>171
最初から読んでよｗ
デスクトップをブラウザにするって話から始まってるんだからさ。

>>172
MFCを使うどころかMFCの概念や性格さえ知らないバカが言うなってことだよ。

例えば
OWLを使ったことが無くても、見れば「便利そうだね」と誰もが言う。
この「便利」は相手を説得させるためにあるものじゃないことは
バカ以外誰でもわかる。

ただの感想じゃん
何のどこに説得力とやらが必要になるのか。

>>174
では聞くが、どこがどう便利なのさ？
いちいち反論したっていいんだぜ？

それよりも先に、「ハードの進化などあってはならない」とか言うバカだから
MFCどころかC++さえ知らないのだろうが

>>176
あのね。
進化さえしなけりゃどんどん安くなるんだよ。
100円 Linux なんて最高だろ？
もちろんハードウエア込みの値段だよ。

>>175

例えば
GDI+などへのアクセスを行うのに、自前で書く必要がない

では聞くが、これのどこがどう便利ではないのさ？
いちいち反論したっていいんだぜ？

>>178
自前で書くって何のことでしょう？
いちいち意味がわからないのですが？

>>177
あのね。
進化しているからどんどん安くなるんだよ。
進化すると安くならないのなら今386なんぞ値がつかないのは何故なのか。

何故なのか答えられずにまた逃げるか？バカは消えろ。

>>179
プログラムもできないバカがシャシャリ出てきているのは何故でしょう？
いちいち意味がわからないのですが？

>>180
386 は進化しないので安くなったのです。
なんてすばらしいんでしょうｗ

>>181
MFC を使えば Gdiplus を自動的に使ってくれるとでも？
使ってくれるとでも？
使ってくれるとでも？

>>182
386以外にCPUは出てきてないのでしょうか。
なんてすばらしいんでしょうｗ

価格については需要と供給のバランスによって変化（安値に落ちていく）するものであって、
進化によって変化するのではないよ。
新しいものの価格が高いのは単にまだ需要があるかどうか分からないからと、
生産ラインが落ち着いていないから。

>>183
MFC を使えば Gdiplus を自動的に使ってくれるって何のことでしょう？
誰が書いたんでしょう？
使ってくれるとでも？
いちいち意味がわからないのですが？

>>184
進化したプロセッサは高くなりました。
ていうかね。
君って、平日の11時にスレ立てできる身分なんだよね？
いったいどういう人なの？

進化しなければ、386の需要がまだあるはず。
ということは、安くならずに値がつく状態にあるわけだ。

ところが値がつかないのは、進化して486やその後継が出てきたために
値がつかなくなった=安くなった
わけだ。

償却と需要供給の違いさえ知らないバカがいるんだよｗ

>>187
進化したプロセッサは後継が出ると値落ちしました。

ていうかね。
君って、何でもかんでも妄想ばかりだよね。
いったいどういう人なの？

>>189
ところで、MFC のどこが便利なの？
嫌々使ってるんですけど？
いつ便利なの？
どういうものを作るときに便利なの？

償却済みであれ、需要がある限り進化しなくても値はつく。
いくら償却してもタダで供給しますと言うことにはならない。
そら商売だしｗ

が、進化して486が出れば需要が無くなり消えていく。
だんだん値がつかなくなる=だんだん安くなる


進化がないと安くなるはずなのに
進化がないといつまでも値がつく不思議さよｗ

がんばってググルといいと思います！

>>190
ところで、これに対して答えずに逃げてばかりなのは何でなの？
これのどこが便利じゃないの？
いつ便利じゃないの？
料理を作るときにMFC使うとでも思ってるの？

178 ：login:Penguin：2006/06/03(土) 00:39:14 ID:Olq/zX+f
>>175

例えば
GDI+などへのアクセスを行うのに、自前で書く必要がない

では聞くが、これのどこがどう便利ではないのさ？
いちいち反論したっていいんだぜ？

がんばってググっても知らない無知は
やはり逃げてばかりでしたね！

>>193
自分で書く必要があるよ。
どういうものだと思っているの？
自動的にアクセスしてくれるとでも？

>>195
その部分は自分で書く必要がないよ。
どういうものだと思っているの？
自動的にアクセスしてくれると誰が言ったの？
自動的にアクセスしてくれるとでも？

だれがメソッド部分を省略できると書いたの？
どういうものだと思っているの？
自動的にアクセスしてくれると誰が言ったの？
自動的にアクセスしてくれるとでも？

>>196
もうグダグダだねｗ
きみさぁ。
Linux 本当に使えてるの？

>>198
また答えられずに逃げたねｗ
きみさぁ。
Linux 本当に使えてるの？

ﾊﾗﾍｯﾀ…
今日はx86_64 Linux clusterのLSFにsubmitするmpitch programの
問題でおお嵌り。まさか、
1)終了したJOBのprocessがbackend nodeにゾンビになって残っているとか、
2) kill -9 -1 しても Shared memoryやSemaphoeのresource解放がされないことがある
なんて…orz
1)はOSまたはLSFのbugだ。絶対。さて今日は仕事上がって美味いもの食べに行くか。
じゃあね。ﾉｼ

>>198
>GDI+などへのアクセスを行うのに、自前で書く必要がない

こう書いてある。
ということは、君は Gdiplus が MFCに組み込まれていると考えていたわけだ。
ていうか、どっちも知らないって言うのが本当の答え。

>>201
>>198
>GDI+などへのアクセスを行うのに、自前で書く必要がない

こう書いてある。
これのどこが、GDI+が が MFCに組み込まれていることになるのか？
逆に君はGDI+がMFCに組み込まれていると考えていたわけだ。

ていうか、どっちも知らないって言うのが本当の答え。

ここまで、彼の書き込みにきっちりと反論できている人が
居ないのがすごいと思った。
むしろ、彼の書き込みを見て「Windows ってすごい」とか
思ってそうな書き込みが多いよね。
Linux 板の程度っていったい・・・

つうかMFC使用なのにビットマップせえと。
そういうことをいいたいわけかｗ

まぁた負け犬の遠吠えかよ

いい加減見苦しい

>>204
そこまで言うなら、はっきりさせよう。
ごく簡単な Windows プログラムを明日提出。
俺もお前もだ。
それを見比べて判断しようジャマイカ。
まけねーぜ。

早速お題を決めよう。

結局逃げるんだよな

何一つ答えてねえw

ちなみに Windows は古臭いです。
ちっともすごいとこなんて無いです。

>>207
早くお題決めようぜ。
1日で出来る簡単なやつで良い。
付き合ってやるぜ。

スレタイに反して、後ろ向きな粘着厨が
集まるスレですか？

答えてからにしろや。

>>210
暇なんです。

>>211
プログラミングしたことが無いってはっきり書けば？

>>213
プログラミングしたことが無いってはっきり書けば？

何一つ答えられない = プログラムすらできないバカ


いい証拠

>>214
プログラムを明日提出。
それを見比べて判断しようぜ。
俺はぜんぜん負ける気がしないｗｗｗ

とっととお題を決めよう。

ほらよ
int main()
{
printf("Hello,Nenchaku!");
return 0;
}

>>218
それは駄目でしょｗ

とっとと答えろ
答えられねえなら消えろ

Gdiplus を使って自前描画する基本的なテキストエディタなんてどうよ？
勝負としては面白いだろ？
1日でどこまで実装できるかを競う。
腕の差、出まくりだよｗｗｗ

>>220
やるのかやらないのか5分以内に答えなさいね。
やることに決まれば全力を以って戦いますｗ

Cなんだろうなw

>>223
普通に C++ を使いますが、何か？

とっとと答えろ
答えられるのか答えられねえのか5分以内に答えなさいね。
やることに決まれば全力を以って戦いますｗ

>>225
ひとつ。
やるって答えないと、傍観者は君のこと見下すと思うよ？
やろうよ。

既存流用コード一切無し
完全オリジナルを作るわけだな

これ言っとかねえとソースをパクるバカが出るからなあ
MFCよりラクな手法をよ

いいなｗ

>>227
1. エディター部分にコントロールは使わない。
2．以下何か付け加えるものがあったら付け加えて。

>>226
ひとつ。
やるって答えても答えなくても、傍観者は君のこと見下すと思うよ？
あそこまでバカ晒して論破されてるからねえ。
やろうよ。

既存流用コード一切無し
完全オリジナル

>>227
俺は MFC は使わなくても良いよ。
基本的なエディター作るのに MFC 使って楽できるとは思わないし。

普通は、DnD 実装するのに COM がなぁ〜〜とか考えて MFC 使うでしょ。
今回そこまで出来るとは思えないしね。

>>229
了解。
じゃぁ、時間指定して。
現実的な制限時間ね。

エディタにドラッグアンドドロップなんざ必要ねえよなw

で？
ソースコードの公開は？

>>232
そう？
選択してそのままドラッグなんて普通に必要でしょ。

時間よろしくね。
あと、重要なことがひとつ。

Gdiplus を使っていることがわかるようにしておくこと。
これは簡単に出来るよね。
これによって、既存コードの流用でないこともある程度保障されるし。

>>233
どっちでもいいよ。
メッセージ見てればバイナリだけでも判断つくしね。

誰が、既存ソース使ってないって証明するんだヲイ。
オマエら馬鹿丸だし w)
当然、windows.h 諸々、インクルード禁止だよな。

時間はどうでもいい。

バイナリだけじゃ判断できない。
パクリがあっても判断できない。

>>236
それは無理でしょ。
エディタの実装に流用しないって位の話。
1日で出来ることなんてたかが知れてるから。
メッセージ見て十分判断がつくよ。
頭の程度もわかるよね。

>>236
それ前提だよｗ
RADも不可だし手書きでｗ


まあいいが

>>239
RAD は使っても意味無いでしょ。
コントロール禁止なんだからさ。

とにかく、逃げずに完成させようぜ。
お互いな。

でねえと逃げ道色々あるからなあ

んじゃ。
7月4日23時まででいいかな？

まちがえた。
6月4日23時ねｗｗｗ

また間違えた。
6月3日23時ｗｗｗ

>>240
手書きだな

時間はそれでいいよ

>>245
6月3日23時ね。

Gdiplus を使って自前で描画する。
当然だけどコントロール・コンポーネントの類を使わない。
もうひとつ、オリジナルであることがわかるように
起動直後のエディタ画面中央に「2CH」と大きく薄い青で表示。
最初に入力を開始したときにそれを消す。
この程度でも spy++ で見ればオリジナルと判断できるでしょ。

ソースコードの公開。
というかこれでないとオリジナルとは判断できない。

>>247
俺は別に公開でも良いよ。

ほかに何か作りこむとか条件とかある？

俺はとりあえず
ソースコードの公開、
既存流用コード一切無し
完全オリジナル

だな

仕込みがあってもつまらんし

>>249
はいはい。
それじゃ開始ね。
付き合ってくれてありがとさんｗ

それじゃ23時に。

>>249
お前もがんばって作るんだよ。
ソース公開ならお互い勉強にもなるしな。

いつまでも何言ってんだ

#!/Perl/bin/Perl
$jane2ch_ini='E:/openjanedoe-0.1.12.2/JANE2CH.ini';
open(INPUT, $jane2ch_ini) || die "Couldn't open $jane2ch_ini for reading: $!\n";
@lines = <INPUT>;
close INPUT;
($jane2ch_bak = $jane2ch_ini) =~ s/\.ini$/\.bak/i;
rename($jane2ch_ini, $jane2ch_bak) or
die "Couldn't rename $jane2ch_ini to $jane2ch_bak: $!\n";
open(OUTPUT, "> $jane2ch_ini") || die "can't open $jane2ch_ini for writting: $!\n";
foreach (@lines) {
chomp;
print OUTPUT $_;
if (/^WrtCookie\s*=(.+)$/) {
unless ($1 =~ /hana\s*=\s*mogera\s*;/) {
print OUTPUT " hana=mogera;";
}
}
print OUTPUT "\n";
}
close OUTPUT;

ソフトウェアは目的があってつくる物だし

MFCやGDIは使いにくい
それがLinuxを選ぶ一つの理由
先祖帰りなんてバカみたい

便利といえば便利
OSの挙動を知るという、基本を学ぶときには
使用すると分からんままになると言うだけで
そういう基本をしっかり習得したなら後は使っても問題ない。

俺が課題出してやろうかＷ
GUI不要のアルゴリズム指向がいいなｗ
なんちゃって、うそさ。
今は無きＣマガの課題でも解いてな

Linuxはもう少し使いやすくなれば更に素晴らしいんだがな
って思う点はまだある。だろ？
Windowsに近づたら解決する？
しないよな