K.Maebashi's BBS

>手間と言えば手間なんですが、グローバル変数にするような >ものは、必ず初期化する趣味なので、GLOBAL みたいな簡単な >マクロでは対処できなかったりします (たとえ 0 や NULL で >初期化する場合でも、明示的に初期化するスタイルを採って >ます)。 GLOBAL char *hoge[] #ifdef GLOBAL_VARIABLE_DEFINE = { "foo", "bar", } #endif /* GLOBAL_VARIABLE_DEFINE */ ; とか書いたこともありますけどね (^^; >また、そもそもグローバル変数なんてほとんど使わないので、 >手間的にはたいしたことないです。 別レスで書きましたけど、実は私もそうです。 別レスで挙げたCLC_Interpreterのように、構造体にまとめて malloc()で領域を確保することが多いです。 # わかりにくいですがCLC_Interpreterはポインタでして、 # こういうふうにポインタがポインタでないかのようにtypedefするのは # よろしくないなあ、と今は思っています。当時はXtとかのスタイルを見て # かっこいいと思ってしまったわけですが。 ## clc_current_interpreterのようなものを静的に持ってしまうと ## リエントラントでなくなります。当時はマルチスレッドなんて ## そうそう使わないよね、と思ってたわけですが… ## まあ、リエントラントにしたい場合も、外部のインタフェースにだけは影響を ## 与えないようにしてあるからまあ許容範囲かと。 >昔風のプログラムなら >グローバル変数にする場合も、たいていは accessor/mutator >関数でラップして見かけは関数にしてしまうことがほとんど >です。 たとえばclc_current_interpreterは関数でラップされていませんが、 CLCモジュールの外から見えることもありません。 これはモジュールの粒度をどのくらいにするかという問題だと思いますが、 「関連の強いソースの集合体としてのモジュール」内(せいぜい数千行レベル)で あれば、この程度のカプセル化の侵食は許容範囲じゃないかなあ、 と私は思っています。 もちろん最初からgetter/setterを書いたからといってさしたる手間でも ないですけれど。

>http://kmaebashi.com/programmer/pointer.html >では GLOBAL int global_variable; を推奨されているようですが、私は反対です。 うーん。 GLOBALに反対する根拠として一番大きいのは、私としては 「Cの構文をねじ曲げるようなマクロはよろしくない」という原則に 反しているからじゃないかな、と思っています。 #define BEGIN { みたいなシンタックスのレベルで改変を入れるようなマクロは確かに いろんな意味でまずいでしょう。 >hoge.c の中で >#include "hoge.h" >int global_variable; >と書いても ISO 文法上何の問題も無いので。 これはそうですね。 >もし仮に hoge.c の中で >#define GLOBAL_VARIABLE_DEFINE >#include "hoge.h" >#include "piyo.h" >とかやっちゃうと hoge piyo 両方の大域変数が定義されてしまいます。 私のヘッダファイルの切り分け方からすると、 http://kmaebashi.com/programmer/c_yota/module.html hoge.h, piyo.hが共にプライベートヘッダファイルならどこかでまとめて #define GLOBAL_VARIABLE_DEFINEして#includeしますし、 piyo.hが別モジュールのパブリックヘッダなら、グローバル変数は公開しないので この問題は起きないんですね。 >わざわざ同一の記述を複数の個所で行なうのは間違いのもとである このメリットは一応それなりの説得力はあるかと思っています。 が、私が実際これをどう使っているかというと、たとえばここで 公開しているソースでは、 http://kmaebashi.com/programmer/c_yota/calc_html/calc.html #ifdef GLOBAL_VARIABLE_DEFINE #define GLOBAL #else #define GLOBAL extern #endif GLOBAL CLC_Interpreter clc_current_interpreter; これ一個だけ…　だったら必要ないじゃん、というのはもっともですね (^^;

> hoge.h の中では必ず > extern int global_variable; > と書くべきだと考えます。 僕も自分で一から書くソフトウェアでは、 GLOBAL のようなマクロは使わず、extern 宣言と、変数の 実体の定義と 2回書いてます。 手間と言えば手間なんですが、グローバル変数にするような ものは、必ず初期化する趣味なので、GLOBAL みたいな簡単な マクロでは対処できなかったりします (たとえ 0 や NULL で 初期化する場合でも、明示的に初期化するスタイルを採って ます)。 また、そもそもグローバル変数なんてほとんど使わないので、 手間的にはたいしたことないです。昔風のプログラムなら グローバル変数にする場合も、たいていは accessor/mutator 関数でラップして見かけは関数にしてしまうことがほとんど です。プロファイルとって効率が問題になるようだったら、 あとで実装をマクロに直すだけですから、最初からグローバル 変数として見せる必要があるとは思えません。逆に、最初は 変数で済んでいたものが、後になって変更時に手続きをフック したくなることは結構あります。(単に最初の仕様検討がいい 加減なだけだって話もありますが… ^^;) > globals.c とか作るのは個人的には嫌っています。 同じく globals.c みたいなものは作りません。 こういうのって、モジュール分けの原則に反してますよね。

