掲示板
Powered by OTD
この記事は、K.Maebashi's BBSの過去ログです。
書き込む場合は、新しい掲示板へお願いします。
[日付順表示] | [日付順インデックス] | [スレッド順インデックス]


新規投稿 | 開設者ホームページへ戻る | ヘルプ


[630] Re:数値のエラー処理
返信


投稿者: ishikawa
2004/02/16 21:45

Mail:   Link:
 レスありがとうございます。
> 「残りのバッファ」の「残り」というのは、何から何を引いた分を指して
> 言ってますか?
> たとえば、ユーザが1234567890123[改行]と入力した場合、
> 最初にnumberに格納されるのはどんな文字列ですか?
> また、いらない部分を捨てたければ何をすればよいと思いますか?
「残り」というのはfgets(number,SIZE+2,stdin);この部分でnumberに読み込まれ
なかった部分です。1234567890123[改行]が入力された場合は「123[改行]」が「残り」
です(この時点でnumberには「1234567890[nul文字]」が入ります)。
 いらない文字を捨てたければ無理やりバッファを読み込めばいいと思いました。

で・・・、改行の部分はうまくいけました^^; getc()をEOFで制御してたからダメだったんですね・・。
・・・が[ctrl+z]で終わらした場合にどうしてもうまくいけません。
このように書き変えたんですが
if(strlen(number) >= SIZE) {
    while(1) {
if((flag = getc(stdin)) == 0x0A) break;
   if(flag == EOF) break;
}
//printf("%d\n",getc(stdin));
printf("\a桁数が多すぎです、やり直しです:");
goto retry;
}
なぜか無限ループになります。なにが残ってる(?)のかなと思って↑のコメントの部分
で調べたんですが、なぜか-1が永遠に入ってました(?)。
[ctrl+z]のあとに[改行]を打ったから0x0Aでも残ってるのかなとかも考えたんですが
違いました。
[ctrl+z]で終わらした場合のバッファの処理は無理なんでしょうか・・・。


[629] Re:誤解?
返信


投稿者: (ぱ)
2004/02/16 19:50

Mail:PXU00211@nifty.ne.jp   Link:http://kmaebashi.com/
 > サブクラスを増やす毎に、呼び出し部分を含むファイルShapeTest.javaはいつも
> 修正、再コンパイルする必要があると思うので、誤解が溶けないのです。

そりゃあ各Shapeをnewするところまで含まれば、修正しなければならないでしょう。
私が書いているのは、「呼び出し部分のコード」についてです。
「呼び出し部分のコード」がどこかといえば、(KYさんがコメントをつけて
おられるように)

> shapes[i].draw(); // 呼び出し部分

この部分です。

テストプログラムはいざ知らず、現実にドローツールを作るなら、
「呼び出し部分のコード」と「newする部分のコード」は別々に記述される
ことが多いはずです。「Java謎+落とし穴〜」をお持ちであれば、
List3.35のXDrawCanvas.javaが、draw()メソッドの「呼び出し部分のコード」を
含みます。XDrawCanvas.javaは、Shapeの種類を増やしても修正/再コンパイルの
必要がありません。
XDrawに図形を追加する場合、どことどこを修正する必要があるかについては、
「3.6.6 図形を追加する場合には」を参照してください。

どうせ修正が入るなら、draw()を呼ぶところだけ修正しなくて済んでも
たいしたメリットはないのではないか、と思われるかもしれません。
しかし、図形ごとの挙動というのは「描画」に限らないわけで、
マウスでピックされたときの判定とか、囲んで選択する際の範囲算出とか、
そういったメソッドが増えてくると、ポリモルフィズムを使ったほうが
便利だ、ということになります。
# …という議論には異論がなくもなく、それは3.6.7に書きました。


[628] 誤解?
返信


投稿者: KY
2004/02/16 10:46

Mail:katsutoshi_yamaguchi@mhi.co.jp   Link:
 前橋さんの著書「Java謎+落し穴」や、C言語ヨタ話「無理矢理インヘリタンス」に
以下のような記述があります。

