> しかし、人間誰しも他人に全く迷惑をかけずに生きていくことは出来ないわけで、
> 「受忍限度」というものがあるわけです。だから、程度のひどいものから優先的に
> どうにかしよう、というのは当然の発想だと思います。
程度のひどいものから優先的に対策して行くべきだというのはその
通りだと思います。
> この部分に同意していただけるのであれば、「携帯にケチを付けるより先に」という
> 優先度の付け方にも同意していただけるのではないかと思うのですが…
どちらかのうるささがもう一方を「はるかに」上回るのであれば、優先度に差をつける
べきでしょうが、そうでなければ優先度を同程度にするというのは、さほどおかしくは
ないと思いますが。
> 電車の中で私語は全面禁止、とおっしゃるのなら
> それもありかもしれませんが、通常の会話が良くて携帯だとダメ、とする根拠が
> わかりません。
前提なしに「電車の中での携帯はマナー違反」と言ったので、誤解を招いたかも
しれません。
私の立場は「通常の会話も携帯での会話も、うるさくないのであればして良い。
ただし、車内で携帯を使う必要性がないのに、携帯を使うような場合、
うるさくなってしまいがちなので、あまり好ましくない」というものです。
前の発言と思いっきり矛盾してるかもしれませんが、マナー違反というので
思い浮かんだケースが、不必要に車内で携帯を使う輩だけだったので、前の
ような書き方になりました。
> しかし、電車の中では携帯の電源を切れ、ということになると、
> 「電車に乗り遅れた。少し遅れます」とか、「待ち合わせ場所が変更になったよ」
> というような、電車の中でこそ伝えたい連絡すら出来なくなってしまいます。
> こんなバカな話があるかい、と私は思うわけですが、どうでしょうか。
このようなケースでは、別に携帯を使っても良いと思います。
> ペースメーカーを使っているような人こそ、緊急連絡用の携帯電話は欠かせないと
> 思うんだけどなー。
緊急連絡用の場合は明らかに例外でしょう。それと、普通の時に車内で携帯を使う
のが妥当かというのは別問題です。
こんばんは〜。
ちょっと目が覚めてしまったのでフラリとやってまいりました。
> 優先度の付け方にも同意していただけるのではないかと思うのですが…
私もこれは同意ですね。
元々の行動様式がこうである方は「携帯であろうがなかろうが」ですけど(^^;
> しかし、電車の中では携帯の電源を切れ、ということになると、
> 「電車に乗り遅れた。少し遅れます」とか、「待ち合わせ場所が変更になったよ」
> というような、電車の中でこそ伝えたい連絡すら出来なくなってしまいます。
これは少し微妙ですね。
都心では割と頻繁に電車が来ますので私は乗り遅れの際はホームで連絡を入れてます。
しかし、飛行機なりバスなりに乗り継いだりしないとならない場合、
先に乗り込んでから連絡しないと明らかにタイムオーバーになってしまいますね。
つまり電話内容の優先度（あるいは緊急度）の問題になるでしょうね。
> ペースメーカーを使っているような人こそ、緊急連絡用の携帯電話は欠かせないと
> 思うんだけどなー。
そうですね。携帯からナースコールレベルの119ができるといいかも。
例えば病院のみで配布する機種を作って救急アクセス用のボタンが使えればGoodかな。
と言うのも以前、急に症状が悪化して電話をかけたが喋れない状態の人が
いたずら電話扱いされて無視されたってことがありますしね。
# 普通に喋れる人間だけが119してくるもの、と思っているほうもアレですが。:-p
それに、特定の識別コードを送れるようにしておけば、
かかりつけの病院もすぐ特定できてスムースに運べますし、
応急処置をするために違う病院に入っても、
移送中にかかりつけの病院から情報をもらってアレルギーなどの情報ももらえますしね。
もちろん、月額の支払いは携帯電話会社（＋病院？）へどうぞ。
そこまで税金で賄うのは厳しすぎます。;-<
> こんにちは。
はじめまして。
>それによって携帯のうるささがどうでも良くなるわけではないでしょう。
それはそうです。
しかし、人間誰しも他人に全く迷惑をかけずに生きていくことは出来ないわけで、
「受忍限度」というものがあるわけです。だから、程度のひどいものから優先的に
どうにかしよう、というのは当然の発想だと思います。
> >傍若無人なおばちゃんとか酔っ払いとかガキのわめき声とかの方が、
> >携帯よりずっとやかましいと思うんだが。
> これには同意しますが、
この部分に同意していただけるのであれば、「携帯にケチを付けるより先に」という
優先度の付け方にも同意していただけるのではないかと思うのですが…
> 私は、電車内などで携帯を使うのも、大きな声で会話するのも、うるさいという点で、
> 同様にマナー違反だと思います。
同様に、ではなくて程度の問題です。電車の中で私語は全面禁止、とおっしゃるのなら
それもありかもしれませんが、通常の会話が良くて携帯だとダメ、とする根拠がわかりません。
まあ、携帯でも、でかい声で延々と話し続ける輩はいますからね。
そういう連中は時としてガキんちょよりもやかましいかもしれません。
しかし、電車の中では携帯の電源を切れ、ということになると、
「電車に乗り遅れた。少し遅れます」とか、「待ち合わせ場所が変更になったよ」
というような、電車の中でこそ伝えたい連絡すら出来なくなってしまいます。
こんなバカな話があるかい、と私は思うわけですが、どうでしょうか。
ペースメーカーを使っているような人こそ、緊急連絡用の携帯電話は欠かせないと
思うんだけどなー。
こんにちは。
2003/6/22の日記の「電車の中で携帯電話」ですが、
>携帯以外の会話はうるさくないと?
>傍若無人なおばちゃんとか酔っ払いとかガキのわめき声とかの方が、
>携帯よりずっとやかましいと思うんだが。
これには同意しますが、
>携帯にケチを付けるより先に、小学生以下のガキからは大人の3倍の料金を
>取るべきなんじゃないか。行楽シーズンの電車なんかもう地獄だよ。
この論理はさすがにどうかと思います。おばちゃんとか酔っ払いなどがうるさい
からといって、それによって携帯のうるささがどうでも良くなるわけではないでしょう。
私は、電車内などで携帯を使うのも、大きな声で会話するのも、うるさいという点で、
同様にマナー違反だと思います。
> まったく同感です、はい。私も常々このように主張してます:-)。
どうもです。
ひとつ忘れてたのは、携帯電話は補聴器のノイズの原因になるらしいってこと。
以前2chのスレで読んで、実際どんなもんなんかなあと思って検索してみたんだけど、
具体的にどんな距離でどの程度のノイズが入るのかよくわかりません。
「携帯電話 補聴器」でGoogleする限りでは、「補聴器装着者本人が電話する
ときには、ノイズが問題になる」というレベルの話のように思えます。
確かに満員電車なら携帯持った他の乗客と密着することもありますから、
そういう時には迷惑をこうむることもあるんでしょう。
ペースメーカーも、14cmくらいの距離では誤作動を起こす機種がたまには
あるようですから、ギチギチの満員電車では電源を切るべきなんでしょうね。
# とはいえ全員が切り忘れないことを期待するのはやっぱり無謀だと思う。
表の掲示板の書き込みがさっぱり振るわないので…
元質問者の人はどっか行っちゃいましたけど。
> もし正しくエラーがとれているなら、この原因は、
> - 誤って fclose(stdin) あるいは close(0) などを行ってしまっている。
> か、
> - メモリを破壊しており、stdin のファイルディスクリプタ番号を保持して
> いる部分にゴミが入っている
> ということになると思います。
そうなんですが、これ、どっちも確率的には低いように思います。
stdinをfclose()って… 昔256倍本でそんな話があったような気はしますが…
だからまず疑うべきは「正しくエラーがとれている」かどうかだと思うわけです。
もし正しくエラーがとれているなら、この原因は、
- 誤って fclose(stdin) あるいは close(0) などを行ってしまっている。
か、
- メモリを破壊しており、stdin のファイルディスクリプタ番号を保持して
いる部分にゴミが入っている
ということになると思います。
いずれにせよ、答は
> 原因があるとすれば、これより前の部分です。
になるわけですが。
> なんか、(ぱ)さんの書き込み時間が朝方なんですけど...
いや、これはたまたま早く帰ったら20:00頃に寝ちゃって、目がさめたら午前1時で、
フロ入ってネットをうろうろしてた時に書いたレスなんですが (^^;
結局その後寝付けなくて、やっぱり寝不足で会社行くことになって、
翌日も早く帰ってちょっと寝そべった途端に寝ちゃって今度は朝まで目がさめなくて
やけにたっぷり睡眠をとったりしちゃってます。まあ累積の寝不足があるから
こういう状況になるというのは確かなんですけれども。
返答いただき、ありがとう御座いました。
なんか、(ぱ)さんの書き込み時間が朝方なんですけど...
私も経験ありますが、徹夜は翌日体に来ます。
あまり無理をなさらないよう、体に気をつけて下さい。
それではまた。
> ただ、strncpy(dest, src, len)はdest[len]に書き込まないのに、
> my_strncpy(dest, src, len)はdest[len]に書き込むというのは、整合性が取れて
> いないような気がします。
それもわかりますけど、strncpy()はとにかくlen文字コピーしますが、
dest[len-1]='\0'だとlen-1文字しかコピーしませんよね。
いずれにしても、lenを文字数ではなくdestのサイズだと考えるなら、
引数名はlenではなくdest_sizeとかにした方がよさそうです。
> if(fgets(b, (int)sizeof(b),stdin)!=NULL) {
> ・
> ・
> ・
> }
...
> ちなみに、同様の処理（配列名だけ違う）を違うところでやっているのですが、
> そちらは期待通り入力待ちになります。
同様の処理を違うところでやっていて、そちらは期待通り動くなら、
このコード自体には問題がない、と考えるのが普通ではないですか?
問題がないであろうコードだけを貼られても誰も答えられないでしょう。
原因があるとすれば、これより前の部分です。
# 実のところCの場合「よくないコードでもたまたま動く」こともありますが...
> fgets関数にて入力待ちを期待していますが、入力待ちになりません。
なんだかものすごーくありそうなケースとして、ここより前に
scanfを使っている、というのが考えられますが、
> 現象として、fgets関数が入力待ちにならずにエラー（NULLを返す）となっています。
NULLが返ってきているなら違いますかね。
> また、fgets関数直後でエラーコードを取ってみると、
> 「Bad file descriptor」
> となって、これは何を言っているのかもわかりません。
エラーメッセージをそのまま解釈すると、変なファイルディスクリプタを渡してる、
ということになりますが、stdinを壊すという状況はあまりなさそうな気がするので、
現象を正確に把握できていない可能性があるように思います。
どのような実験の結果先のポストのような推測を得たのか、もう少し具体的に
書いてもらえませんか?
> 1054635476っていつからの時間なのでしょうか?
man clock_gettime でマニュアル表示出ませんか？
UNIX Epoch からの積算秒です。
UNIX Epoch は 1970/1/1 00:00:00 (GMT) ですね。
32bit signed long MAX である 2147483647 秒を加えると 2038 年。
2000年問題の時に話題になったはずなのですが... もう目前。
> % gcc timetest.c -o timetest -O2 -Wall -lrt
> という感じにしてください。
家のパソコンにVine Linuxを入れてやってみたらできました。
ところで、tm.tv_secが秒でtm.tv_nsecがナノ秒ですよね?
Pen3 600MHz + Vine Linux 2.6の環境で実験すると以下のようになるのですが
これはどういうことなのでしょうか?
1054635476.752918000
プログラムは次のとおりです。
--------
#include<stdio.h>
#include<time.h>
int main(void)
{
struct timespec tm;
clock_gettime( CLOCK_REALTIME , &tm );
printf("%ld.%09ld\n",tm.tv_sec, tm.tv_nsec);
return 0;
}
--------
1054635476っていつからの時間なのでしょうか?
> p.301の説明も、「len文字だけコピーする。後ろは切れても構わない」という用途だと
> 書いてあります。ここでlenをバッファサイズと考えると、コピーされるのは
> len-1文字なので、かえって説明と矛盾しそうです。
確かにその様に書いてありますね。見落していました。ここでのmy_strncpy()の仕様は
「len文字だけコピーする。後ろは切れても構わない」というものですので、
このままで問題ありませんね。
ただ、strncpy(dest, src, len)はdest[len]に書き込まないのに、
my_strncpy(dest, src, len)はdest[len]に書き込むというのは、整合性が取れて
いないような気がします。
要求された仕様を満しているという点では何ら問題ありませんが、その仕様が
ちょっと変だな、と思うのですが、どうでしょう?
なんか表にも裏にもポストしていますが、
あなたはVBのサイトでも似たようなことしていますよね。確か。
できれば裏のはちゃんと消しておいたほうが良いかと思います。
> 「Bad file descriptor」
これはファイル記述子が不正になっているんでしょう。
前後の処理で壊したりしていませんか？
# stdinを壊すなんて恐ろしいですが・・・
> ちなみに、同様の処理（配列名だけ違う）を違うところでやっているのですが、
> そちらは期待通り入力待ちになります。
このfgetsが2回目で1回目の入力の食べ残しをそのまま入力している可能性がありますね。
教えてください！
環境は、Linux（ソースはC言語）なのですが下記のようなソースがあります。
char b[8];
if(fgets(b, (int)sizeof(b),stdin)!=NULL) {
・
・
・
}
fgets関数にて入力待ちを期待していますが、入力待ちになりません。
現象として、fgets関数が入力待ちにならずにエラー（NULLを返す）となっています。
また、fgets関数直後でエラーコードを取ってみると、
「Bad file descriptor」
となって、これは何を言っているのかもわかりません。
ちなみに、同様の処理（配列名だけ違う）を違うところでやっているのですが、
そちらは期待通り入力待ちになります。
どなたかご教示お願い致します。
> > 返答ありがとう御座います。是非参考にさせていただきます。
> > 「無理矢理インヘリタンス」で言うところの、get_property_instance とかで
> > 実装できるかな、と思ってます。
> > (つまりフレームワークによる機能提供と、クラスディスクリプタの実装です)
>
> ところで素朴な疑問なんですが、
うへ。何か書きかけてそのまま送信してしまいました。この部分は無視してください。
> 返答ありがとう御座います。是非参考にさせていただきます。
> 「無理矢理インヘリタンス」で言うところの、get_property_instance とかで
> 実装できるかな、と思ってます。
> (つまりフレームワークによる機能提供と、クラスディスクリプタの実装です)
ところで素朴な疑問なんですが、
> ところで私はJavaは全然知らないんですが、そもそもリフレクションというのは
> 頻繁に使用される機能なんでしょうか。
どうでしょうか。リフレクションでフィールド(メンバ変数)を書きかえるようなことは、
そこはそれオブジェクト指向言語であるJavaのこと、カプセル化の破壊になりますので
やらないと思いますが(というかメンバがprivateならやろうと思っても出来ませんが)、
メソッドをリフレクションを使って呼び出すことは、ちょくちょくあるように思います。
JavaBeansなんかは、リフレクションを前提にしていますし。
コンポーネントを疎結合で組み合わせようとすると、リフレクションによるメソッドの
呼び出しは必須のように思います。
# しかし、現実問題、なんだかわからんオブジェクトのメソッドを呼び出しても
# なんだかわからんことにしかならないような気も。
# マウスで線でつないでいくような開発環境って、結局いまいち普及してないですよね…
> ここのmy_strncpyは、そういうものを想定していました。
> …と、ここまで書いて、気になって確認してみました。そう考えるのだとすると、
> p.301の記述と矛盾するように思います。
> strncpy()の代用品という位置付けからしても、[len-1]にしておいた方が
> よさそうですね。後で正誤表に入れておきます。
…と書いてしまいましたが、あらためて確認すると、やっぱり今のままで
問題ないように思います。
strlenが「文字数」を返すように、my_strncpy()が(バッファサイズでなく)
「文字数」を引数に取っても変ではないでしょうし、
p.301の説明も、「len文字だけコピーする。後ろは切れても構わない」という用途だと
書いてあります。ここでlenをバッファサイズと考えると、コピーされるのは
len-1文字なので、かえって説明と矛盾しそうです。
どうでしょうか?
返答ありがとう御座います。是非参考にさせていただきます。
「無理矢理インヘリタンス」で言うところの、get_property_instance とかで
実装できるかな、と思ってます。
(つまりフレームワークによる機能提供と、クラスディスクリプタの実装です)
ところで私はJavaは全然知らないんですが、そもそもリフレクションというのは
頻繁に使用される機能なんでしょうか。
> 皆さんはじめまして、エイトと申します。
はじめまして。
> "無理矢理インヘリタンス"の章でリフレクションの実装を追記されてますが
> メンバの名前を文字列で外部ヘッダに公開し、同時にオフセット対応表にも
> 載せる事で外部からオブジェクトの参照を可能にする事と理解しています。
そうですね。「メンバの名前を文字列で外部ヘッダに公開」することは必須では
ないと思いますが、XtVaSetValues() のようなことをしようとすると必要に
なりますし。
> しかし、そのオブジェクトの型の種類分、参照する為の関数を用意する必要が
> あると思うんです。
そう思います。また、型を問い合わせる関数も必要です。
Type get_member_type(Core *obj, char *member_name);
int get_int_member(Core *obj, char *member_name);
char *get_string_member(Core *obj, char *member_name);
...
こんな感じでどうでしょうか。あるいは型を表現する列挙型と、なんでも入る
共用体をセットで返すとか。その方法は、要するに↓と同じですね。
> （Member構造体を渡し、渡されたほうでMember内Typeを見て処理分岐するとか）
列挙型Typeに許される型だけではなくてメンバに任意の型を許したければ、
メンバ名、オフセットのほかにサイズも保持して、
void get_member(Core *obj, void *buf);
のようにすれば可能かと思います。
しかし、この場合、取り出す人はこのオブジェクトを知っていることが前提になるので、
それぐらいなら最初からアクセサ書けよ、とも思います。
> 学校のSolarisで実験してみたのですが、clock_gettimeは未定義ですみたいなエラーが出てきます。
あ、ごめんなさい。compileのときに、-lrtというcompile optionをつけてください。
説明が不足してましたね。
% gcc timetest.c -o timetest -O2 -Wall -lrt
という感じにしてください。
# 正確なcompile errorの内容がわからないのですが、まず間違いないと思います。
# real time libraryに入っているので、
# librt.soをdynamic linkの対象にしなくてはならないのです。
# ...という大雑把な説明でわかるかなぁ?
> 以下のような書き方はだめなのでしょうか？
OKだと思いますよ。
> UNIXでは time.hをincludeすれば、使えると思いますが、
> time.hをincludeしても使えないようなら、ダメなのかもしれません。
> 私はSolarisとlinuxとcygwinではcompilerを持っていますが、
> WINDOWS用のcompilerを持っていないので、Windowsの事情がわからないんです。
> すいません。
学校のSolarisで実験してみたのですが、clock_gettimeは未定義ですみたいなエラーが出てきます。
以下のような書き方はだめなのでしょうか？
---------------------
#include<stdio.h>
#include<time.h>
int main(void)
{
struct timespec tm;
clock_gettime( CLOCK_REALTIME , &tm );
printf("%ld , %09ld\n", tm.tv_sec , tm.tv_nsec );
return 0;
}
---------------------
> > > Pentiamで、ある程度 高精度に時間を測れる関数の作り方です。
> > > とりあえず、linuxとcygwinでは動作するようです。
> > アセンブラの部分が良く分からないのですが頂いておきます。
> > ありがとうございます。
> 実を言うと私もよくわかってません...(^^;)
> CPUのことをよく調べないとこのあたりは把握するのは難しいでしょうね。
>
> ところで、Windowsでもちゃんと動作しましたか?
はい、windows2000 + MinGW 2.0.0できちんと動きました。
> > > # POSIX準拠の関数(のはず)だからUNIXなら間違いなく使えると思うのですが、
> > > # Windowsだと...使えないのかなぁ?
> とりあえず、timeと名前がついているヘッダーファイルをインクルードしてみましたが、
> どうも使えないようです。
> (gthr-posix.hというのもあったのですが、なぜかパスを指定しても見つけてくれない）
> どのヘッダーファイルをインクルードすれば使えるようになるのでしょうか？
UNIXでは time.hをincludeすれば、使えると思いますが、
time.hをincludeしても使えないようなら、ダメなのかもしれません。
私はSolarisとlinuxとcygwinではcompilerを持っていますが、
WINDOWS用のcompilerを持っていないので、Windowsの事情がわからないんです。
すいません。
> > Pentiamで、ある程度 高精度に時間を測れる関数の作り方です。
> > とりあえず、linuxとcygwinでは動作するようです。
> アセンブラの部分が良く分からないのですが頂いておきます。
> ありがとうございます。
実を言うと私もよくわかってません...(^^;)
CPUのことをよく調べないとこのあたりは把握するのは難しいでしょうね。
ところで、Windowsでもちゃんと動作しましたか?
> typedefでの型隠蔽は、
> ライブラリを作成していて当初の見積もりではビットが足りない、って
> なった場合にはヘッダ直してリコンパイルで済むので便利ですね。
typedefで整数型の変数を型隠蔽したときはprintf()用の型変換文字列macro(?)も
常に用意して欲しいですね。
例えば、stdint.hには、int16_t,uint16_t,int32_t, uint32_t
という型がtypedefされています。
各systemで16や32bitの整数型に適切にtypedefされているものなのですが、
これらにはそれぞれ対応するPRId16, PRId32という文字列をdefineしています。
例えば、
typedef long int32_t;なら、PRId32は"ld"と定義されているし、
typedef int int32_t;なら、PRId32は "d"になってます。
これは、int32_t型の変数をprintf()するときには、
printf(" val32 = %08" PRId32 "\n", val32);
ってやれば、型が違うという警告を受ける心配がありません。
clock_tに対するこういうmacroってありましたっけ?
clock_tがlongかどうかをheaderから調べてきて、
%ldにするか、%dにするかを選択するって言うのは
製作者(?)が少し不親切の様に思えますね。
# PRId32というのを挿入するのが見やすいかというと...(^^;)
皆さんはじめまして、エイトと申します。
中〜上級者向けで現場で活用できる具体的な開発手法が明記されている本なり
文章が以外と少ない事から、前橋さんのHPは大変勉強になります。
掲題の件について、ご教授ください。
"無理矢理インヘリタンス"の章でリフレクションの実装を追記されてますが
メンバの名前を文字列で外部ヘッダに公開し、同時にオフセット対応表にも
載せる事で外部からオブジェクトの参照を可能にする事と理解しています。
しかし、そのオブジェクトの型の種類分、参照する為の関数を用意する必要が
あると思うんです。
そのオブジェクトの型がintでもchar*でもstruct*でも共通の関数でオブジェクトを
渡すとか、このあたりを処理する方法についてどのようにお考えか
教えていただきたいです。
（Member構造体を渡し、渡されたほうでMember内Typeを見て処理分岐するとか）
過去ログは一通り読んだんですが、もし過去に同様の記述がありましたら
ご容赦ください。
以上です。
どうぞよろしくお願いいたします。
typedefでの型隠蔽は、
ライブラリを作成していて当初の見積もりではビットが足りない、って
なった場合にはヘッダ直してリコンパイルで済むので便利ですね。
ライブラリの仕様がコロコロ変わるM$向けのものと言えましょう。:-p