　はじめまして、トルと申します。 　追加・削除する時は、分けると２箇所を修正する必要がありますから、分けない方が一箇所で済み、何かと楽ではないですか？ >globals.c とか作るのは個人的には嫌っています。 　私は嫌いではありませんよ。

発言数が少ないようなのでネタ振りなど。 http://kmaebashi.com/programmer/pointer.html では GLOBAL int global_variable; を推奨されているようですが、私は反対です。 hoge.h の中では必ず extern int global_variable; と書くべきだと考えます。 hoge.c の中で #include "hoge.h" int global_variable; と書いても ISO 文法上何の問題も無いので。 もし仮に hoge.c の中で #define GLOBAL_VARIABLE_DEFINE #include "hoge.h" #include "piyo.h" とかやっちゃうと hoge piyo 両方の大域変数が定義されてしまいます。 #undef GLOBAL_VARIABLE_DEFINE しますか？めんどくさいです。 ヘッダ中から別ヘッダを #include しているとそもそも分離不可能だし。 globals.c とか作るのは個人的には嫌っています。 >わざわざ同一の記述を複数の個所で行なうのは間違いのもとである こと自体は御意なのです。でも、 関数(原型)宣言と関数定義を両方書く必要があるなら、 大域変数の宣言と定義を両方書いても大差ないぢゃん、とか思う今日この頃。 皆様はどうお考えですか？

>「ハッカーと画家」、出版されるみたいですよ。 > >http://www.shiro.dreamhost.com/scheme/wiliki/wiliki.cgi?Shiro 　遅くなりましたが、情報提供ありがとうございます。 　Webで公開されている文書11本に、書き下ろしを4本加えた本ですか。 その11本がどれだかわからないのですが、この中からチョイスしたものなんですかね。 　http://www.paulgraham.com/articles.html 　翻訳されたものがWebで読めるのかわかりませんが、読めるのだとしたら、 やっぱりどうしても購入を躊躇してしまう…

こんにちは。 「ハッカーと画家」、出版されるみたいですよ。 http://www.shiro.dreamhost.com/scheme/wiliki/wiliki.cgi?Shiro ↑の、2004/9/30の箇所で査読者募集していました。

>ですよねぇ。あれだけ居た人々はいったいどこに行ってしまったのでしょうか。 ># Java人口自体は増えてると思うんですが……。 2chかなあ… それとも小さなコミュニティに分散したのか… これは私も不思議に思っていますので、ご存知の方、情報をお願いいたします(_o_)

>JavaHouse自体、最近はほとんど流量がないじゃないですか。 ですよねぇ。あれだけ居た人々はいったいどこに行ってしまったのでしょうか。 # Java人口自体は増えてると思うんですが……。 # 最近はどの案件もみ～んなJava。(おいらは異端のPerl屋さん^^;) >私が知っているところだと、Java読書会BOFくらいですかねえ。 情報ありがとうございます。一度入って様子を見てみます。 >JavaMailネタでしたら、木下さんもいますし。 そーいえばJavaMailの本の存在をどっかで見かけたよーな気がするなー、と思って 「JavaMail 木下」でぐぐってみたのですが……まだちゃんと中身確認してませんが、 この本とWebページみれば質問事項一通り解決しそーな予感が(^^; ぁぅぁぅ。 # 如何にJavaについて情報収集してなかったかとゆー……。

>JavaHouseに質問投げたら応答無し子さん(;_;)だったので JavaHouse自体、最近はほとんど流量がないじゃないですか。 アーカイブも復活しませんし。高木さんもすっかり投げてますよね。 というわけで >## それとも質問の仕方がマズかったのかなぁ……。 これはないと思います。 >他のところに聞こーかと思うんですが、どこか良さげな >ところありますでしょーか? 私が知っているところだと、Java読書会BOFくらいですかねえ。 http://www.iaj.or.jp/bukai/java/wg_bof/jfriends.html JavaMailネタでしたら、木下さんもいますし。

JavaHouseに質問投げたら応答無し子さん(;_;)だったので 他のところに聞こーかと思うんですが、どこか良さげな ところありますでしょーか? # 2ch?(^^; ## それとも質問の仕方がマズかったのかなぁ……。

