コーディング規約について
OKAMURA Kikuo
変数の初期化に関していろいろな意見が出ています。
何かしらのバグに対応することも含めて「コーディング規約」とするのはなん
か違う気がします。私の考える「コーディング規約」とは、「C言語の自由度
を、誰が表現してもある程度同じようになるように規約する。」と理解してい
ました。
ということで、「コーディング規約」ってなに？
--
OKAMURA Kikuo mailto:gf4k...@asahi-net.or.jp
Yoshiki Kataoka
「* ではなく [] と書け」
「auto 変数１つ作るたびに上司の承認が必要」
「ポインタ変数は p で始まること」
「各行に最終更新者のIDを記入せよ」
などなど、各社いろいろあるようですね。
社のルールに異論があるときに
とるべき行動といえば？？
これはコーディング基準に限ったことでは
ないですね。
会社から現場を預かっている担当者として、
または会社と労使契約を締結している人格として、
どちらにしても当事者意識を持って
ベストを尽くすことが大事だと思います。
Kusakabe Youichi
<kat...@ka2.so-net.ne.jp> wrote:
> 「* ではなく [] と書け」
> 「auto 変数１つ作るたびに上司の承認が必要」
> 「ポインタ変数は p で始まること」
> 「各行に最終更新者のIDを記入せよ」
> などなど、各社いろいろあるようですね。
より合理的なルールでoverrideする、では?
(それしかやったことないけど)
4つめは実際に出くわしたことがありますねー
ルールを変更するまで(って1日間ですが)の間は、
触ったファイルの全部の行を変更し(空白1つ変えただけの行もあったけど)、
全部の行に自分のIDとタイムスタンプを入れました。 (しかもIDは「void」だった
り
するので何のコメントかわかりづらい)
> 会社から現場を預かっている担当者として、
> または会社と労使契約を締結している人格として、
> どちらにしても当事者意識を持って
> ベストを尽くすことが大事だと思います。
この4行はほとんど意味のあることを言ってませんね(情報量0)。
ヘ_ヘ ____________________________
ミ・・ ミ vo...@merope.pleiades.or.jp
( ° )～ 日下部陽一
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hideo Sir MaNMOS Morishita
In article <void-27040...@newshost.ryukyu.ad.jp>,
vo...@merope.pleiades.or.jp (Kusakabe Youichi) writes:
> In article <9c92d4$58h$1...@news01dd.so-net.ne.jp>, "Yoshiki Kataoka"
> <kat...@ka2.so-net.ne.jp> wrote:
> > 「* ではなく [] と書け」
> > 「auto 変数１つ作るたびに上司の承認が必要」
> > 「ポインタ変数は p で始まること」
> > 「各行に最終更新者のIDを記入せよ」
> > などなど、各社いろいろあるようですね。
> > 社のルールに異論があるときにとるべき行動といえば??
>
> より合理的なルールでoverrideする、では?
> (それしかやったことないけど)
>
> 4つめは実際に出くわしたことがありますねー
> ルールを変更するまで(って1日間ですが)の間は、
> 触ったファイルの全部の行を変更し(空白1つ変えただけの行もあったけど)、
> 全部の行に自分のIDとタイムスタンプを入れました。 (しかもIDは「void」だった
> り
> するので何のコメントかわかりづらい)
これって、cvsを使っていたら、全く必要のないことですよね。ツールででき
る仕事をわざわざ人間がやるのって愚の骨頂のような。
３番目は「変数名はハンガリアン記法」って形で見たことあります。
＃ハンガリアン記法って今一つ分かりにくい。
--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 ＭａＮＭＯＳ 英夫＠ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37
とほほ
> 変数の初期化に関していろいろな意見が出ています。
> 何かしらのバグに対応することも含めて「コーディング規約」とするのはなん
> か違う気がします。私の考える「コーディング規約」とは、「C言語の自由度
> を、誰が表現してもある程度同じようになるように規約する。」と理解してい
> ました。
元投稿者の方の質問から、ちょっとはずれているかもしれませんが・・・・・
私は、この「コーディング規約」の規定の一つ、少なくても"｛"のインデントなど
の制御構造の規定こは、意味がないと思っています。
なぜなら、Ｃソースの整形プログラムが、UNIXベースであれWindowsベースであれ
多数ありますので、それを使えば他人のソースであっても、ある程度自分の好みのス
タイルに整形できるからです。
むしろ、スタイルの完成した人に他の人のスタイルに合わせることを強要すること
は、無駄な労力を強いて、バグ検出の機会を増やし、また埋め込む機会を増やすよう
な気がしてなりません。
また、どのスタイルを選ぶかということも、言語の習熟度と関係しています。 例
えば、"++i"などと演算子と項との間にブランクを置かない記述と、"++ i"とを置く
記述とでは、"++"という強結合の１項演算子の理解度を反映した結果となっていま
す。
こういったことを無視して、"万人が同じスタイルでコーディングしろ"という
「コーディング規約」なるものは、私は好きではありません。
なぜ世間では、コーディング・スタイルなんかよりも、解法表現スタイルの方を重
視してくれないのでしょうか？ この形式の問題には、こういった解法（＝アルゴリ
ズム）があり、この解法を適用するのがベストだとかいうような・・・・。
解法に対する一般的な表現（＝コーディング）の提言という意味での「コーディン
グ規約」というのであれば、私はそれを否定しません。
「コーディング規約」なるものについては、いろいろ言いたいことがあります。
--
とほほ
Go Watanabe
toh...@zxmail.comさんは書きました。
>
> 私は、この「コーディング規約」の規定の一つ、少なくても"｛"のインデントなど
>の制御構造の規定こは、意味がないと思っています。
>
> なぜなら、Ｃソースの整形プログラムが、UNIXベースであれWindowsベースであれ
>多数ありますので、それを使えば他人のソースであっても、ある程度自分の好みのス
>タイルに整形できるからです。
> むしろ、スタイルの完成した人に他の人のスタイルに合わせることを強要すること
>は、無駄な労力を強いて、バグ検出の機会を増やし、また埋め込む機会を増やすよう
>な気がしてなりません。
cvsなどのシステムは整形と改変の区別ができません。
そういったシステムを使おうとする限り、スタイルの統一は必須です。
もっとインテリジェントなシステムが今後登場してきたら
状況はかわるかもしれませんね IBMのJava統合環境とかがそんなかんじですし、
MSの統合環境もソースを常時解析した状態で保持してるし、素地はできてると
思いますが、統合環境の常でエディタが専用のものになる(その上カスタマイズに
限界あり)という「好み重視」に対する最大の障壁が…
> なぜ世間では、コーディング・スタイルなんかよりも、解法表現スタイルの方を重
>視してくれないのでしょうか？ この形式の問題には、こういった解法（＝アルゴリ
>ズム）があり、この解法を適用するのがベストだとかいうような・・・・。
> 解法に対する一般的な表現（＝コーディング）の提言という意味での「コーディン
>グ規約」というのであれば、私はそれを否定しません。
コーディングスタイルの統一のほうが、すくなくとも現時点ではより
現実的、ということでしょう。
--
渡邊剛 (Watanabe,Go) g...@dsl.gr.jp / g...@denpa.org
Kusakabe Youichi
"Sir MaNMOS" Morishita) wrote:
> > 4つめは実際に出くわしたことがありますねー
> > ルールを変更するまで(って1日間ですが)の間は、
> > 触ったファイルの全部の行を変更し(空白1つ変えただけの行もあったけど)、
> > 全部の行に自分のIDとタイムスタンプを入れました。 (しかもIDは「void」だ
った
> > り
> > するので何のコメントかわかりづらい)
>
> これって、cvsを使っていたら、全く必要のないことですよね。
> ツールでできる仕事をわざわざ人間がやるのって愚の骨頂のような。
実際にはその日のうちに全員にRCSを使わせるようにしたわけです。
(当時cvsがなかったので)
Kusakabe Youichi
rote:
> 私は、この「コーディング規約」の規定の一つ、少なくても"｛"のインデントな
ど
> の制御構造の規定こは、意味がないと思っています。
意味はありますよ。
カーニハンもそう言ってますし ;)
(ってひとのせいにするなって)
> 例えば、"++i"などと演算子と項との間にブランクを置かない記述と、
> "++ i"とを置く記述とでは、
> "++"という強結合の１項演算子の理解度を反映した結果となっています
いいえ。
ただの「後者は問題外」なだけでは?
とほほ
> > "++ i"とを置く記述とでは、
> > "++"という強結合の１項演算子の理解度を反映した結果となっています
>
> いいえ。
> ただの「後者は問題外」なだけでは?
上の例では、"++ i"とか書くひとが、結構いるんすよね ・・・ このよう人が、
「コーディング規約」なるものを作成しているプロジェクトもまた少なくない、とい
う現状があります。
＃とにかく、へんな規約が多すぎる！！
--
とほほ
とほほ
> は、無駄な労力を強いて、バグ検出の機会を増やし、また埋め込む機会を増やすよ
う
> な気がしてなりません。
”バグ検出の機会を増やし”ではなく、”バグ検出の機会を減らし”、でした、と
ほほ
--
とほほ
Sugihara Yoshimi
"とほほ" <toh...@zxmail.com> wrote in message
news:9carho$g76$1...@nn-tk105.ocn.ad.jp...
コーディング規約って「自分がメンテナンスするわけではない」
ということから発生してる内容だと思うんですよね
時々ほかの人のソースコード見るんですが
なんでこんなことやってんのかな・・
とか
この処理はどこでやってんだ？
とかいったのを極力減らすにはとりあえず良い方法だと思います。
初期化も
変数宣言したらすぐに初期化する
と決めてあれば
とりあえず変数が宣言してある部分の直後に初期化するコード
があるはず
とある程度見る範囲をある程度しぼることも可能ですし・・
まあ規約の中に「？？」とか思うものもありますが（笑）
#そういや私は"++i"や"i++"って使わないなぁ・・
#そのほかにも使わない表記って結構ある
とほほ
> 初期化も
> 変数宣言したらすぐに初期化する
> と決めてあれば
> とりあえず変数が宣言してある部分の直後に初期化するコード
> があるはず
> とある程度見る範囲をある程度しぼることも可能ですし・・
そうですね、このような処理原則といったような「コーディング規約」っていうの
が、ホントの有用な「コーディング規約」だと思います。
上の線で展開はほとんどなく、多くの「コーディング規約」ってのは、インデント
をこういうにしろとか、３項演算子は使うなとか、intは使うなとか、書き方を縛っ
ているだけの形式にこだわったものが多いと思います。
合理的理由があれば別ですが、既に一般化している慣習を無視してローカル・ルー
ルを定めているのもままあり、こんなの逆に混乱をまねくだけってのも・・・・・
--
とほほ
MAEDA Atusi (前田敦司)
> 初期化も
> 変数宣言したらすぐに初期化する
> と決めてあれば
> とりあえず変数が宣言してある部分の直後に初期化するコード
> があるはず
> とある程度見る範囲をある程度しぼることも可能ですし・・
機械的に初期化するということは、本当に後で使う値を計算して入れるのでは
なく、適当な嘘の値(0とかNULLとか)を入れとくわけですよね。
その「嘘の値」を入れとくと何の役に立つの? バグが見つけにくくなるだけじゃ?
int i;
i = 0;
...
i = <本当に必要な値>;
...
<iを使う場所>
「<iを使う場所>でiに<本当に必要な値>が入っているかどうか」と
「宣言直後にiを初期化するかどうか」に何の関係が?
前田敦司
Kazuo Fox Dohzono
OKAMURA Kikuo <gf4k...@asahi-net.or.jp> writes:
> ということで、「コーディング規約」ってなに？
色々出ているようですが, 簡単に閲覧できるものに GNU CODING STANDARD と
いうのもあります. 昔は emacs-info の中にもあった気がしますけど, 最近は
見掛けませんね. GNU アーカイブに standards.text というのがあったら多分
それです.
if (cond1)
if (cond2)
stmt1;
else
stmt2;
の場合は
if (cond1)
{
if (cond2)
stmt1;
else
stmt2;
}
としなさい, などがありました.
# 構文解析に明るい人は自然とこうしてる気も.
--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp
[12],(6,9),0,0,2
(4/1449/3742)
Koji Shiota
》> 初期化も
》> 変数宣言したらすぐに初期化する
》> と決めてあれば
》> とりあえず変数が宣言してある部分の直後に初期化するコード
》> があるはず
》> とある程度見る範囲をある程度しぼることも可能ですし・・
》
》機械的に初期化するということは、本当に後で使う値を計算して入れるのでは
》なく、適当な嘘の値(0とかNULLとか)を入れとくわけですよね。
》
》その「嘘の値」を入れとくと何の役に立つの? バグが見つけにくくなるだけじゃ?
》
実体の確保．．．という話はおいといて。
「変数宣言したらすぐに初期化する」は、「変数宣言したら初期化が必要
な変数はすぐに初期化する」がよくあることだと思います。
「嘘の値」ではなく、「初期化が必要な変数の初期設定値」ですよね。
役に立つとかバグが見つけにくくなるというのは「必要のない初期化」を
した場合ですよね。やり方はコーディングや設計をした人によって違いま
すが。
--
Koji Shiota <k-sh...@po.iijnet.or.jp>
Sugihara Yoshimi
インデントは見栄えをそろえるとかもありますね。
時々ですがすごい人がいるもので（笑）
intは１６ビットから32ビットに移行するころにいろいろ起こったような記憶が
あります。私も一時intを使わなかったころがありますし・・
Sugihara Yoshimi
"MAEDA Atusi (前田敦司)" <ma...@cc.tsukuba.ac.jp> wrote in message
news:m3lmom2...@maedapc.cc.tsukuba.ac.jp...
普通に考えれば
{
int i=<本当に必要な値>;
<iを使う場所>
}
と思うんですが・・
MAEDA Atusi (前田敦司)
> > > 初期化も
> > > 変数宣言したらすぐに初期化する
> > > と決めてあれば
> > > とりあえず変数が宣言してある部分の直後に初期化するコード
> > > があるはず
> > > とある程度見る範囲をある程度しぼることも可能ですし・・
> > 「<iを使う場所>でiに<本当に必要な値>が入っているかどうか」と
> > 「宣言直後にiを初期化するかどうか」に何の関係が?
>
> 普通に考えれば
>
> {
> int i=<本当に必要な値>;
> <iを使う場所>
> }
>
> と思うんですが・・
そんな単純な例ばかりなら、もともと「見る範囲をある程度しぼる」必要なん
てないじゃない。
前田敦司
とほほ
> > > 初期化も
> > > 変数宣言したらすぐに初期化する
> > > と決めてあれば
> > > とりあえず変数が宣言してある部分の直後に初期化するコード
> > > があるはず
> > > とある程度見る範囲をある程度しぼることも可能ですし・・
> >
> > そうですね、このような処理原則といったような「コーディング規約」ってい
う
> の
> > が、ホントの有用な「コーディング規約」だと思います。
付け加えるなら、ｎｅｗしたデータは、別スコープでなく同じスコープでｄｅｌｅ
ｔｅする、セマフォなどのシステム資源の確保と解放は原則同一スコープで行う、不
要になったハードウェア資源、たとえばファイルやタイマなどは、いつまでも抱えて
いないですぐ解放する、結合の強い関数は離さず近くに置くとかとか・・・
> インデントは見栄えをそろえるとかもありますね。
> 時々ですがすごい人がいるもので（笑）
あるある（笑）！！ でも、コーディング・スタイルが統一されているというより
も、わたしはどちらかというと、なんでこの問題にこんなアルゴリズムを？？？って
いうのが多いですね。
適切なアルゴリズムを使える人たちのコーディングは、似ている部分が多いのでは
ないでしょうか？
こういったことで、書き方の些細な部分にこだわった「コーディング規約」なんて
ものはクソクラエ！と思っています。 もっとアリゴリズムの勉強や、先にあげたバ
グの発生を抑える処理ルールなどを・・明らかにせよと・・・・
> intは１６ビットから32ビットに移行するころにいろいろ起こったような記憶が
> あります。私も一時intを使わなかったころがありますし・・
”ｉｎｔ型のデータ型を使うな”っていう考え方は、外部データについては一慨に
否定することはできませんが、ＡＰＩの引数などについては、ｉｎｔ型と定義されて
いるデータは、その通りｉｎｔ型でコーディングすべきだと思います。
＃ｉｎｔ型を使わないというルールでコーディングされたプログラムの移植
＃には、ＡＰＩ絡みでえらい苦労をさせられたなぁ。
OKAMURA Kikuo
>> ということで、「コーディング規約」ってなに？
>
>色々出ているようですが, 簡単に閲覧できるものに GNU CODING STANDARD と
>いうのもあります. 昔は emacs-info の中にもあった気がしますけど, 最近は
>見掛けませんね. GNU アーカイブに standards.text というのがあったら多分
>それです.
http://www.gnu.org/prep/standards.html
のことでしょうか？
なんとなく面白そうなのですが、外国の言葉は苦手なので、読むのに苦労しそ
うです。
> if (cond1)
> {
> if (cond2)
> stmt1;
> else
> stmt2;
> }
私としては { の位置がなんか宙ぶらりんに見えるので、少し気持ち悪いので
すが、一般的な書き方なのでしょうか？
#こういう質問のための例ではないので恐縮です。
OKAMURA Kikuo
>「auto 変数１つ作るたびに上司の承認が必要」
#６分冗談ですが、４分本気です。（半分半分ではありません。若干冗談が
#多いです）
これは、申請書が用意されていていたりするのでしょうか？
auto 変数申請用紙
申請者氏名 OKAMURA KIKUO
作成したい変数名 int i
申請の理由 計算で必要
などと記入するのでしょうか？
ひとつの変数のスコープを広くして、申請しなくてもいいように使いまわすこ
とを奨励しているのでしょうか？
どうしてなのか知りたいです。
OKAMURA Kikuo
>> intは１６ビットから32ビットに移行するころにいろいろ起こったような記憶が
>> あります。私も一時intを使わなかったころがありますし・・
>
> ”ｉｎｔ型のデータ型を使うな”っていう考え方は、外部データについては一慨に
>否定することはできませんが、ＡＰＩの引数などについては、ｉｎｔ型と定義されて
>いるデータは、その通りｉｎｔ型でコーディングすべきだと思います。
>
>＃ｉｎｔ型を使わないというルールでコーディングされたプログラムの移植
>＃には、ＡＰＩ絡みでえらい苦労をさせられたなぁ。
どのように、移植される可能性があるのか？という疑問を抜きにし過ぎの規約
だったようですね？
でも、上記の場合「intを使うな」という規約の誤りではなく、「かかわって
いるプロジェクトでこの規約を選択した」ことが間違いなだけですよね。
Shinji KONO
In article <9cal96$t4n$1...@nn-tk105.ocn.ad.jp> ,
とほほ<toh...@zxmail.com> writes
> なぜなら、Ｃソースの整形プログラムが、UNIXベースであれWindowsベースであれ
>多数ありますので、それを使えば他人のソースであっても、ある程度自分の好みのス
>タイルに整形できるからです。
そんなんで、ソースの形式をがんがん変形されちゃったら、変更履歴
を追跡出来なくなるでしょうが...
こういう奴と常に対決していかなければならないのが、最近、うっ
とうしいかも...
> なぜ世間では、コーディング・スタイルなんかよりも、解法表現スタイルの方を重
>視してくれないのでしょうか？
コーディング規則は、自分のためではなくて、一緒に仕事をしている
他の仲間のためにあるんです。
C のソースを実は、XML で記述して、style file で、自分の好み
に整形してくれるとかいうなら、許す。
In article <squeluf...@stellar.co.jp>, Hideo "Sir MaNMOS" Morishita writes:
> これって、cvsを使っていたら、全く必要のないことですよね。ツールででき
> る仕事をわざわざ人間がやるのって愚の骨頂のような。
でも、ツールを使いこなすためには、実は、規則があった方がいい
んですよね。
> ３番目は「変数名はハンガリアン記法」って形で見たことあります。
> ＃ハンガリアン記法って今一つ分かりにくい。
ハンガリアン記法って、なんか、チェッカとかあるんですかね? あ
るんだったら、少しは意味があるかも。
まぁ、でも、それが使われていたら、(文句はいうけど) それに従います。
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)
Shinji KONO
In article <void-27040...@newshost.ryukyu.ad.jp> ,
vo...@merope.pleiades.or.jp (Kusakabe Youichi) writes
>> 「各行に最終更新者のIDを記入せよ」
>4つめは実際に出くわしたことがありますねー
ソース管理ツールを使ってないってのはさびしすぎる...
でも、
int a,b,....;
とか並べると、diff した時に、変更点が読みづらいってのはあるかな。
Hironori FUJII
>
> 河野 真治@琉球大情報工学です。
>
> In article <9cal96$t4n$1...@nn-tk105.ocn.ad.jp> ,
> とほほ<toh...@zxmail.com> writes
> > なぜなら、Ｃソースの整形プログラムが、UNIXベースであれWindowsベースであれ
> >多数ありますので、それを使えば他人のソースであっても、ある程度自分の好みのス
> >タイルに整形できるからです。
>
> そんなんで、ソースの形式をがんがん変形されちゃったら、変更履歴
> を追跡出来なくなるでしょうが...
cvs にて、チェックインとチェックアウトの際に透過的に
GNU indent などを通せばこの問題は解決できないですか?
ただ、何行目という概念が成り立たなくなってしまいます。
その際はラベルでも付けましょう。:-)
Kusakabe Youichi
rote:
> > > 例えば、"++i"などと演算子と項との間にブランクを置かない記述と、
> > > "++ i"とを置く記述とでは、
> > > "++"という強結合の１項演算子の理解度を反映した結果となっています
> >
> > いいえ。
> > ただの「後者は問題外」なだけでは?
>
> 上の例では、"++ i"とか書くひとが、結構いるんすよね ・・・
そんな人は問題外なのでさっさと切り捨てましょう。
Yoshiki Kataoka
> どうしてなのか知りたいです。
ハンガリー記法よりずっと厳しい命名規則があったらしいです。
Yoshitaka Ikeda
> そうですね、このような処理原則といったような「コーディング規約」っていう
の
>
> 上の線で展開はほとんどなく、多くの「コーディング規約」ってのは、インデン
ト
> をこういうにしろとか、３項演算子は使うなとか、intは使うなとか、書き方を
縛っ
> 合理的理由があれば別ですが、既に一般化している慣習を無視してローカル・
ルー
> ルを定めているのもままあり、こんなの逆に混乱をまねくだけってのも・・・・・
intに関しては,使うなは行き過ぎにしても,
変数サイズが違うケースがある事を認識した上で使用するべきだと思います.
int=32bitとかローカルの環境でしか通用しない前提を元にコーディングする人が
時々います.
(自分も昔それで永久ループ作った事があって,それ以来intは外部関数の要求以外で
は
使用しなくなりました.)
基本は,longやshortですよね.そうでなければtypedefで解決するようにした方がいい
と思う.
#分かって使う分にはOKだけど
--
/-----------------/
/ Yoshitaka Ikeda /
/ ik...@4bn.ne.jp /
/-----------------/
Junn Ohta
ik...@4bn.ne.jpさんは書きました。
> intに関しては,使うなは行き過ぎにしても,
> 変数サイズが違うケースがある事を認識した上で使用するべきだと思います.
それはそうですけど、それをいうならshortもlongも同
じでしょう?
> 基本は,longやshortですよね.
違うと思う...。
--
太田純(Junn Ohta) (株)リコー/新横浜事業所
oh...@sdg.mdd.ricoh.co.jp
Kusakabe Youichi
Ohta) wrote:
> fj.comp.lang.cの記事<9cl79l$9ua$1...@nn-tk105.ocn.ad.jp>で
> ik...@4bn.ne.jpさんは書きました。
> > intに関しては,使うなは行き過ぎにしても,
> > 変数サイズが違うケースがある事を認識した上で使用するべきだと思います.
>
> それはそうですけど、それをいうならshortもlongも同じでしょう?
そう思います。「intを使うな」っていう人はまあ信用できないと思っていいと
思う。
実際そういうコーティング規約はみたことありますが...
あるプロジェクトで「intを使わずにマクロ名SHORT、LONGを使うように」っていう
ローカルルールなやつはありましたが、そういうのならまだわからなくもないと
思います。
Sugihara Yoshimi
"Junn Ohta" <oh...@src.ricoh.co.jp> wrote in message
news:9cl7pj$98g$1...@ns.src.ricoh.co.jp...
> fj.comp.lang.cの記事<9cl79l$9ua$1...@nn-tk105.ocn.ad.jp>で
> ik...@4bn.ne.jpさんは書きました。
> > intに関しては,使うなは行き過ぎにしても,
> > 変数サイズが違うケースがある事を認識した上で使用するべきだと思います.
>
> それはそうですけど、それをいうならshortもlongも同
> じでしょう?
short ・・・ 2byte
long ・・・ 4byte
以外の場合があるということでしょうか。
paoneko
"Yoshitaka Ikeda" <ik...@4bn.ne.jp> wrote in message
news:9cl79l$9ua$1...@nn-tk105.ocn.ad.jp...
> 変数サイズが違うケースがある事を認識した上で使用するべきだと思います.
> int=32bitとかローカルの環境でしか通用しない前提を元にコーディングする
人が
> 時々います.
ローカルの環境の意味がわかりませんが、別に問題の無い場合も多いです。移植
の予定もなく、その環境でしかコンパイルされないなら、構わないでしょ？
> 基本は,longやshortですよね.
いいえ。例えばlongは何ビットだとお考えですか？
私は、少し前までint=32bit long=32bit の環境で仕事をしていましたが、最近
はint=32bit long=64bitの環境に変わりました。
> そうでなければtypedefで解決するようにした方がいい
> と思う.
必ずしもそうだとは思いません。ひとつのソースを別の環境でコンパイルする可
能性がある場合、例えばUnix系で広く公開しようとしているプログラムなどで、
サイズに依存している部分は、そうしておくべきでしょうけど。
for (i=0; i<100; i++) というケースでは、いかなる環境でも i は int でい
いですよね？
Kazuo Fox Dohzono
OKAMURA Kikuo <gf4k...@asahi-net.or.jp> writes:
> >色々出ているようですが, 簡単に閲覧できるものに GNU CODING STANDARD と
> >いうのもあります. 昔は emacs-info の中にもあった気がしますけど, 最近は
> >見掛けませんね. GNU アーカイブに standards.text というのがあったら多分
> >それです.
>
> http://www.gnu.org/prep/standards.html
> のことでしょうか？
たぶんそれです (と, 見ずに言う奴…).
> なんとなく面白そうなのですが、外国の言葉は苦手なので、読むのに苦労しそ
> うです。
http://www.sra.co.jp/ の「技術情報」に無いかな, と思って探しましたけど
見つけられませんでした.
> > if (cond1)
> > {
> > if (cond2)
> > stmt1;
> > else
> > stmt2;
> > }
>
> 私としては { の位置がなんか宙ぶらりんに見えるので、少し気持ち悪いので
> すが、一般的な書き方なのでしょうか？
今は (よく見掛けるという意味で) 一般的と言っていいんじゃないかと思いま
す. GNU のスタイルがこうですよね.
私も emacs を使うようになってこういう書き方になりましたが, その前は
if (cond) {
…;
}
でした.
SHIROYAMA Takayuki
In <<9clfld$4om$1...@news.kyosai.or.jp>>, Sugihara Yoshimi wrote:
> > それはそうですけど、それをいうならshortもlongも同
> > じでしょう?
>
> short ・・・ 2byte
> long ・・・ 4byte
>
> 以外の場合があるということでしょうか。
>
では、一例を。
--------
pastel> uname -rsm
NetBSD 1.5L alpha
pastel> cat v.c
#include <stdio.h>
int main( int c, char *v[])
{
printf( "short = %d, long = %d\n", sizeof( short ), sizeof( long ) );
}
pastel> cc v.c
pastel> ./a.out
short = 2, long = 8
--------
---
SHIROYAMA Takayuki
Yukihiro Matsumoto
"Sugihara Yoshimi" <sugi...@kyosai.or.jp> writes:
|short ・・・ 2byte
|long ・・・ 4byte
|
|以外の場合があるということでしょうか。
もちろんですとも。そうだったら世の中楽だったんですが。
Hironori FUJII
> そう思います。「intを使うな」っていう人はまあ信用できないと思っていいと
> 思う。
>
> 実際そういうコーティング規約はみたことありますが...
>
> あるプロジェクトで「intを使わずにマクロ名SHORT、LONGを使うように」っていう
>
> ローカルルールなやつはありましたが、そういうのならまだわからなくもないと
> 思います。
>
マクロ名っていうことは、
#define SHORT short
って感じですか? それとも typedef で定義したものもマクロと
いうのかな? どちらにしろ悲しくなります。
似たような話で、Gtk+ の GLib に gint ってのが定義されています。
あれを見たとき、 C に対するボウトクだ! と思ったのは私だけですか？
どうしても、頭文字が g でなくては病気になるのなら
やむをえませんが。
KATAYAMA Yoshio
"Sugihara Yoshimi" <sugi...@kyosai.or.jp> writes:
>short ・・・ 2byte
>long ・・・ 4byte
>以外の場合があるということでしょうか。
ありますよ。
1 byte が 8 ビットではない処理系もありますね。
--
片山＠ＰＦＵ
Hideo Sir MaNMOS Morishita
In article <9clj9i$2b70$1...@news2.rim.or.jp>,
doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:
> > 私としては { の位置がなんか宙ぶらりんに見えるので、少し気持ち悪いので
> > すが、一般的な書き方なのでしょうか？
>
> 今は (よく見掛けるという意味で) 一般的と言っていいんじゃないかと思いま
> す. GNU のスタイルがこうですよね.
>
> 私も emacs を使うようになってこういう書き方になりましたが, その前は
>
> if (cond) {
> …;
> }
>
> でした.
emacsで書いていても
(setq c-default-style "bsd")
で良いのでは？
--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 ＭａＮＭＯＳ 英夫＠ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37
Junn Ohta
sugi...@kyosai.or.jpさんは書きました。
> short ・・・ 2byte
> long ・・・ 4byte
> 以外の場合があるということでしょうか。
それはあまりといえばあまりにnaiveな...。:-(
極端なところでは、Cray PVP上のCray Standard C処理
系(ANSI規格準拠)のように
short 64ビット
int 64ビット
long 64ビット
という例もあります。
Yoshitaka Ikeda
> ik...@4bn.ne.jpさんは書きました。
> > intに関しては,使うなは行き過ぎにしても,
> > 変数サイズが違うケースがある事を認識した上で使用するべきだと思います.
>
> それはそうですけど、それをいうならshortもlongも同
> じでしょう?
すみません。今の今迄そう思い込んでいました。
定義上は
short<=int<=long
に過ぎないのですね。
> > 基本は,longやshortですよね.
>
> 違うと思う...。
というわけで、
移植性を考慮するならやはりプリミティブな型を直接書かない方がいいのか。
intに限らず,サイズの違いは考慮した方がいいんですね。
#今までそうでないのにであってこなかっただけだったのか。
Takao Ono
うか?
<9cljdv$hmo$1...@pastel.front.nest.or.jp>の記事において
p...@felicia.fortune.nest.or.jpさんは書きました。
psi> > short ・・・ 2byte
psi> > long ・・・ 4byte
psi> > 以外の場合があるということでしょうか。
他の方のフォローアップにもありますが, 規格上はありえますし実際
64bit CPU の環境では long が 64bit になったりします. そっち方面の
キーワードはLP64 とか ILP64 とかですかね.
そういう環境で CHAR_BIT == 8 なら long は 8byte になっちゃいます.
# もちろん CHAR_BIT == 16 かつ short が 32bit, long が 64bit なら
# 「short = 2byte, long = 4byte」と言えるんですが.
psi> printf( "short = %d, long = %d\n", sizeof( short ), sizeof( long ) );
ところで, ここは %d じゃなくて %u の方が教科書的には正しいような....
# いや, すべて unsigned long にキャストして %lu で受けるべきか....
--
名古屋大学 工学部 電子工学科 平田研究室
小野 孝男
Hironori FUJII
> http://www.gnu.org/prep/standards.html
> のことでしょうか？
> なんとなく面白そうなのですが、外国の言葉は苦手なので、読むのに苦労しそ
> うです。
<8913.98...@rananim.ie.u-ryukyu.ac.jp> にて、
河野さん曰く、
> コーディング規則は、自分のためではなくて、一緒に仕事をしている
> 他の仲間のためにあるんです。
より、苦労してまで今すぐ読む必要はなさそうです。
ちなみに、私はコーディング規則は自分のためでもあるが持論です。
一貫した規則で書いたほうがバグを見付けやすいですから。
> 私としては { の位置がなんか宙ぶらりんに見えるので、少し気持ち悪いので
これは私も同感です。
でも日本語訳もありますし、ここで議論されてる方のほとんどは
１度は目を通されているのではないでしょうか?
読んだところで何も得しないとは思いますが、
私は読むことをおすすめします。
GNU Coding Standards 日本語訳
http://www.sra.co.jp/wingnut/standards-j_toc.html
GNU jdoc
http://openlab.ring.gr.jp/gnujdoc/
Shinji KONO
In article <3AEE5F77...@cr.info.hiroshima-cu.ac.jp> ,
Hironori FUJII <e23...@cr.info.hiroshima-cu.ac.jp> writes
>> 私としては { の位置がなんか宙ぶらりんに見えるので、少し気持ち悪いので
>これは私も同感です。
それは、つまり、Unix のカーネルを読んだことがないってことですよね。
kernel style とか呼ばれることもあります。ま、慣れですね。
僕も最初は、
int
main()
{
if ()
{
}
}
みたいなスタイルを自分勝手に使っていました。Pascal の影響が
少し入ってますね。大学院に入ってから直しました。
Kusakabe Youichi
そんなまぬけなことを言っているひとが
「intはよくない」なんて言っているのでしょうか?
うーむ。
Kusakabe Youichi
<e23...@cr.info.hiroshima-cu.ac.jp> wrote:
> > あるプロジェクトで「intを使わずにマクロ名SHORT、LONGを使うように」って
いう
> > ローカルルールなやつはありましたが、そういうのならまだわからなくもない
と
> > 思います。
> >
>
> マクロ名っていうことは、
> #define SHORT short
> って感じですか? それとも typedef で定義したものもマクロと
> いうのかな? どちらにしろ悲しくなります。
そうではなくて、移植先に応じて定義を変えるっていうことです。
「INT32」「INT16」なんていうマクロ名を使っているプロジェクトもありました。
まあ、そういうのがいいって私が言っているわけではなく、
「intを使うな。short、longを使え」とかいうマヌケなのよりは、
そっちのほうがまだ意味があるかもしれない、という程度の話です。
Kusakabe Youichi
現実的にはその大小関係でいいのでしょうけど、
定義的には、
short<=long
が言えるだけだったかも。
> 移植性を考慮するならやはりプリミティブな型を直接書かない方がいいのか。
> intに限らず,サイズの違いは考慮した方がいいんですね。
それを言ったらbit幅だけじゃなくて、全部1が立ったのをどう扱うかの違いとか、
そういう違いもでてくるのでは?
そもそも2の補数形式である保証もないんじゃなかったっけ?
Kusakabe Youichi
> 私も emacs を使うようになってこういう書き方になりましたが, その前は
> if (cond) {
> …;
> }
> でした.
いわゆるallmanスタイルじゃなくてkernelスタイルってことですか?
Kazuo Fox Dohzono
man...@stellar.co.jp (Hideo "Sir MaNMOS" Morishita) writes:
> > 私も emacs を使うようになってこういう書き方になりましたが, その前は
> >
> > if (cond) {
> > …;
> > }
> >
> > でした.
>
> emacsで書いていても
> (setq c-default-style "bsd")
> で良いのでは？
うーん, その変数は私の環境だと symbol's value as variable is void って
言われてしまいます. でも確かに今の環境でもやろうと思えばそうなります.
うーん. なんで移行したんだろ.
Kazuo Fox Dohzono
ka...@pfu.fujitsu.com (KATAYAMA Yoshio) writes:
> >short ・・・ 2byte
> >long ・・・ 4byte
>
> >以外の場合があるということでしょうか。
>
> ありますよ。
なんというか, 幸せな質問ですね.
> 1 byte が 8 ビットではない処理系もありますね。
$(gcc)/config/ を grep したら
./c4x/xm-c4x.h:#define HOST_BITS_PER_CHAR 32
./c4x/xm-c4x.h:#define HOST_BITS_PER_SHORT 32
./c4x/xm-c4x.h:#define HOST_BITS_PER_INT 32
というのがありました. TMS320C[34]x だそうです (これって正式にサポート
されてるのかなあ).
320C50 なら使ったことがあって, そいつは char から int まで全部 16bit
でした (コンパイラはベンダ供給のものを使いました).
といず
Subject: Re: indent (Re: コーディング規約について)
Message-ID: <squy9sh...@stellar.co.jp>
Hideo "Sir MaNMOS" Morishita san wrote:
> In article <9clj9i$2b70$1...@news2.rim.or.jp>,
> doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:
> > > 私としては { の位置がなんか宙ぶらりんに見えるので、少し気持ち悪いので
> > > すが、一般的な書き方なのでしょうか？
> >
> > 今は (よく見掛けるという意味で) 一般的と言っていいんじゃないかと思いま
> > す. GNU のスタイルがこうですよね.
> >
> > 私も emacs を使うようになってこういう書き方になりましたが, その前は
> >
> > if (cond) {
> > …;
> > }
> >
> > でした.
>
> emacsで書いていても
> (setq c-default-style "bsd")
> で良いのでは？
>
“indent” でお好きに設定すれば、とっても楽チンでわ？
$ see man indent
ついでに私は、
$ indent -kr -ts 4 ファイル名
この形式が好きだったりする。
----------------------------------
といず＠花粉症.狂
mailto:toys...@hotmail.com
自分自身を大切に
Junn Ohta
ォローアップ先は決めていません。
fj.comp.lang.cの記事<20432.9...@rananim.ie.u-ryukyu.ac.jp>で
ko...@ie.u-ryukyu.ac.jpさんは書きました。
> 僕も最初は、
> int
> main()
> {
> if ()
> {
> }
> }
> みたいなスタイルを自分勝手に使っていました。Pascal の影響が
> 少し入ってますね。
つーかPascalでもいろいろあったのでは?
私はPascalでは
procedure ほげ;
begin
if 条件 then begin
文の並び
end else if 条件 then begin
文の並び
end else begin
文の並び
end
end;
こんな感じでした。(たぶん少数派:-)
実際には
if 条件 then
文の並び
elif 条件 then
文の並び
else
文の並び
fi
と書いておいてプリプロセッサーで
then → then begin
elif → end else if
else → end else begin
fi → end
に変換していたのですが...。
Go Watanabe
ik...@4bn.ne.jpさんは書きました。
>すみません。今の今迄そう思い込んでいました。
>定義上は
>short<=int<=long
>に過ぎないのですね。
それぞれのサイズの下限は決まってますが上限が決まってません
>> > 基本は,longやshortですよね.
>>
>> 違うと思う...。
>
>というわけで、
>移植性を考慮するならやはりプリミティブな型を直接書かない方がいいのか。
>
>intに限らず,サイズの違いは考慮した方がいいんですね。
>
>#今までそうでないのにであってこなかっただけだったのか。
多くの UNIX 環境では、sys/types.h などで int??_t といった形で幅の指定が
できる型名が定義されてますね。それを使って限られた範囲ではありますが、
移植性を確保していたりします。
C99 ではちゃっかり規格にとりこまれて、stdint.h で int??_t, int_least??_t
といった型が定義されてます (?? には 8 とか 16 とか 32 とか 64とか入る)
# ただし、これらは実装系によってそれぞれが使えるかどうかは変わります。
# intN_t は厳密な幅規定でint_leastN_t は最小幅規定です。
--
渡邊剛 (Watanabe,Go) g...@dsl.gr.jp / g...@denpa.org
SHIROYAMA Takayuki
In <<9clll1$cck$1...@henry.hirata.nuee.nagoya-u.ac.jp>>, Takao Ono wrote:
>
> psi> printf( "short = %d, long = %d\n", sizeof( short ), sizeof( long ) );
> ところで, ここは %d じゃなくて %u の方が教科書的には正しいような....
>
さくっと数分で作って捨てたプログラムなんで、 そう
いう点にあまり気を使ってませんでした、すみません(^^;
---
SHIROYAMA Takayuki
Sugihara Yoshimi
"Takao Ono" <ta...@hirata.nuee.nagoya-u.ac.jp> wrote in message
news:9clll1$cck$1...@henry.hirata.nuee.nagoya-u.ac.jp...
> そういえば, IA64 用コンパイラではやっぱり long = 8byte なんでしょ
> うか?
>
> <9cljdv$hmo$1...@pastel.front.nest.or.jp>の記事において
> p...@felicia.fortune.nest.or.jpさんは書きました。
> psi> > short ・・・ 2byte
> psi> > long ・・・ 4byte
> psi> > 以外の場合があるということでしょうか。
> 他の方のフォローアップにもありますが, 規格上はありえますし実際
> 64bit CPU の環境では long が 64bit になったりします. そっち方面の
> キーワードはLP64 とか ILP64 とかですかね.
６４ビットCPUっすか。
それは触ったことなしです。
> そういう環境で CHAR_BIT == 8 なら long は 8byte になっちゃいます.
> # もちろん CHAR_BIT == 16 かつ short が 32bit, long が 64bit なら
> # 「short = 2byte, long = 4byte」と言えるんですが.
これは
1byte=16bit
とになっている処理系では
long=64bit(4byte)
ってことです？
しかも、これで規格上OK（ANSI－C準拠）ってことですか？
#なんかなー
昔16bit単位でしか扱えないCPUを触ったことあるけど
そのときは16bit=1word=2byteと定義されてました。
うわさでlong=64bitというのがあるときいてはいたけど
規格上OKとは思いませんでした（＾＾；；
Takao Ono
vo...@merope.pleiades.or.jpさんは書きました。
void> > 定義上は
void> > short<=int<=long
void> > に過ぎないのですね。
void> 現実的にはその大小関係でいいのでしょうけど、
void> 定義的には、
void> short<=long
void> が言えるだけだったかも。
いえ, ちゃんと
short <= int <= long
が保証されています. あと, short は少なくとも 16bit, long は少なく
とも 32bit というのも保証されています.
C99 の long long は「long より短くなく, 少なくとも 64bit」です.
void> そもそも2の補数形式である保証もないんじゃなかったっけ?
ありません. 負の数の形式としては, 「2の補数」, 「1の補数」, 「符
号+絶対値」のどれでもかまいません.
その他であってもいいかもしれません.
paoneko
"Takao Ono" <ta...@hirata.nuee.nagoya-u.ac.jp> wrote in message
news:9clll1$cck$1...@henry.hirata.nuee.nagoya-u.ac.jp...
> そういう環境で CHAR_BIT == 8 なら long は 8byte になっちゃいます.
> # もちろん CHAR_BIT == 16 かつ short が 32bit, long が 64bit なら
> # 「short = 2byte, long = 4byte」と言えるんですが.
1Byte も 8bit とは限らないのでしょうか？
昔に１Byteが何ビットであるかはCPUによって違う、だからROMの単位はビットを
使うという、のを見たような気もするのですが、いつの頃からか、1Byte=8bitと
いう記述ばかりなったような気がします。
ある時期に1Byte＝8bitと定まったような気もするのですが、単なる私の妄想の
可能性大です。
何で定められているのでしょう?
Takao Ono
sugi...@kyosai.or.jpさんは書きました。
sugihara> > そういう環境で CHAR_BIT == 8 なら long は 8byte になっちゃいます.
sugihara> > # もちろん CHAR_BIT == 16 かつ short が 32bit, long が 64bit なら
sugihara> > # 「short = 2byte, long = 4byte」と言えるんですが.
sugihara> これは
sugihara> 1byte=16bit
sugihara> とになっている処理系では
sugihara> long=64bit(4byte)
sugihara> ってことです？
もちろんです.
sugihara> しかも、これで規格上OK（ANSI－C準拠）ってことですか？
もちろんです.
integral type の大きさに関して規格にあるのは
・char >= 8bit, short >= 16bit, long >= 32bit (long long >=
64bit)
・(char <=) short <= int <= long (<= long long)
・とにかく char 1個入る大きさが 1byte
の 3つだけですから. したがって, 極端な話ですが
char = short = int = long = long long = 64bit
という処理系があったとしても (実際にはほぼ間違いなく存在しません
が) それだけでは問題なしです.
# もちろんこの処理系ではすべての型が 1byte ですが.
--
名古屋大学 工学部 電子工学科 平田研究室
小野 孝男
φ(^_^)φ 小野 孝男
《名古屋大学.大学院.工学研究科.情報工学専攻》
ta...@hirata.nuee.nagoya-u.ac.jp
Yukio Sakuma
> つーかPascalでもいろいろあったのでは?
>
> 私はPascalでは
> procedure ほげ;
> begin
> if 条件 then begin
> 文の並び
> end else if 条件 then begin
> 文の並び
> end else begin
> 文の並び
> end
> end;
Borland Turbo PASCAL 7.0のサンプルコードはこんな感じみたいです。
procedure Hoge1
begin
if 条件 then
begin
文の並び
end else
if 条件 then
begin
文の並び
end else
begin
文の並び
end
end;
昔の教科書みたいな書籍で見たような気がする、どんどん深くなっていくタイプとか。
＃そういう学校には行ったことがないです。
procedure Hoge2
begin
if 条件 then
begin
文の並び
end
else (*ここ変？*)
if 条件 then
begin
文の並び
.....
私ならこんな感じかな。
procedure Hoge3
begin
if 条件 then begin
文の並び
end else
if 条件 then begin (*たいして変わらんか*)
文の並び
end else begin
文の並び
end
end;
Pascalといっても人によって結構違うみたいです。が、そんなに多くの
ソースコードがあるわけじゃないですね。(^^;
--
Yukio Sakuma
MAEDA Atusi (前田敦司)
> ６４ビットCPUっすか。
> それは触ったことなしです。
存在することも知らなかったんですか。それとも「64bit CPUのためのC処理系
では64bit整数が使えるだろう」という推論をしなかったとか?
> うわさでlong=64bitというのがあるときいてはいたけど
> 規格上OKとは思いませんでした（＾＾；；
うわさ... うーん。64bitマシンなんて別に珍しくも何ともないんですけど。
＃ WSはもちろん、Nintendo64もPlayStation2も...
＃ (あ、PS2ってひょっとしてlong 128bitだったりする？)
ところで、あれだけ規格の話をしていたのに、規格書を読んでないんでしょう
か。
前田敦司
Kazuo Fox Dohzono
"Sugihara Yoshimi" <sugi...@kyosai.or.jp> writes:
> 昔16bit単位でしか扱えないCPUを触ったことあるけど
> そのときは16bit=1word=2byteと定義されてました。
その場合 C の定義では 1byte == 16bit です.
[#1] byte
addressable unit of data storage large enough to hold any
member of the basic character set of the execution
environment
Kazuo Fox Dohzono
といず<toys...@hotmail.com> writes:
> $ indent -kr -ts 4 ファイル名
> この形式が好きだったりする。
indent: Command line: unknown parameter "-kr"
# ってのが私の環境.
これは全く私の偏見 (?) なのですが,
x >>= y;
を
x >> = y;
とフォーマットされてから GNU indent は使わないようにしています (修正さ
れているのは確認しましたし, 人にも勧めることはあるんですけど).
Takao Ono
pao...@e-game.co.jpさんは書きました。
paoneko> ちょいとCの話題からはずれます。
これ, どこに振るんでしょうね. とりあえず followup-to を
fj.comp.misc にしておきます.
paoneko> > # もちろん CHAR_BIT == 16 かつ short が 32bit, long が 64bit なら
paoneko> > # 「short = 2byte, long = 4byte」と言えるんですが.
paoneko> 1Byte も 8bit とは限らないのでしょうか？
C の規格からは「8bit 以上であればいい」が正解. UCHAR_MAX の関係か
ら最低 8bit 必要なことが決まりますが, それ以上は「処理系に聞いて
ください」です.
そういえば「8あれば9あり」という諺を見た記憶があるんですが, どこ
で見たんだろう.
# 「1Byte = 8bit とは限らない, 9bit の環境だってあるんだから, そ
# んなことに依存しないプログラムを書きましょうね」という意味だっ
# たと記憶しているんですが....
逆に,
paoneko> ある時期に1Byte＝8bitと定まったような気もするのですが、単なる私の妄想の
paoneko> 可能性大です。
paoneko> 何で定められているのでしょう?
「C の規格以外」で 1Byte = 8bit としているものがあれば, それが適
用される文脈では 1Byte = 8bit としなければならないことになります.
それが何かは知りませんが.
# Java で byte = 8bit にしたのは... きっとそこに手がかりがあるに
# 違いない.
あと, ネットワーク関係だと 8bit のまとまりを octet と言ってますよ
ね. これは多分 byte の大きさが環境に依存することを避けているんだ
と思います.
KATAYAMA Yoshio
ta...@hirata.nuee.nagoya-u.ac.jp (Takao Ono) writes:
>> そもそも2の補数形式である保証もないんじゃなかったっけ?
>ありません. 負の数の形式としては, 「2の補数」, 「1の補数」, 「符
>号+絶対値」のどれでもかまいません.
>その他であってもいいかもしれません.
C90 ではその他もよかったのですが、C99 では上記の三種のいずれかに
なりました。
--
片山＠ＰＦＵ
IKEDA Kenji
Yukio Sakuma <CXJ0...@nifty.ne.jp> writes:
> Pascalといっても人によって結構違うみたいです。
Wirth さんの本では、begin の後に文を書いてましたね。
while j<=n do {eliminate}
begin sieve := sieve - [j]; j := j+c
end
みたいな。2つくらいなら上記のようだけど、たくさんあると、
begin pi := 3/14159;
writeln(2.0,7,power(2.0,7));
spi := power(pi,2);
writeln(pi,2,spi);
writeln(spi,2,power(spi,2));
writeln(spi,4,power(pi,4))
end.
だったり、
begin try(18,27);
try(312,2142);
try(61,53);
try(98,868)
end.
だったり。あたしゃ、どうしても馴染めなかったです。
# 「↑」って、どう書くんでしたっけ?
--
池田研二 稲城駅前在住
Junn Ohta
sugi...@kyosai.or.jpさんは書きました。
> しかも、これで規格上OK（ANSI－C準拠）ってことですか？
> #なんかなー
うーむ、規格についてこの程度の認識(知識とか尊重す
る姿勢とか)しかない人と規格がらみの話を延々と議論
していたのか...。悲しすぎるぞ。(;_;)
Sugihara Yoshimi
> integral type の大きさに関して規格にあるのは
> ・char >= 8bit, short >= 16bit, long >= 32bit (long long >=
> 64bit)
> ・(char <=) short <= int <= long (<= long long)
> ・とにかく char 1個入る大きさが 1byte
> の 3つだけですから. したがって, 極端な話ですが
> char = short = int = long = long long = 64bit
> という処理系があったとしても (実際にはほぼ間違いなく存在しません
> が) それだけでは問題なしです.
> # もちろんこの処理系ではすべての型が 1byte ですが.
なる。
そういう定義されてたんですね。
私が参考にしてるのはMicrosoftのVC++6のヘルプ
なんですがそこにはlong=32bitになってたんですよね。
VC++6のヘルプはコンパイラ作ったところが書いてんだから
一番正確だろうという判断だったけど・・
うぬぬ。。。
#ちなみにANSI準拠じゃないところは準拠じゃないと書いてある
といず
Subject: Re: indent (Re: コーディング規約に ついて)
Kazuo Fox Dohzono san wrote:
> In article <9clpbg$mn3$1...@nn-tk104.ocn.ad.jp>
> といず<toys...@hotmail.com> writes:
>
> > $ indent -kr -ts 4 ファイル名
> > この形式が好きだったりする。
>
> indent: Command line: unknown parameter "-kr"
>
> # ってのが私の環境.
indentバージョン1.3 用の「The `indent' Manual」の0.02 版(1992年5月2日版)
より
`-kr' :
Kernighan & Ritchie スタイルは、以下のオプションの組合せと同等である:
-nbad -bap -nbbb -nbc -br -c33 -cd33 -ncdb -ce -ci4 -cli0 -cp33 -d0 -di1
-nfc1 -nfca -i4 -ip0 -l75 -lp -npcs -npsl -nsc -nsob -nss -ts8
> これは全く私の偏見 (?) なのですが,
>
> x >>= y;
>
> を
>
> x >> = y;
その スペースが一個入ってしまうだけで、動作が変わってしまうようなコーディ
ングは、トラブルに繋がることがあるので、そういう書き方はしないように規約を設け
るのが良いのではないでしょうか。
# 個人（単独）でやるなら、規約もなんもないけどね（当然か…）
> とフォーマットされてから GNU indent は使わないようにしています (修正さ
> れているのは確認しましたし, 人にも勧めることはあるんですけど).
たしかに余計なことをさせちゃうこともありますね。(indent)
Kazuo Fox Dohzono
といず<toys...@hotmail.com> writes:
> `-kr' :
> Kernighan & Ritchie スタイルは、以下のオプションの組合せと同等である:
> -nbad -bap -nbbb -nbc -br -c33 -cd33 -ncdb -ce -ci4 -cli0 -cp33 -d0 -di1
> -nfc1 -nfca -i4 -ip0 -l75 -lp -npcs -npsl -nsc -nsob -nss -ts8
indent: Command line: ``-cp33'' requires a parameter
> > x >>= y;
> >
> > を
> >
> > x >> = y;
>
> その スペースが一個入ってしまうだけで、動作が変わってしまうようなコーディ
> ングは、トラブルに繋がることがあるので、そういう書き方はしないように規約を設け
> るのが良いのではないでしょうか。
真面目に言ってるの?
他の複数文字からなる演算子 (<< とか sizeof とか) はどうするんですか?
Shinobu Kumaoka
Sugihara Yoshimi wrote:
> 私が参考にしてるのはMicrosoftのVC++6のヘルプ
> なんですがそこにはlong=32bitになってたんですよね。
> VC++6のヘルプはコンパイラ作ったところが書いてんだから
> 一番正確だろうという判断だったけど・・
それは、VC++6のヘルプのどこの話なんでしょうか？
VC++6のヘルプでも、「C/C++言語およびC++ライブラリ」の「基本型」の頁には、
「Microsoft固有の仕様」として、char,int,short,long.float,doubleそれぞれのサイズが
書かれています。
--
cog...@sp.hudson.co.jp
株式会社ハドソン
研究開発本部 研究開発課
熊岡 忍(Kumaoka Shinobu)
Hideo Sir MaNMOS Morishita
妙にけったいなコーディング規約の話も出てきますが、命名規則についてはど
うでしょうね。
私の場合
・なるべく略さない。
・ローカル変数は短くする。適当に略す。
・単語のつなぎは`_'は使わず、次の単語からCapitalizeする。
・変数／関数は小文字から始める。
・typedefはcapitalizeする。そのポインター型は最後をPにする。
くらいなんです。
ただ、
・主語と動詞と目的語がいい加減
なのは私の英語のセンスのなさのなせる業ですんで、攻めないでください。
あと、個人的には「命名はしっかりして、ほとんどコメントをつけない」って
のをやっていますが、これって人に嫌われますが、コード変更してコメントを
変えないって話も多くあるんで、貫いてます。
--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 ＭａＮＭＯＳ 英夫＠ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37
KATAYAMA Yoshio
ma...@cc.tsukuba.ac.jp (MAEDA Atusi (前田敦司)) writes:
>ところで、あれだけ規格の話をしていたのに、規格書を読んでないんでしょう
>か。
彼は規格書を読んだことがない旨の記事を投稿したことがあったと思い
ますが、私の勘違いでしょうか。
--
片山＠ＰＦＵ
paoneko
"Sugihara Yoshimi" <sugi...@kyosai.or.jp> wrote in message
news:9cno3v$bvp$1...@news.kyosai.or.jp...
> 私が参考にしてるのはMicrosoftのVC++6のヘルプ
> なんですがそこにはlong=32bitになってたんですよね。
> VC++6のヘルプはコンパイラ作ったところが書いてんだから
> 一番正確だろうという判断だったけど・・
なんて書いてあったか知らないけど、そのVC++では、longは32ビットなんでしょ
？
無茶書いて、ひとのせいにしないように。
Shinji KONO
In article <squk840...@stellar.co.jp> ,
man...@stellar.co.jp (Hideo "Sir MaNMOS" Morishita) writes
>あと、個人的には「命名はしっかりして、ほとんどコメントをつけない」って
>のをやっていますが、これって人に嫌われますが、コード変更してコメントを
>変えないって話も多くあるんで、貫いてます。
この関数は何をするのか、引数は何かぐらい、書いた方が良いと思います。
そういうコメントは便利ですね。
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)
Uchikawa Yoshiaki
最近は Indian Hillのコーディングガイドは参照されないのが
普通なんでしょうか?
＃あえて書くまでも無いとか
例えば
http://www.doc.ic.ac.uk/lab/secondyear/cstyle/cstyle.html
日本語版
http://dennou-t.ms.u-tokyo.ac.jp/arch/comptech/cstyle/cstyle-ja.htm
<3AEE5F77...@cr.info.hiroshima-cu.ac.jp>の記事において
e23...@cr.info.hiroshima-cu.ac.jpさんは書きました。
>> 読んだところで何も得しないとは思いますが、
>> 私は読むことをおすすめします。
この点は GNU Coding Standards 同様かな。時間が無ければ最後の
「Cプログラマへの十戎」だけ読んでみるとか。
--
yosh...@kt.rim.or.jp
(う)
といず
Subject: Re: indent (Re: コーディング規約に ついて)
Message-ID: <9cnt9m$h2l$1...@news2.rim.or.jp>
Kazuo Fox Dohzono san wrote:
> > `-kr' :
> > Kernighan & Ritchie スタイルは、以下のオプションの組合せと同等である:
> > -nbad -bap -nbbb -nbc -br -c33 -cd33 -ncdb -ce -ci4 -cli0 -cp33 -d0 -di1
> > -nfc1 -nfca -i4 -ip0 -l75 -lp -npcs -npsl -nsc -nsob -nss -ts8
>
> indent: Command line: ``-cp33'' requires a parameter
>
> > > x >>= y;
> > >
> > > を
> > >
> > > x >> = y;
> >
> > その スペースが一個入ってしまうだけで、動作が変わってしまうようなコーディ
> > ングは、トラブルに繋がることがあるので、そういう書き方はしないように規約を設け
> > るのが良いのではないでしょうか。
>
> 真面目に言ってるの?
>
> 他の複数文字からなる演算子 (<< とか sizeof とか) はどうするんですか?
<< とか sizeof とか離れちゃったら「バグ」ですね。
バグ報告すればよろしいのでは？
Kusakabe Youichi
<sugi...@kyosai.or.jp> wrote:
> なる。
> そういう定義されてたんですね。
> 私が参考にしてるのはMicrosoftのVC++6のヘルプ
> なんですがそこにはlong=32bitになってたんですよね。
あほか...こいつは。
> VC++6のヘルプはコンパイラ作ったところが書いてんだから
> 一番正確だろうという判断だったけど・・
> うぬぬ。。。
規格がどうのっていう話をするのに、どうしてそういうローカルな
ものを見てるんだろ。
ヘ_ヘ ____________________________
ミ・・ ミ vo...@merope.pleiades.or.jp
( ° )～ 日下部陽一
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kusakabe Youichi
> ・なるべく略さない。
> ・ローカル変数は短くする。適当に略す。
英単語で変数名をつけているときに「なるべく日本語のローマ字綴りを混ぜない」
ってのもやったほうがいいです。(データベースのカラム名なども)
> あと、個人的には「命名はしっかりして、ほとんどコメントをつけない」って
> のをやっていますが、これって人に嫌われますが、コード変更してコメントを
> 変えないって話も多くあるんで、貫いてます。
っていうか「コメントをつけなくてもわかるぐらいわかりやすく書く(で、つけな
い)」
っていうふうに言い方を変えるといいかも :)
Kusakabe Youichi
> wrote:
> > これは全く私の偏見 (?) なのですが,
> > x >>= y;
> > を
> > x >> = y;
>
> その スペースが一個入ってしまうだけで、動作が変わってしまうようなコー
ディ
> ングは、トラブルに繋がることがあるので、そういう書き方はしないように規約
を設け
> るのが良いのではないでしょうか。
i = -1; を i=-1; と書くのはよくないっていう話と似てますね。
(って、いまどきi=-1をi -= 1;と同じ意味に解釈するものは存在してないか...。
でもちょっと古い処理系だとありましたよね。
> # 個人（単独）でやるなら、規約もなんもないけどね（当然か…）
個人でも規約や規則は必要でしょうに。
といず
Subject: Re: indent (Re: コーディング規約について)
Message-ID: <9co9pa$qpg$1...@nn-tk104.ocn.ad.jp>
といず wrote:
> Subject: Re: indent (Re: コーディング規約に ついて)
> Message-ID: <9cnt9m$h2l$1...@news2.rim.or.jp>
> Kazuo Fox Dohzono san wrote:
> > > `-kr' :
> > > Kernighan & Ritchie スタイルは、以下のオプションの組合せと同等である:
> > > -nbad -bap -nbbb -nbc -br -c33 -cd33 -ncdb -ce -ci4 -cli0 -cp33 -d0 -di1
> > > -nfc1 -nfca -i4 -ip0 -l75 -lp -npcs -npsl -nsc -nsob -nss -ts8
> >
> > indent: Command line: ``-cp33'' requires a parameter
> >
> > > > x >>= y;
> > > >
> > > > を
> > > >
> > > > x >> = y;
> > >
> > > その スペースが一個入ってしまうだけで、動作が変わってしまうようなコーディ
> > > ングは、トラブルに繋がることがあるので、そういう書き方はしないように規約を設け
> > > るのが良いのではないでしょうか。
失礼しました。indentの動作について指し示して述べている訳ではないです。
Kazuo Fox Dohzono
といず<toys...@hotmail.com> writes:
> << とか sizeof とか離れちゃったら「バグ」ですね。
<<= が << と = に分かれてしまうのも「バグ」では?
> バグ報告すればよろしいのでは？
その程度で送ってたら向うが迷惑だと思う. 確か <<= のときはハッシュ関数
をごにょごにょして直しました.
# で, 「普通こういうツールは自分自身くらい処理出来る状態でリリースする
# よなぁ」と思った次第.
KATAYAMA Yoshio
vo...@merope.pleiades.or.jp (Kusakabe Youichi) writes:
>In article <9cnp2g$79n$1...@nn-tk103.ocn.ad.jp>, といず <toys...@hotmail.com
>> wrote:
>> > これは全く私の偏見 (?) なのですが,
>> > x >>= y;
>> > を
>> > x >> = y;
>> > とフォーマットされてから GNU indent は使わないようにしています (修正さ
>> その スペースが一個入ってしまうだけで、動作が変わってしまうようなコーディ
>> ングは、トラブルに繋がることがあるので、そういう書き方はしないように規約を設け
>> るのが良いのではないでしょうか。
>i = -1; を i=-1; と書くのはよくないっていう話と似てますね。
>(って、いまどきi=-1をi -= 1;と同じ意味に解釈するものは存在してないか...。
>でもちょっと古い処理系だとありましたよね。
今は「x >> = y;」が構文規則違反にならないと「ちょっと古い処理系」
と言われる時代です。:-)
>> # 個人（単独）でやるなら、規約もなんもないけどね（当然か…）
>個人でも規約や規則は必要でしょうに。
「個人なら規約がいらない」と言っている人は、その時々の気分で書き
方が変わるんでしょう。
--
片山＠ＰＦＵ
Junn Ohta
yosh...@kt.rim.or.jpさんは書きました。
> 「Cプログラマへの十戎」だけ読んでみるとか。
これじゃ「じっかい」ならぬ「じゅうえびす」ですぜ。:-)
Kazuo Fox Dohzono
doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:
> # で, 「普通こういうツールは自分自身くらい処理出来る状態でリリースする
> # よなぁ」と思った次第.
grep までやってみたのを忘れてました. GNU indent には <<= が登場しない
のでした.
Mon Feb 3 20:22:04 1992 Joseph Arceneaux (jla at churchy.gnu.ai.mit.edu)
* Version 1.2 released.
Tue Oct 10 17:20:36 1989 Jim Kingdon (kingdon at hobbes.ai.mit.edu)
* lexi.c (lexi): Handle "<<=".
Mon Sep 11 20:03:56 1989 Jim Kingdon (kingdon at apple-gunkies.ai.mit.edu)
* Indent 1.1 released.
直ってるのに次のリリースが遅かったのも使わなかった要因かも.
KATAYAMA Yoshio
doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:
>> << とか sizeof とか離れちゃったら「バグ」ですね。
><<= が << と = に分かれてしまうのも「バグ」では?
何時頃のことでしょうか。ANSI C 対応前なら、バグとは言えないでしょ
う。バグ的仕様ではあると思いますが。
--
片山＠ＰＦＵ
paoneko
"Kusakabe Youichi" <vo...@merope.pleiades.or.jp> wrote in message
news:void-02050...@newshost.ryukyu.ad.jp...
>
> 英単語で変数名をつけているときに「なるべく日本語のローマ字綴りを混ぜな
い」
専門用語（という程でもなくても）などで、手持ちの一般的な和英辞書ではどう
しても英訳がわからなくて悔しい思いをよくします。
グーローシェーディングのグーロー程度の単語ですら、検索エンジンでサイトを
探してしらべました。
タイヤのスキール音の「スキール」は、未だ見つけられず・・・。
Hideo Sir MaNMOS Morishita
In article <9codfn$rcp$1...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) writes:
> fj.comp.lang.cの記事<9co9d1$n2e$1...@news2.rim.or.jp>で
> yosh...@kt.rim.or.jpさんは書きました。
> > 「Cプログラマへの十戎」だけ読んでみるとか。
>
> これじゃ「じっかい」ならぬ「じゅうえびす」ですぜ。:-)
最初が西宮…
Hideo Sir MaNMOS Morishita
In article <void-02050...@newshost.ryukyu.ad.jp>,
vo...@merope.pleiades.or.jp (Kusakabe Youichi) writes:
> "Sir MaNMOS" Morishita) wrote:
> > ・なるべく略さない。
> > ・ローカル変数は短くする。適当に略す。
>
> 英単語で変数名をつけているときに「なるべく日本語のローマ字綴りを混ぜない」
>
> ってのもやったほうがいいです。(データベースのカラム名なども)
>
> > あと、個人的には「命名はしっかりして、ほとんどコメントをつけない」って
> > のをやっていますが、これって人に嫌われますが、コード変更してコメントを
> > 変えないって話も多くあるんで、貫いてます。
>
> っていうか「コメントをつけなくてもわかるぐらいわかりやすく書く(で、つけな
> い)」
> っていうふうに言い方を変えるといいかも :)
「コメントをつけなくても、わかるはず」とは言っているんです。
Junn Ohta
pao...@e-game.co.jpさんは書きました。
> タイヤのスキール音の「スキール」は、未だ見つけられず・・・。
squeal でしょ?
Hideo Sir MaNMOS Morishita
In article <22507.9...@rananim.ie.u-ryukyu.ac.jp>,
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 河野 真治@琉球大情報工学です。
>
> In article <squk840...@stellar.co.jp> ,
> man...@stellar.co.jp (Hideo "Sir MaNMOS" Morishita) writes
> >あと、個人的には「命名はしっかりして、ほとんどコメントをつけない」って
> >のをやっていますが、これって人に嫌われますが、コード変更してコメントを
> >変えないって話も多くあるんで、貫いてます。
>
> この関数は何をするのか、引数は何かぐらい、書いた方が良いと思います。
> そういうコメントは便利ですね。
私の場合、そういうことは、別のドキュメントに記載されることになっていま
す:-)
先日も私のプログラムを別の方がドキュメントになさいましたが、あまり、質
問がなかったことを見ると(できあがったものは大変満足するものでした)、
「あ、やっぱり、そんなにコメントは必要ないんだ」ってのを実感しました。
＃実際、私も他人のコードを読むときにも全然コメントなんか読んでいないも
＃んね。
Kazuo Fox Dohzono
ka...@pfu.fujitsu.com (KATAYAMA Yoshio) writes:
> ><<= が << と = に分かれてしまうのも「バグ」では?
>
> 何時頃のことでしょうか。
<9coep7$poj$1...@news2.rim.or.jp> にも書きましたが, 最初のリリースが Jul '89,
次が Sep '89, "<<=" の修正が Oct '89 です.
# でも const/volatile がハッシュ表に載ったのが Jul '92 という….
> ANSI C 対応前なら、バグとは言えないでしょう。
ANSI style には最初から対応していたと思います. 本体の方にも
Wed Jun 21 21:28:37 1989 Roland McGrath (roland at hobbes.ai.mit.edu)
* indent_globs.h: Use ANSI token pasting #ifdef __STDC__.
なんていう記録がありますからそれはちょっと理由としては弱い気がします.
# 実は gperf (完全ハッシュ関数生成機) の単なるサンプルだという説も.
Yuuichi Naruoka
Shinji KONO wrote in message <20432.9...@rananim.ie.u-ryukyu.ac.jp>...
>河野 真治@琉球大情報工学です。
>
>In article <3AEE5F77...@cr.info.hiroshima-cu.ac.jp> ,
> Hironori FUJII <e23...@cr.info.hiroshima-cu.ac.jp> writes
>>> 私としては { の位置がなんか宙ぶらりんに見えるので、少し気持ち悪いので
>>これは私も同感です。
>
>それは、つまり、Unix のカーネルを読んだことがないってことですよね。
>kernel style とか呼ばれることもあります。ま、慣れですね。
「宙ぶらりん」の解釈ですが、私は
if (cond1)
{
if (cond2)
stmt1;
else
stmt2;
}
は気持ち悪いが
if (cond1)
{
if (cond2)
stmt1;
else
stmt2;
}
あるいは
if (cond1)
{
if (cond2)
stmt1;
else
stmt2;
}
なら良い、と解釈したのですがそういうことではないのでしょうか？
# ちなみに私は真ん中タイプです。
--
成岡＠ＤＴＩ(yn...@jade.dti.ne.jp)
Murakami Hiroshi
sa...@eye.kisarazu.ac.jp
In article Message-ID:<9clhl7$goh$1...@nn-tk102.ocn.ad.jp> at fj.comp.lang.c
"paoneko" wrote:
= for (i=0; i<100; i++) というケースでは、いかなる環境でも i は int でい
= いですよね？
本当ですか?
--
Yasuyuki SAITO
paoneko
<sa...@eye.kisarazu.ac.jp> wrote in message
news:9d0gk3$fvr82$1...@ID-74790.news.dfncis.de...
> In article Message-ID:<9clhl7$goh$1...@nn-tk102.ocn.ad.jp> at
fj.comp.lang.c
> "paoneko" wrote:
>
> = for (i=0; i<100; i++) というケースでは、いかなる環境でも i は int
でい
> = いですよね？
>
> 本当ですか?
「本当ですか？」っていうのは、（intでは）まずいケースがあるんじゃないの
？ってことですよね？
うーん、ギブアップです。ダメなケースがあるなら教えてください。
Kazuo Fox Dohzono
"paoneko" <pao...@e-game.co.jp> writes:
> > = for (i=0; i<100; i++) というケースでは、いかなる環境でも i は int
> でい
> > = いですよね？
> >
> > 本当ですか?
>
> 「本当ですか？」っていうのは、（intでは）まずいケースがあるんじゃないの
> ？ってことですよね？
> うーん、ギブアップです。ダメなケースがあるなら教えてください。
無いんじゃないかなぁ.
5.2.4.2.1 Sizes of integer types <limits.h>
-- minimum value for an object of type int
INT_MIN -32767 // -(2^15-1)
-- maximum value for an object of type int
INT_MAX +32767 // 2^15-1
# int が #define されてたり, とか.
sa...@eye.kisarazu.ac.jp
In article Message-ID:<9d0hvu$njj$1...@nn-tk105.ocn.ad.jp> at fj.comp.lang.c
"paoneko" wrote:
= <sa...@eye.kisarazu.ac.jp> wrote in message
= news:9d0gk3$fvr82$1...@ID-74790.news.dfncis.de...
= > In article Message-ID:<9clhl7$goh$1...@nn-tk102.ocn.ad.jp> at
= fj.comp.lang.c
= > "paoneko" wrote:
= >
= > = for (i=0; i<100; i++) というケースでは、いかなる環境でも i は int
= でい
= > = いですよね？
= >
= > 本当ですか?
=
= 「本当ですか？」っていうのは、（intでは）まずいケースがあるんじゃないの
= ？ってことですよね？
= うーん、ギブアップです。ダメなケースがあるなら教えてください。
あ，いえ，char やunsigned int などでも良いのではない
かなぁと思った次第です．
# 趣旨がずれてました．移植のときに駄目になるという話で
# はないです…．
--
Yasuyuki SAITO
Shinobu Kumaoka
sa...@eye.kisarazu.ac.jp wrote:
> あ，いえ，char やunsigned int などでも良いのではない
> かなぁと思った次第です．
unsigned intはともかく、charでは速度低下の可能性がある気がします
--
cog...@sp.hudson.co.jp
株式会社ハドソン
研究開発本部 研究開発課
熊岡 忍(Kumaoka Shinobu)
Narita Takaoki
<3AF63382...@sp.hudson.co.jp>の記事において
cog...@sp.hudson.co.jpさんは書きました。
> sa...@eye.kisarazu.ac.jp wrote:
>
> > あ，いえ，char やunsigned int などでも良いのではない
> > かなぁと思った次第です．
>
> unsigned intはともかく、charでは速度低下の可能性がある気がします
8bit CPU って可能性も。
--
成田 隆興 ＠ エー・アイ・ソフト株式会社 NB 推進部
E-mail tak...@aisoft.co.jp
『十分間で決断し、短い理由を添えよ』
Narita Takaoki
<squ8zkg...@stellar.co.jp>の記事において
man...@stellar.co.jpさんは書きました。
> In article <void-02050...@newshost.ryukyu.ad.jp>,
> vo...@merope.pleiades.or.jp (Kusakabe Youichi) writes:
> > In article <squk840...@stellar.co.jp>, man...@stellar.co.jp (Hideo
> > "Sir MaNMOS" Morishita) wrote:
> > > ・なるべく略さない。
> > > ・ローカル変数は短くする。適当に略す。
:
> > > あと、個人的には「命名はしっかりして、ほとんどコメントをつけない」って
> > > のをやっていますが、これって人に嫌われますが、コード変更してコメントを
> > > 変えないって話も多くあるんで、貫いてます。
> >
> > っていうか「コメントをつけなくてもわかるぐらいわかりやすく書く(で、つけな
> > い)」
> > っていうふうに言い方を変えるといいかも :)
>
> 「コメントをつけなくても、わかるはず」とは言っているんです。
私も似たような方針でコードを書いていますが、以前「わかりづらい？」
と訊いてみたところ、「いえ、結構わかりやすいです」と(お世辞かもし
れないけれど ^^;)返事を得ました。
結局、トリッキーなところや、意図するところが一瞥して読み取れない
ようであったりするところで、その意図をコメントするくらいで、ベテ
ランにとっては多くは十分なようです。
むしろ一読読み下しで分かるようなコードや、そこまでの文脈から何を
意図しているかすぐ推測できるようなところでの、やたらなコメントは
うるさいだけの様で。
# もちろん関数の頭のコメント(引数の説明とか)はあった方が良いです
# が。
でも、C、C++、Java だと Smalltalk の様には、関数(メソッド)名がき
れいに文になってくれない。(;_;)
# 命名をしっかりしてるとやたら長い識別子になって寸刻を争う修羅場
# では、自らを呪うこともありますが、じゃぁそれで短縮して一瞥して
# も意味がわからないような識別子にすると良いかってぇと、えてして
# 修羅場の鶏頭には意味不明な文字列になってしまって、結局余計に難
# 儀したりする。(^^;
ハンガリアン記法も何かの都合で型変えちゃったときにテンテコ舞いに
なるし、第一あっしのざるな記憶力では、何がどの型だったかすぐ忘れ
ちまって全然嬉しくない。それだったらその変数とかが何を意味するも
のかをしっかり命名しておいた方が、自ずと型も推測できるので嬉しか
ったり。
Kazuo Fox Dohzono
tak...@aisoft.co.jp (Narita Takaoki) writes:
> 8bit CPU って可能性も。
私なら i が文字を表さないのならやっぱり int (か, unsigned) を使います.
6.2.5 Types
[#5] An object declared as type signed char occupies the
same amount of storage as a ``plain'' char object. A
``plain'' int object has the natural size suggested by the
architecture of the execution environment (large enough to
contain any value in the range INT_MIN to INT_MAX as defined
in the header <limits.h>).