# メソッドオーバーライドについて、コンパイラが呼び出しの所にswitch caseを展開
# しているんだ、と思ってる人って、実は結構いそうな気がするんですけど、それは
# 誤解ですからね。もし、そうだとしたら、さらに継承してサブクラスを増やす毎に
# 呼び出し部分のコードを再コンパイルする必要があります。

でも、次のような場合、
class ShapeTest {
public static void main(String[] args) {
Shape[] shapes = new Shape[3];
shapes[0] = new Polyline(); // 既存のサブクラス
shapes[1] = new Circle(); // 同上
shapes[2] = new Rectangle(); // 増やしたサブクラスに対する追加コード
for (int i = 0; i < 3; i++) {
shapes[i].draw(); // 呼び出し部分
}
}
}
サブクラスを増やす毎に、呼び出し部分を含むファイルShapeTest.javaはいつも
修正、再コンパイルする必要があると思うので、誤解が溶けないのです。

何か根本的な勘違いをしているのでしょうか? 呼び出し「部分」の再コンパイルという
のも理解できないし。
(私はJava初心者で、Appletや、C/C++はよくわかりません。)


[627] Re:数値のエラー処理
返信


投稿者: (ぱ)
2004/02/16 02:23

Mail:PXU00211@nifty.ne.jp   Link:http://member.nifty.ne.jp/maebashi/
 > この部分の処理がうまく言ってないように思えます。一応自分ではfgets関数で切り取ら
> れた残りのバッファを全部処理してるつもりなんですが、

うーん。
「残りのバッファ」の「残り」というのは、何から何を引いた分を指して
言ってますか?

たとえば、ユーザが1234567890123[改行]と入力した場合、
最初にnumberに格納されるのはどんな文字列ですか?
また、いらない部分を捨てたければ何をすればよいと思いますか?

fgets()は、第2引数で指定された文字数までしか読み込みませんから、
この例だと10文字を超える入力があった場合、残りを入力ストリームに
食べ残します。その場合、改行がどのタイミングでやってくるか、
図など書いて確認してみることをお勧めします。




[626] 数値のエラー処理
返信


投稿者: ishikawa
2004/02/15 23:51

Mail:   Link:
 いきなりですが以下のコードがうまくいかないんです、なぜなんでしょう?
ただたんに数値を入力して表示するプログラムです。エラーの種類を多くつけました。

if(strlen(number) >= SIZE){
   while(getc(stdin) != EOF) ;   /* ここ */
   printf("\a桁数が多すぎです、やり直しです:");
   goto retry;
}
この部分の処理がうまく言ってないように思えます。一応自分ではfgets関数で切り取ら
れた残りのバッファを全部処理してるつもりなんですが、もう一度fgets関数を呼び出す
と自動的に(入力することなく)素通りしてしまいます。
ご教授お願いします。


#include <stdio.h>
#include <ctype.h>
#include <string.h>

#define SIZE 9