>規格の6.2.1.5を見る限り、両辺の型が浮動小数点数でもlongでも >unsignedでもなければ、両オペランドがintに拡張されることになっています。 すいません。 テストする時、下記のようにpiyoに200を代入してました。 hoge = 100; piyo = 200; で、投稿する時に(手が勝手に？)piyoに100を代入して送ってしまいました。 お騒がせしてすいませんでした。 前橋さん、774RRさんありがとうございました。

LSI-C 86 試食版とか。 これは最近では数少ない non-ISO compliant な悪名高き処理系です。 もともと i8080 系のためのコンパイラとして開発されたため char と char の演算は char のまま行ってくれます。 っていうか README にその旨書いてあるので、理解し評価し納得した上で 使わないといけないのですが...

>表題の件ですが、どこかで「式の中ではchar型の変数は、int型に格上げされる」 規格の6.2.1.5を見る限り、両辺の型が浮動小数点数でもlongでも unsignedでもなければ、両オペランドがintに拡張されることになっています。 >オーバーフローせず、fooに10000が代入される。というような説明を >読んだ記憶があるのですが、いまやってみるとしっかりオーバーフローしてくれます。 というわけで私のところでも試してみましたが、 bcc32とgccの両方で、しっかり10000が代入されました(gccはLinux上、 gccに-Wallを付けた以外はどちらもオプションなし)。 すみませんが、tosさんが実験された処理系とコンパイルオプション、 および再現できる完全なソースコードを教えていただけませんか? ちなみに私はこんなソースで試しました。 #include <stdio.h> int main(void) { char hoge; char piyo; int foo; hoge = 100; piyo = 100; foo = hoge * piyo; printf("foo..%d\n", foo); return 0; }

皆さん、こんにちは。 表題の件ですが、どこかで「式の中ではchar型の変数は、int型に格上げされる」 というような説明を読んだような気がして、またそこで下記のような例で、 char hoge; char piyo; int foo; hoge = 100; piyo = 100; foo = hoge * piyo; オーバーフローせず、fooに10000が代入される。というような説明を 読んだ記憶があるのですが、いまやってみるとしっかりオーバーフローしてくれます。 「kmaebashi.com内」を検索して、「intより小さい整数型は、可変長引数で渡される ときには無条件でintに格上げされています。」との前橋さんの発言は見つかったのですが、上記のような説明はやはりありませんでした。 やっぱり記憶違いでしょうか? #でも、どっかで読んだような気がするのですが･･･。 #C FAQでもないみたいなんですよね。

