K.Maebashi's BBS

> 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時間悩んだ、 と言われてしまうと激しく萎えてしまいます・・・ >満足じゃないですが、最低限のレベルとしては、「そんなやり方は美しくない」 >といった意識を持っているかどうかですね。 ああ、なんとなく解るような気がします。 私も「もっと処理を端折れないかな」 「こうしたらメンテが楽かも」などと考えるようにしています。 # あとでメンテするのも自分ですしね。 >時間の都合などで美学を曲げるのはアリかもしれませんが(きっと後で後悔しますが)、 >最初からそれが通じない人がたまにいます。 お客が文句を言わないからうちの飯は「きっと」うまいんだろうと考えて 味付けを工夫しないでいるような下町の定食屋さんとでも言えば良いでしょうかね。 # 定食屋さんに恨みがあるわけではないです(^-^;) >また、ツールやミドルウェアに関して言えば、使い方を覚えるのも重要ですが、 >外部仕様から動作原理を推測する姿勢があるとよいんじゃないでしょうか。 >あるいは「俺だったらこう作る!」とか。 他人の作ったプログラムから内部動作を推測して勉強するってことですね。 ブラックボックスから明確にコードを想像するには ある程度以上は「プログラム」というものを理解していないとできない技ですし。 # ハード屋さんが解体したハードから回路を抜き取って勉強するのと一緒ですね。

おはようございます。 >・現状に満足していない よりコンパクトに解決できるはずだ、と思うことは必要ですね。 納期があるのでそれだけに没頭できないという制約もありますので、 ある程度の妥協点は必要でしょうか。 >・仕事のレベルだけで満足していない 解決方法っていう視点では1番と同じですかね・・・？ 手段を手広くするには仕事で使う以外のプログラムを見ておいて、 ある程度の見聞を広げておくことも必要なような気がしてます。 >・コードを書くことが好き 私も好きです(^-^) >・書いたコードを読んで、「きれいだ」「洗練されている」と感じさせる 大昔のAS/400などで開発をした人はカラムの記述位置に制約があったので、 「綺麗に並んでること」＝「綺麗なコード」と思っている方がいますね。 # あのマシンで「確定」ボタンを押し忘れて何度泣いたことか。 それよりもパッと見で何をやっているかが判る & 解るコードのほうが 数倍も有益で綺麗で洗練されてると感じます。 >↓それから、ちょっと次元が違う話かもしれませんが、こんな記事を見付けました。 ありがとうございます。読んでみました。 感想は下のスレでまとめて。

>>↓それから、ちょっと次元が違う話かもしれませんが、こんな記事を見付けました。 >うちのリンク集にも「ハッカーと画家」が入っていたのでした。 両方読んでみました。（前者は続きもありました。） ハッカーは好奇心がより強い人って感じですね。 でも興味のないことには思った以上に無頓着というか(^-^;) >一般にプログラミングは、なんというかこう「センス」みたいなものが必要だ、 >というのはよくわかります。画家に通じるものもあるでしょう。 問題（対象）をどう捉えて表現するか、ってところもそうですね。 そう言えばプログラムのセンスってどんなものでしょうかね！？ 例えば、 　・問題切り分けのうまさ 　・コード表現の簡潔さ 　・解決方法をいくつも思いつく柔軟さ などが思いつきます。 >間違ったことならいくら綿密にやってもしょうがないですわな。 その上、間違っていることに気づかなかったりしてたら目も当てられない、と(^-^;) >でも、凄腕ハッカーだけを集めてプログラム開発が出来るなら結構ですが、 >実際にはそうはいかないので、大規模プロジェクトは(私のような)ボンクラを >前提としたものでなければならないと思います。 前橋さんがボンクラだったら私は一体・・・(T_T) ただ、働いてお金をもらってるって意識があれば、 他人におんぶに抱っこな人はそうそう見つからなくなると思います。 # コンパイルエラーの取り方すらしらないベテランPGさんもいますし・・・隣に。 ># だから型なし言語は大規模プロジェクトには不向きだと思う。 0パディングした文字列に+1されてハマったりしますね。 >ところで、凄腕ハッカーに個室を与えたら、ちゃんと仕事しますかね。 与えた仕事が終わっていればそれも良し、かもしれません。 それより会社の自販機とかエアコンをハッキングされて困ったりして。:-)