int main(void)
{
int i;
char number[SIZE+2];
int hoge;

printf("10進数で数値を入力してくだい(%d桁までです):",SIZE);
retry: ;
fgets(number,SIZE+2,stdin);
for(i = 0; number[i] != '\0'; i++){
if(number[i] == 0x0A){ //改行まできたらそこにnul文字を入れる
number[i] = '\0';
break;
}
if(strlen(number) >= SIZE){ //桁数が多くないかチェックする
while(getc(stdin) != EOF) ;
printf("\a桁数が多すぎです、やり直しです:");
goto retry;
}
if(isdigit(number[i]) == 0){ //数値以外が入ってるかチェック
printf("\a10進数値を入力してください、やり直しで
す:");
goto retry;
}
}

sscanf(number,"%d",&hoge);  //表示
printf("あなたの入力した数値は%dですね!!!!",hoge);

return 0;
}


[625] Re:構造体の代入方法によえうメモリ消費量
返信


投稿者: (ぱ)
2004/02/15 15:19

Mail:PXU00211@nifty.ne.jp   Link:http://kmaebashi.com/
 > この2つのプログラムでは、
> メモリの消費量は違うのでしょうか?

ここで「メモリの消費量」とは何を指して言っていますか?
構造体の内容を保持しておくためのメモリについての話ですか?
それとも、代入するためのコードが消費するメモリサイズ(Windowsなら
.EXEのサイズに影響する)の話ですか?

前者についてであれば、代入方法に関係なく、メモリの消費量は等しいでしょう。
どちらもsizeof(DAT)で得られるサイズを消費します。
これが異なるのではないか、と疑問をもたれたのでしたら、その理由を
教えてください。ナックさんがなにか誤解しているのならそこに原因がある
はずですし、あるいはナックさんの疑問が正しくて私が知らないだけかも
しれません。

後者についてであれば、コンパイラによりますが、一括代入の方が
小さなコードを吐いてくれる可能性が高いでしょう。

ちょっと手元のbcc32で、-Sオプションをつけてアセンブリコードを吐かせて
みたところ、ナックさんの例では、どちらも同じコードを吐いたようですが、
構造体のメンバの数を増やしたら(7個)、ひとつひとつ代入しているほうは
こんなコードになりましたが、

mov eax,dword ptr [ebp-28]
mov dword ptr [ebp-56],eax
mov edx,dword ptr [ebp-24]
mov dword ptr [ebp-52],edx
mov ecx,dword ptr [ebp-20]
mov dword ptr [ebp-48],ecx
mov eax,dword ptr [ebp-16]
mov dword ptr [ebp-44],eax
mov edx,dword ptr [ebp-12]
mov dword ptr [ebp-40],edx
mov ecx,dword ptr [ebp-8]
mov dword ptr [ebp-36],ecx
mov eax,dword ptr [ebp-4]
mov dword ptr [ebp-32],eax

一括代入のほうはこうでした。

lea esi,dword ptr [ebp-28]
lea edi,dword ptr [ebp-56]
mov ecx,7
rep movsd

もちろんコンパイラによっては違う結果になるかもしれませんし、
速度がどっちが速いかは、また別の話です。


[624] Re:移転
返信


投稿者: (ぱ)
2004/02/15 14:52

Mail:PXU00211@nifty.ne.jp   Link:http://kmaebashi.com/
 > | Link:http://member.nifty.ne.jp/maebashi/ 
> ↑こんなところも、まだまだ張り替えられてませんしね(^.-)

おおっ、これは見落としていました (^^;

> (ぱ)さんは投稿しているsiteが多そうですし、
> cookieで楽してると、いつまでも古いsiteへのlinkが残ってしまうとかいう...

いやあ、そんなにあちこちの掲示板に書き込んでいるわけでもないですし、
書き込んでいる場合でも、WebページのURLまではつけないことが多いです。
というか要求されない掲示板が多いような。tcupあたりだと、一応入力欄が
ありますが、そこにURLを入れると本文の最後にURLが出てしまって、
それもどうかと思いますし。

> > ~/essay/tsuru.htmlを読んでる人もいるのか、とか。
> あのシリーズ(でもないか)も再開はしないんですよね...(^^;)
> アマチュア 漫画家とか、与太話とか。

ええとその(^^; 「第1部完」とか「戦いはこれからだ!」みたいなものだと
解釈してください。実際時間がないだけですので…


[623] 構造体の代入方法によえうメモリ消費量
返信


投稿者: ナック
2004/02/15 04:04

Mail:   Link:
 #include<stdio.h>
typedefstructdat
{
unsigned int dat1;
unsigned int dat2;
}DAT;
int main(void)
{
DAT src_dat={1,22};
DAT copy_dat;
copy_dat=src_dat;
}

#include<stdio.h>
typedefstructdat
{
unsigned int dat1;
unsigned int dat2;
}DAT;
int main(void)
{
DAT src_dat={1,22};
DAT copy_dat;
copy_dat.dat1=src_dat.dat1;
copy_dat.dat2=src_dat.dat2;
}

2つのプログラムがあります。
処理内容は構造体を構造体に代入しております。
同じ処理内容だと思いますが、
代入方法が違います。
下のほうのプログラムですと、
メンバ毎に代入しております。

この2つのプログラムでは、
メモリの消費量は違うのでしょうか?

メモリの使い方(割り当て方)が全然分かりません。
教えてください。


[622] Re:移転
返信


投稿者: 本多
2004/02/14 21:58

Mail:manybook@msc.biglobe.ne.jp   Link:
 > いろいろ調べると、「転送量無制限」と言っても実は無制限ではない
> ことが多いようなんですよね。
へぇ。。そうだったんですね...

> それぐらいなら、うちのページが制限にかかるとはちょっと思えませんし、
> はっきり制限を出してくれてるところの方が信用できるかな、と。
たしかに、明示されていない制限を超えたら追い出されちゃうのも
困りますよね。
でもそういうのを基に法律的に追い出すなんてありなのかしら?

> 上のプランと下のプランとでは「転送量無制限」の意味が違うんじゃ
> ないでしょうか。
そのようですね。

> まだ、検索エンジンやらブックマークやらリンクやらが張り替えられたりして
> いない、というのもあるでしょうが、20Gの制限にはまだまだ余裕でオッケー、
> という感じです。
| New[621] Re:移転
| 投稿者: (ぱ)
| 2004/02/14 16:38
| Mail:PXU00211@nifty.ne.jp
| Link:http://member.nifty.ne.jp/maebashi/
↑こんなところも、まだまだ張り替えられてませんしね(^.-)
(ぱ)さんは投稿しているsiteが多そうですし、
cookieで楽してると、いつまでも古いsiteへのlinkが残ってしまうとかいう...

> ~/essay/tsuru.htmlを読んでる人もいるのか、とか。
あのシリーズ(でもないか)も再開はしないんですよね...(^^;)
アマチュア 漫画家とか、与太話とか。


[621] Re:移転
返信


投稿者: (ぱ)
2004/02/14 16:38

Mail:PXU00211@nifty.ne.jp   Link:http://member.nifty.ne.jp/maebashi/
 > まぁ、(ぱ)さんのsiteは、映像音楽などの(ほとんど)ない文字中心のsiteですから
> 取り立てて問題はないんでしょうけど、
> 上から2番目のプランにだけ制限があるっていうのが激しく謎ですね(^^;)

いろいろ調べると、「転送量無制限」と言っても実は無制限ではない
ことが多いようなんですよね。

http://www.0405.net/radio/html/05site/3rentalserver/02.html
http://www.e-provider.jp/server/traffic.html

それぐらいなら、うちのページが制限にかかるとはちょっと思えませんし、
はっきり制限を出してくれてるところの方が信用できるかな、と。
それに、もし本当に無制限なら、隣の誰かが回線を使い尽くすかもしれないし。

TwodotsNetは、上から2番目のプランにだけ制限があるように見えますが、
上のプランと下のプランとでは「転送量無制限」の意味が違うんじゃ
ないでしょうか。

> ...ってここまで書いて言うのもなんですけど、
> 普通どれくらいのデータ転送量があるのでしょう?
> いくら文字だけって言っても大勢が詰め掛ければ、
> 転送量は大きくなるんだろうし。

現状のトータルが672Kbytesだそうで。
まだ、検索エンジンやらブックマークやらリンクやらが張り替えられたりして
いない、というのもあるでしょうが、20Gの制限にはまだまだ余裕でオッケー、
という感じです。

しかし、今まではアクセスログが見られなかったのですが、見てみると
楽しいですね。~/essay/tsuru.htmlを読んでる人もいるのか、とか。


[620] 移転
返信


投稿者: 本多
2004/02/14 15:44

Mail:manybook@msc.biglobe.ne.jp   Link:
 どうでもいいことですが。

>サーバには、TwodotsNetのドメインプラン-プラスを使用しました。
この会社、色々プランがあるのですが、「ドメインプラン-プラス」という
プランにだけ、データ転送量に上限があるのですね。

以下、当該web siteより

> >データ転送量 月間20GB
> >※転送量を超過した場合、20GB〜40GBまで1GBあたり200円、
> >40GB以上は1GBあたり450円を別途ご請求いたします。
まぁ、(ぱ)さんのsiteは、映像音楽などの(ほとんど)ない文字中心のsiteですから
取り立てて問題はないんでしょうけど、
上から2番目のプランにだけ制限があるっていうのが激しく謎ですね(^^;)

...ってここまで書いて言うのもなんですけど、
普通どれくらいのデータ転送量があるのでしょう?
いくら文字だけって言っても大勢が詰め掛ければ、
転送量は大きくなるんだろうし。

頻繁に更新すると財布に負担がかかるという罠。


[619] Re: 若返りの秘薬とは
返信


投稿者: (ぱ)管理人モード
2004/02/09 19:01

Mail:   Link:
 この書き込みは明らかな広告なので削除しました。
 


[617] Re:mallocについて
返信


投稿者: (ぱ)
2004/02/08 15:00

Mail:PXU00211@nifty.ne.jp   Link:http://member.nifty.ne.jp/maebashi/
 > > > 確保したmemoryをfree()したら、
> > > すぐにallocateしたmemoryがsystemに開放されます。
> > でも小さな領域の確保には使えないのが難点です。
> あれ?これはどうしてですか?効率が悪いという意味ですか?
> 効率の悪さは確かにそのとおりですが
> 小さくても大きくてもmapmallocで確保できますよ?

mmap()は仮想記憶の仕掛けをアプリケーションが使うためのシステムコールの
ようなものですから、(4KBくらいの)ページ単位でしか確保/開放ができないはずです。
ですから、「mmap()を使用したmalloc()ライブラリ」は、小さな領域の要求に対し
毎度毎度mmap()を呼ぶわけではなくて、大きく取った領域を小売りしているはずです。

だとすれば、大きく取った領域の中にちょっとでもfree()されない領域があると
結局開放できないわけで、だからこそマニュアルに

| There is no reclaiming of memory.

とあるんだと思います。


[616] Re:mallocについて
返信


投稿者: 本多
2004/02/08 09:19

Mail:manybook@msc.biglobe.ne.jp   Link:
 > http://www.dimi.uniud.it/cgi-bin/man-cgi?mapmalloc+3MALLOC
> つまりアプリケーションがsbrk()呼んでるときは、普通のmalloc()を使うと
> かち合うのでこっちにしなさい、ってことですね。
> だとすると確かにmmap()「だけ」で実装しなければいけません。
なるほど、知らなかった。参考になります...
でもsbrk()を呼ぶようなapplicationが想像できませんが

> > でも、file system(/dev/nullだったかな?)をmmap()するとことで
> 今ならMAP_ANNONYMOUSが使えるかも。
実際、内部でどのようにしてるのかは知りませんが、
trussでsystem callを監視するとopen(/dev/null)+mmap()をしてるようでした。

> > 確保したmemoryをfree()したら、
> > すぐにallocateしたmemoryがsystemに開放されます。
> でも小さな領域の確保には使えないのが難点です。
あれ?これはどうしてですか?効率が悪いという意味ですか?
効率の悪さは確かにそのとおりですが
小さくても大きくてもmapmallocで確保できますよ?


[615] Re:mallocについて
返信


投稿者: (ぱ)
2004/02/08 04:34

Mail:PXU00211@nifty.ne.jp   Link:http://member.nifty.ne.jp/maebashi/
 > Solarisにはsbrk()の代わりにmmap()を利用したmalloc()を含む
> dynamic link libraryが標準で存在します(他のsystemは知りません)。

ちょっと調べてみました。
http://www.dimi.uniud.it/cgi-bin/man-cgi?mapmalloc+3MALLOC
| The routines in this library are intended to be used only
| if necessary, when applications must call sbrk(), but need
| to call other library routines that might call malloc. The
| algorithms used by these routines are not sophisticated.
| There is no reclaiming of memory.

つまりアプリケーションがsbrk()呼んでるときは、普通のmalloc()を使うと
かち合うのでこっちにしなさい、ってことですね。
だとすると確かにmmap()「だけ」で実装しなければいけません。

> でも、file system(/dev/nullだったかな?)をmmap()するとことで

今ならMAP_ANNONYMOUSが使えるかも。

> 確保したmemoryをfree()したら、
> すぐにallocateしたmemoryがsystemに開放されます。

ですね。
でも小さな領域の確保には使えないのが難点です。
でっかく取って小売する方針を取ると、ちょっとでも使われている限り
開放できないですし。
コンパクションができればいいんですが。


[614] Re:mallocについて
返信


投稿者: 本多
2004/02/06 14:53

Mail:manybook@msc.biglobe.ne.jp   Link:
 > > brk()/sbrk() を使わず、mmap() だけで実装した malloc() もありえると
> > 思います。
> ええと、ありえるでしょうし、あるのかもしれませんが、まああんまりないだろう、
> と認識してます。合ってますよね (^^;

Solarisにはsbrk()の代わりにmmap()を利用したmalloc()を含む
dynamic link libraryが標準で存在します(他のsystemは知りません)。

-lmapmallocをつけてcompileをすると、mmap()をしたmalloc()が利用できます。

sbrk()の代わりにmmap()を使っているmapmalloc libraryを利用すると
若干、実行時間が遅くなったはずです。

でも、file system(/dev/nullだったかな?)をmmap()するとことで
確保したmemoryをfree()したら、
すぐにallocateしたmemoryがsystemに開放されます。

temporaryに極端に大きなmemoryを確保する可能性がある
常駐するprogramで利用します。


[613] Re:mallocについて
返信


投稿者: (ぱ)
2004/02/05 22:18

Mail:PXU00211@nifty.ne.jp   Link:http://member.nifty.ne.jp/maebashi/
 > UNIX 用 malloc() の伝統的実装は brk() ないし sbrk() だけを使っていた
> わけですが、今では brk()/sbrk() と mmap() を併用している実装もあります。

はい。一応それは注を入れてます。

| 最近の実装では、場合によってmmap()(後述)を使うものもあるようですが、
| 小さい領域をmalloc()するときは、やはりbrk()を使用しているようです。

> brk()/sbrk() を使わず、mmap() だけで実装した malloc() もありえると
> 思います。

ええと、ありえるでしょうし、あるのかもしれませんが、まああんまりないだろう、
と認識してます。合ってますよね (^^;


[612] Re:mallocについて
返信


投稿者: kit
2004/02/05 21:16

Mail:   Link:
 > (2) メモリを取得する手段は、UNIXの場合brk()というシステムコールである。

余談です。

UNIX 用 malloc() の伝統的実装は brk() ないし sbrk() だけを使っていた
わけですが、今では brk()/sbrk() と mmap() を併用している実装もあります。
brk()/sbrk() を使わず、mmap() だけで実装した malloc() もありえると
思います。


[611] Re:mallocについて
返信


投稿者: (ぱ)
2004/02/05 00:18

Mail:PXU00211@nifty.ne.jp   Link:http://member.nifty.ne.jp/maebashi/
 > 一応全部読んでるんですけどね・・、brk()というシステムコールがあるというだけで、
> mallocから呼び出されるとは書いていなかったのでちょっと分からりずらかった・・。

うーん。すみません。

一応前段も引用すると、

| たいていの実装では、malloc()は、オペレーティングシステムから
| 一括して大きなメモリを取得し、それをアプリケーションプログラムに
| 「小売り」するようになっています。
| オペレーティングシステムからメモリを取得する手段はOSにより
| さまざまですが、UNIXの場合brk()というシステムコールを利用します。

(1) malloc()はオペレーティングシステムからメモリを取得する。
(2) メモリを取得する手段は、UNIXの場合brk()というシステムコールである。

ということで、malloc()がsbrk()を呼び出すということを意味している
つもりでしたが、わかりにくかったでしょうか。
確かに「小売りする」とか「システムコールを利用する」といった比喩的な
言い回しは、わかっている人同士ではよく使いますが、第三者に説明するには
わかりにくいかもしれませんね。

今後の参考にさせていただきます。


[610] Re:mallocについて
返信


投稿者: ishikawa
2004/02/04 21:06

Mail:   Link:
  > 呼んでいます(状況によって呼ばないこともありますが)。
> 「本」というのがポインタ完全制覇のことであれば、p.119で言及しています。
あ、そうですか、納得しました。
これのことですね。。
>オペレーティングシステムからメモリを取得する手段はOSによりさまざまですが、UNIX
>の場合brk()というシステムコールを利用します。
一応全部読んでるんですけどね・・、brk()というシステムコールがあるというだけで、
mallocから呼び出されるとは書いていなかったのでちょっと分からりずらかった・・。


[609] Re:mallocについて
返信


投稿者: (ぱ)
2004/02/04 19:16

Mail:PXU00211@nifty.ne.jp   Link:http://member.nifty.ne.jp/maebashi/
 > 今更かもしれませんが、本にmallocはシステムコールではないと書かれてありましたよ
> ね、それはmalloc内部の処理でもシステムコールは呼び出していないということですね?
> ちょっと気になったもので。

呼んでいます(状況によって呼ばないこともありますが)。
「本」というのがポインタ完全制覇のことであれば、p.119で言及しています。



[608] mallocについて
返信


投稿者: ishikawa
2004/02/04 18:47

Mail:   Link:
 今更かもしれませんが、本にmallocはシステムコールではないと書かれてありましたよ
ね、それはmalloc内部の処理でもシステムコールは呼び出していないということですね?
ちょっと気になったもので。


[607] Re:韓国語版
返信


投稿者: 本多
2004/02/03 07:38

Mail:manybook@msc.biglobe.ne.jp   Link:
 > 某掲示板でのおでんの話を拝見してました。
たまに(ぱ)さんも書き込んでいますよね。ばれてましたか。

> 私は韓国語はさっぱりですので、AMIKAIの翻訳エンジンにかましてみました。
私の訳したところはきれいに自動翻訳されるんですねぇ。(^^;)

> 翻訳できない部分をカタカナに開くんですね…
> 「ガングコムがゾックになってください」って何がなんだか。
そこは
「KangCom(site名)家族(会員というニアンスかな)になってください」
という意味です。

> ゾックなんて前後対称なだけで見掛け倒しであっというまにやられてしまって、
> でもメガ粒子砲はやたら強力なせいか近所のゲーセンじゃ対戦での使用が禁止
> されてたりするので、ガンダムがゾックになってもらっちゃ困ります←おぃ
またメタな話を...(^^;)
自動翻訳の場合、単語と単語の間に適切に空白を入れてあげないと
きれいに翻訳してくれないようです。
で、そういう場合仕方なく、読み方(に近い)カタカナに変換しちゃうんですね。


[606] Re:韓国語版
返信


投稿者: (ぱ)
2004/02/03 00:02

Mail:PXU00211@nifty.ne.jp   Link:http://member.nifty.ne.jp/maebashi/
 > そうだったんですか。韓国語版が出ていたんですか。
> さっそく...と言いたい所ですが、韓国から帰ってきてしまったので...

そういえば本多さんは韓国に行ってらしたんですね。
某掲示板でのおでんの話を拝見してました。

> ところでリンク先の本屋の書評にはこんなことが書かれてます。

翻訳ありがとうございます。

私は韓国語はさっぱりですので、AMIKAIの翻訳エンジンにかましてみました。

http://ocn.amikai.com/amiweb/browser.jsp?url=http%3A%2F%2Fkangcom.com%2Fcommon%2Fbookinfo%2Fbookinfo.asp%3Fsku%3D200212240004&langpair=9%2C2&c_id=ocn&lang=JA&toolbar=yes&display=2

翻訳できない部分をカタカナに開くんですね…
「ガングコムがゾックになってください」って何がなんだか。
ゾックなんて前後対称なだけで見掛け倒しであっというまにやられてしまって、
でもメガ粒子砲はやたら強力なせいか近所のゲーセンじゃ対戦での使用が禁止
されてたりするので、ガンダムがゾックになってもらっちゃ困ります←おぃ

> そういえば、韓国の翻訳本の印税も
> 為替レートによって上下するんですか?

少なくとも現時点では第1刷の分しか入ってきてないと思うので、
上下してるかどうかもよくわかりません。もともと発行部数が少ないですし、
訳者さんやら仲介エージェントやらの取り分が入るようで、
小遣い程度にしかなりませんし。
もっとも、翻訳本に関しては、私は何もしていませんから別に不満もないですが。


[605] 韓国語版
返信


投稿者: 本多
2004/02/02 12:37

Mail:manybook@msc.biglobe.ne.jp   Link:
 そうだったんですか。韓国語版が出ていたんですか。
さっそく...と言いたい所ですが、韓国から帰ってきてしまったので...

ところでリンク先の本屋の書評にはこんなことが書かれてます。

対象者:初中級
初級書が洪水を起こしているC言語図書市場において
中級以上の実力を積むための学習に適当な図書を渇望する読者たちの
渇きを癒してあげられる図書だ。

そういえば、韓国の翻訳本の印税も
為替レートによって上下するんですか?


[604] Re:C言語ポインタ完全制覇
返信


投稿者: (ぱ)
2004/02/01 00:00

Mail:PXU00211@nifty.ne.jp   Link:http://member.nifty.ne.jp/maebashi/
 > こんにちは、はじめまして。

はじめまして。

> 私はC言語を直接扱った本は、
> 「K&R初版(日本語)」と
> 「K&R2ndEdition(English)」ぐらいしかもっていませんでした。
> また、manを併用することで、特に不自由も感じていませんでした。

K&R初版をお持ちということは、相当なキャリアを積んでいる方ですね。
私は若輩者なので、後になって人から譲ってもらいました。

> でも、本屋でこの本に出会ったとき、正直言ってその面白さにハマリ
> ました...(^^;

ありがとうございます。そんなにほめても何も出ませんよ (^^;

> ところで、「このような切口での発想や説明ができるなんて、よほど
> 長いプログラム経験のある方なんだろう」と思いましたが...
>
> 私より、お若い方なんですね!

ですから単なる若輩者ですって (^^;
何かありましたらご指導ご鞭撻くださいませ。


[603] C言語ポインタ完全制覇
返信


投稿者: アヒル
2004/01/31 14:09

Mail:   Link:
 
こんにちは、はじめまして。

ちょっと自己紹介&書籍の感想です。

私はC言語を直接扱った本は、
「K&R初版(日本語)」と
「K&R2ndEdition(English)」ぐらいしかもっていませんでした。
また、manを併用することで、特に不自由も感じていませんでした。

(不可解なことや理解できないことは、前橋さんのように自分でいろ
いろと実験して、体でおぼえて来た口です。)

でも、本屋でこの本に出会ったとき、正直言ってその面白さにハマリ
ました...(^^;

斬新な切口と明解なサンプルプログラム!

私が、疑問に思いつつも結果として体で覚えてしまっていて、実験ま
ではしていなかったようなことまでが実にいろいろと満載で、無意識
の内に本を手に取りレジに並んでいました。

(無意識の内に本を手に取り、店を出てなくてよかったです。
→もちろん、冗談です!)

私にとっては、何年かぶりのC言語本の購入となりました。
面白くてためになる本を、ありがとうございました。

ところで、「このような切口での発想や説明ができるなんて、よほど
長いプログラム経験のある方なんだろう」と思いましたが...

私より、お若い方なんですね!

これからも、頑張ってくださいね!
では、


[602] Re:C言語 FAQ 日本語訳 復刊!
返信


投稿者: (ぱ)
2004/01/29 08:21

Mail:PXU00211@nifty.ne.jp   Link:http://member.nifty.ne.jp/maebashi/
 > いつも、楽しくHPを拝見させていただいてます。

はじめまして。ありがとうございます。

> そこでついに、C言語 FAQ 日本語訳がでました!(ご存知でした?)
> http://www.shinkigensha.co.jp/kinkan/

おおっ! これは!

知りませんでした。情報ありがとうございました。
さっそくリンク集に補足を入れさせていただきました。


[601] C言語 FAQ 日本語訳 復刊!
返信


投稿者: kon
2004/01/28 13:15

Mail:   Link:
 いつも、楽しくHPを拝見させていただいてます。
私が、C言語に目覚めさせてくれた本であるC言語ポインタ完全制覇
にはとても感謝しています。
(ポインタと配列等のあいまいだった頃がはずかしい・・・)

その影響か、前橋さんのHPのリンク集はすべて、チェックしています。
そこでついに、C言語 FAQ 日本語訳がでました!(ご存知でした?)

http://www.shinkigensha.co.jp/kinkan/

早速、買ってしまいました。
それではまた。


ひとつ前の過去ログ | 目次へ | ひとつ後の過去ログ