はじめまして。 >はじめて納得がいきました。 どうもです。ほめていただき恐縮です。というかそこまでほめていただくと はずかしいです (^^; 更新が止まっておりましてすみません。 ログを見ると、「オブジェクト指向」で検索エンジンで探してうちのページに たどり着く人は結構いるようなので(検索キーワードとしては、hoge、 ポインタ、オブジェクト指向, PHP 掲示板、樹海あたりが多いです)、 ぼちぼちでも更新したいと思っているのですが。 ただ、この後、継承やインタフェースの話となると、結局普通の入門書と 同じような話になっちゃうのかなあ、という気もしています。 # あ、その前に、「PHPとMySQLで掲示板を作る」もさっさと書かないと…

オブジェクト指向がさっぱりわからず、本を読んだり掲示板をみたり いろいろなサイトをみたりしておりました。 すばらしいです！！！！ はじめて納得がいきました。 本当にありがとうございます（深々

> お客さんのとこに出張して 1時間くらいので、 > 大雑把にデータを整理して何かの資料を作りたいとか言う場合に > 手作業をほんのちょっと減らしたいなんて程度に使う分には > ザクザクッと作れちゃうperlみたいな形無し言語ってとても便利だと思いますが。 お客さんのとこに出張して、さくっとデータ変換しなきゃいけなかった時、 Perlはなく、AWKを使ったら、何しろ日頃使っていないものだからえらく 苦労した、という経験があります。客先じゃNUTS SHELLは落ちてないし、 当時はさくっとGoogleできる環境でもなかったですし。 やっぱり普段から使ってないといかんですねえ。

> 手作業をほんのちょっと減らしたいなんて程度に使う分には > ザクザクッと作れちゃうperlみたいな形無し言語ってとても便利だと思いますが。 実は、恥ずかしい話なんですが。。 僕は、多少なりとも自信を持って使える言語がCとJavaしかなかったりします。 前橋さんの「C言語体当り学習」で、タブをスペースに変換する サンプルコードがありましたが、いつもあんな感じで、CやJavaで 作業用のツールを書いてました。 で、最近になって、他の人達が、perlやrubyを使ってサクッと作っている様子 などを見て、「ひょっとして、壮大な時間の浪費をしているのでは？？」 と感じるようになったのでした。 # もちろん、決して無駄になったとは思ってませんけど。 > 色んな言語に触れて適材適所を身に付けたらベストでしょう。 > 何でもかんでもオブジェクト指向言語万歳じゃないと思うし ありがとうございます。励みになります。 よーし、がんばるぞ。

>でも、PerlならPerlの作者は、長年の経験を積んだ名うてのハッカーであるわけで。 >頭のいい人なら型無し言語でもいいのかもしれません。 なるほど。。 じゃあ、僕はダメかもしれないです（笑） しかも、 >私はと言えば、「この世の中に自分より信用できないものが他にあるかーっ」 >という横島クンの叫び(うろ覚え)に共感する側の人間です。 僕の場合、「自分より信用できないものが他にあるかー」と叫びつつ、 常に自分を甘やかしてしまう人間なので、なおのこと、強い型付けの 言語の方が向いてるかもしれませんね。 でも、やはり視野を広げるために、色々な言語も知っておかなきゃ、 とも思うのです。 # そもそも、CとJavaすら使いこなしてるとは言えなかったりしますけど。。

>>というのは、前橋さんの長年の経験が導き出した答えなんだなぁ、と。 >でも、PerlならPerlの作者は、長年の経験を積んだ名うてのハッカーであるわけで。 >頭のいい人なら型無し言語でもいいのかもしれません。 名うてでも頭よくもないですけど型なしでいいと思うときと言うと、 お客さんのとこに出張して 1時間くらいので、 大雑把にデータを整理して何かの資料を作りたいとか言う場合に 手作業をほんのちょっと減らしたいなんて程度に使う分には ザクザクッと作れちゃうperlみたいな形無し言語ってとても便利だと思いますが。 そういう場合って例外処理だのは、おかしかったら やりなおせばいいのでどうでもよくて、 ちょっと出力に怪しい部分があってもおかしなところだけ手で直せばいいや、 ざっくり結果出してくれやってな感じで使うにはperlって重宝しますよねぇ。 その場合でも型があっても邪魔にならないんじゃないかって言われると んー、どうなんでしょうねぇ。文字列→数値ってなことを 型を意識せずにチャキチャキして欲しいとき型は邪魔かなって思うんですけど。 必要に応じて必要な関数にだけ構造体のメンバを増やしたりとか 手軽にできるし。 #一番困るのはそんなプログラムの一人歩きだったりしますが。 しっかりと設計に時間がかけなくちゃいけない規模のプログラムや、 後でメンテナンスが必要になるようなプログラムには 当然型があるべきだというのは もちろん同意します。 っていうか、設計って型を決めることでは(暴論) っていうか、型さえキレイに決まっていたら後はなんとでもなると思うし(極論) >>今はまだ、色々な言語に触れてみたいなぁ、なんて思ってしまいます 色んな言語に触れて適材適所を身に付けたらベストでしょう。 何でもかんでもオブジェクト指向言語万歳じゃないと思うし。 10分ででっち上げなくちゃいけない場合なんかは。 ま、適材適所ってことで。

>というのは、前橋さんの長年の経験が導き出した答えなんだなぁ、と。 でも、PerlならPerlの作者は、長年の経験を積んだ名うてのハッカーであるわけで。 頭のいい人なら型無し言語でもいいのかもしれません。 結局、自分自身をどこまで信用できるか、という問題のように思います。 私はと言えば、「この世の中に自分より信用できないものが他にあるかーっ」 という横島クンの叫び(うろ覚え)に共感する側の人間です。

>あー懐かしいスレ。 >このスレが現役だった頃はム板も読んでたんですが、最近はさっぱりです。 このスレが現役だった頃、僕はまだ、プログラマじゃなかったです（笑） それで、思ったんですが、 >もちろん用途次第で、静的な型付けがない方がよい場合もあるかもしれません。 >でも私は嫌です。自由よりも犬の首輪が欲しい方なんで。 というのは、前橋さんの長年の経験が導き出した答えなんだなぁ、と。 それに比べると、僕はまだよちよち歩きを始めたばかりで、「あれに触れると 熱くてやけどする」だとか、「あれに近付くと噛みつかれる」だとか、 そういったことを経験してないから、いまいちわかっていないのかもしれません。 今はまだ、色々な言語に触れてみたいなぁ、なんて思ってしまいます。

>怪しいメールは朝4 ～ 6時に来るとムカつきますね。 >まだ眠た・・・いや、バッチでコケたかと思ってドキッとします。 うーんと。 徹夜作業中(監視中?)ですか? お疲れ様です。

>>あー、正直、定年間近なプログラマ(35才定年説が正しいとして)である >>私としては、ツールの使い方などは「隣の席の若い奴に聞く」というのが >>最近常態化しています。こんなこっちゃいかんとは思うんですが。 >うーん。そうですか。 >業務以外のグループで使っているような門外漢なツールならそれは >ありだと思うんですけど、 いやもちろんツールの使い方は知らなきゃいけないと思いますが、 最近の私のボケっぷりからすると、ちと人のことを言えた義理ではないなあ、と。 >VBできます、VC++できますとプロジェクトに入ってきたものの、 >プロジェクトにファイルを追加することができなかったり、 >ライブラリやインクルードパスの設定方法が解らない＋そうする意味が解らないとか、 >モジュールのプロパティ設定ウィンドウが消えて2時間悩んだ、 といっても、さすがにこれはどうかと思いますが。

いろいろあって週末は死んでました。 >と思ったら、↓こんなのを見付けました。 >http://pc.2ch.net/tech/kako/986/986355498.html あー懐かしいスレ。 このスレが現役だった頃はム板も読んでたんですが、最近はさっぱりです。 >ただ、個人的に使ってみるぶんには、型安全でない言語の方が色々できて >面白そうかな、なんて思ってしまいました。 もちろん用途次第で、静的な型付けがない方がよい場合もあるかもしれません。 でも私は嫌です。自由よりも犬の首輪が欲しい方なんで。

怪しいメールは朝4 ～ 6時に来るとムカつきますね。 まだ眠た・・・いや、バッチでコケたかと思ってドキッとします。

はじめまして。 >「不精する努力を惜しまない」人ですかねぇ。 そうですね。コンピュータが得意なことはコンピュータにやらせるのは重要ですね。 > 勤勉すぎる輩 その割に仕事を能率よくこなせるスクリプト言語は 「時間がないから」と言って勉強しなかったり・・・ # 雑談なら毎日30分以上こなせるようですが。:-p

連日徹夜は辛いですね。特に会社が自宅になっている人とか・・・ その上でスーツなんですからこの業界ちょっとどこかおかしいです。 私は徹夜を避けるために技術を磨くとします(^-^;) >- どこでもいつでも寝れる >- 何でも食える 連日徹夜だと嫌でもこの体質になれるかもしれません。 # そんな状態のことは考えたくもない！ ;-<

>あー、正直、定年間近なプログラマ(35才定年説が正しいとして)である >私としては、ツールの使い方などは「隣の席の若い奴に聞く」というのが >最近常態化しています。こんなこっちゃいかんとは思うんですが。 うーん。そうですか。 業務以外のグループで使っているような門外漢なツールならそれはありだと思うんですけど、 VBできます、VC++できますとプロジェクトに入ってきたものの、 プロジェクトにファイルを追加することができなかったり、 ライブラリやインクルードパスの設定方法が解らない＋そうする意味が解らないとか、 モジュールのプロパティ設定ウィンドウが消えて2時間悩んだ、 と言われてしまうと激しく萎えてしまいます・・・ >満足じゃないですが、最低限のレベルとしては、「そんなやり方は美しくない」 >といった意識を持っているかどうかですね。 ああ、なんとなく解るような気がします。 私も「もっと処理を端折れないかな」 「こうしたらメンテが楽かも」などと考えるようにしています。 # あとでメンテするのも自分ですしね。 >時間の都合などで美学を曲げるのはアリかもしれませんが(きっと後で後悔しますが)、 >最初からそれが通じない人がたまにいます。 お客が文句を言わないからうちの飯は「きっと」うまいんだろうと考えて 味付けを工夫しないでいるような下町の定食屋さんとでも言えば良いでしょうかね。 # 定食屋さんに恨みがあるわけではないです(^-^;) >また、ツールやミドルウェアに関して言えば、使い方を覚えるのも重要ですが、 >外部仕様から動作原理を推測する姿勢があるとよいんじゃないでしょうか。 >あるいは「俺だったらこう作る!」とか。 他人の作ったプログラムから内部動作を推測して勉強するってことですね。 ブラックボックスから明確にコードを想像するには ある程度以上は「プログラム」というものを理解していないとできない技ですし。 # ハード屋さんが解体したハードから回路を抜き取って勉強するのと一緒ですね。