今回のトピックは試験問題が遡上にあがっています。
試験というからには前提となる「ルール」があるはずで
日本国の教員資格の試験であれば、それは JIS 規格であるべきでしょう。
gcc とか (以下略) の個別の実装の話を出すのは
(カルマを減らす or ちゃちゃいれ or 他人をおちょくる or so on が目的でなければ)
そろそろ潮時かな～と愚考する次第です。
# もっともこの話題の発端は Oliver 氏の伝えるところの
# 教授氏のmath-out [tuxedo.org]な話から始まっているので
# 結局はこの教授氏を説き伏せるのにどちら (規格 or 実装) が
# 有効かという話に帰結したりするのかも。
入力関数はscanf()? (スコア:4, おもしろおかしい)
main()の返り値がvoidだ、というのは「タイムカードを押さずに帰宅する」のと同等の行為で、「数学上美しくない」といわれても困る。ここは、野暮の極みの手続き問題なのだから。
# そりゃま、exit()の形で「担架に乗せられて搬出されちゃった」のなら、タイムカードの始末はOSに移管されますが…。
むしろ興味を持ったのは、問1の設問2の空欄⑧。
多分scanf()を使って欲しいんでしょうが、scanf() は挙動が不審で、他人に使わせるものには間違っても使いたくない。
で、⑧だと定義文も複文もOKなので、かなりの抵抗ができちゃう。
採点の際は、その辺、どう対処したのかねぇ…。
Re:入力関数はscanf()? (スコア:1)
ううむ (スコア:1)
生徒の書いた謎なプログラムを読む能力を試験しているのだろうか．
私の場合，載っていた C のプログラムでは
私の場合，これでは教員になれないな． 一応教員免許は持ってるけど :-) そうそう，最後の問題，答えは「スタックオーバフロー」なのかなぁ． 見ためは無限ループっぽいけど，サブルーチンコールを繰り返してスタックを食い潰していますね．
Re:ううむ (スコア:2)
# 後、別会社の作った謎なソースを読む能力にも転用可。
# 合格した方、同僚になってください。(;_;)
Re:ううむ (スコア:1)
ソースコードが画像 (スコア:1)
異様にフォント汚いし。
穴埋めの空欄をどう表現するか困ったのかもしれないが、空欄のとこだけ画像にするとか、スタイルシートで表現するとか、やりようはあるだろうに。
それからCOBOLや生CやFortranが使われているのが面白い。
今から始める人のための情報処理教育にこんなの使ってもしかたないような気がするのですが・・・まぁ基本は何の言語でも同じなんでしょうけれども。
Re:ソースコードが画像 (スコア:1)
<p align=""left"> がたくさん並んでるし。
まぁ…、でも、ましな方かな
Re:ソースコードが画像 (スコア:1)
間違えました。 <p align="left"> でしたね。すみません。
Re:ソースコードが画像 (スコア:1)
あの問題は丸つき数字も画像になっているけど、
おそらくOCRから読み込んだんでしょう。
現在の高校のプログラミング教育のカリキュラムが
「こんなの」しか想定していないからです。
商業高校がCOBOLを捨てきれないのは仕方ないけど、
FORTRANやBASICはさっさと捨てるべきだと思う...
今いる高校教諭がBASIC/FORTRAN/COBOLしか知らない/教えられないから
カリキュラムの変更ができないのはしかたがないにしても、
10年後、20年後にもそういう教員ばっかりというのはやばいぞ。
Re:Fortranは要らない？？ (スコア:2)
ンと解析のフレームワークが FORTRAN では確実に開発が破綻します。
速度が必要なところだけ、FORTRAN なりアセンブラで書けばいいのであって
古い人が「FORTRAN でないと駄目だ」というのは、多くの場合は単に彼らが
FORTRAN しか理解できないからという以上の理由はないです。
# 実際、BELLE実験 [bsunsrv1.kek.jp] の解析系は
# 数値計算が厳しい一部を除いて基本的に C++ で開発されています
# オブジェクト指向オンラインデータ収集システム [tohoku.ac.jp] のような物を開発している人もいます。
まぁ物理やさんの仕事はプログラミングではなくて物理解析なので
主従を間違えちゃいけないんですが、目的は道具を選ぶんですよねこれが。
Re:Fortranは要らない？？ (スコア:2)
そう言えば、十年近く前から CERNlib の C++ 移植って話は聞いているんですが、現状どうなったんでしょ？ > 粒子物理関係者各位
Re:ライブラリレベルの話なら (スコア:2)
「伝統の資産」の方が適切ですかね。 要するにライブラリのコンパイルに f77 が要る、という話です。
# で、CERNlib が cc でコンパイルできれば...という事。
# 「過去の資産」なら SLAC [stanford.edu] が配布してた HandyPack (?) だか
# その辺ですかね (自信なし)。
Re:CERNlib の C++ 移植 (スコア:2)
じゃあ粒子物理業界としては FORTRAN らぶな先生が引退して ついでに PAW のコマンドが non-FORTRAN 化されれば FORTRAN 文化圏でなくなるという事ですか...。
# 一昔前は UNIX と C の区別がつかない先生が
# 某大学にいらっしゃったという噂も聞いたものだが。
Re:CERNlib の C++ 移植 (スコア:2)
私は論文書きやシミュレーションの解析に使ってましたけど、現時点で
どれくらい使われているんだろう。
問題点として、オブジェクト指向は FORTRAN や C のような手続き型言語と比べて
初めに覚えなければいけないことが多いというのと、教えられる人材が極めて少ない
という問題があるのかと思われますが。
Re:言語の選択 (スコア:1)
頭のなかで「生Cは面倒くさいから使いたくないなぁ、C++あるんだし」みたいな観念ができている故の発言でした。
低レベルでのコンピュータの挙動を理解しやすいことや、多くのプラットフォームで使えることを考えると、今から始める人にでも生Cはとても有用ですね。
試験，といえば (スコア:1)
そういえば，LPI という，Linux の認定試験があるが，その模擬問題 [yesitis.co.jp]というのもかなり素晴らしい． 素晴らし過ぎて，私にはわからない問題がいくつもありました．
Re:試験，といえば (スコア:2)
Re:つながらない？ (スコア:1)
しかし、void main(void)って．．．
＃確かに一部の入門書にはそう書いてあるのがあるけど。
Kiyotan
void main(void) (スコア:1)
# 他にこの形式のmain関数を使うのってあったかな？
巧妙に潜伏したバグは心霊現象と区別が付かない。
Re:つながらない？ (スコア:1)
/教科に関する科目(III)/情報 と選んでいくと少しは?かもしれず。
しかし、「情報」と「情報技術」と「情報処理」が別個の試験というのもアレゲかも…
Re:みんなで void main (スコア:2, 興味深い)
メソッドは副作用があり、戻り値がない。エラーはExceptionなどの別の方法で通知。
ファクション(関数)は副作用がなく、戻り値がある。戻り値の算出に引数以外に依存すべきではない。
というのが「正しい」姿だからだそうだ。で、mainはメソッドなので、voidでなければいけないそうだ (うちのオブジェクト指向論教授談)。
exit(1)の1ってmain()の戻り値やん、と反論したら、いやー
returnじゃないから、それはthrowと同等だ。とか云々で現実と理想のギャップについて教授と喧嘩してしまった。関数型言語だったら、ここいらは美しいんだけど、imperativeだとね。
Javaの静的タイピング らぶ な教授なんだけど、java.lang.Objectにcastしまくりな現状とRubyみたいな完全動的タイピングについても意見を求めたら.... ってそれは別の話。
Re:みんなで void main (スコア:2)
Re:みんなで void main (スコア:2)
自己フォロー。
教授氏の言わんとするところは、main() が関数であるためには、
のように「return の値は引数だけに依存すべき」だという事ですね？# じゃあ isprint(3) は locale の状態に依存するから
# void じゃないといけないって事？
Re:envp (スコア:2)
差し支えなければ extern char **environ か getenv(3) を使ったほうがいいでしょう。
Re:envp (スコア:2)
(「引数だけ」に依存した return の例示なら argc で十分でしょう？) まあ気持ちは分からなくもないんですが これだけ C/C++ が普及 (特に Windows) するとねぇ...。
# Win な若人に「この bzero() って何ですか？」って
# 聞かれたときには「時代は変わった」と思いましたです。
# まあ書いた人にも「今時なら memset() 使えよ」とか
# 思いましたけど。
Re:みんなで void main (スコア:1)
UNIX 系の C の場合，そもそも main() って，なんとかcrtかんとか.o というスタートアップルーチン（？）からコールしている関数に過ぎないのだけれど．というわけで，引数と戻り値については，単になんとかcrtかんとか.o との摺合わせ，という話になるのではないか，と思います．
あと，ライブラリ関数 exit(3) は (linux では) システムコール _exit(2) を呼び出すようです． このシステムコールは，二度と呼び出し元の関数へは制御は戻らないので，「戻り値」というのはまた別だと思います．
規格は規格，実装は実装 (スコア:1)
サブジェクトの通り :-)
ま，この試験の場合は規格の方に従うべきで，特定の実装に依存するのは好ましくないとは思いますが． ま，UNIX 系 OS ではそういう仕組みになってることが多いので，void main(void) でも矛盾しない実行ファイルが生成できる，というだけの話．
Re:実装なら、現実の実装 (スコア:2)
更に言えば、DOS/Windows だって int main ですね。 但し「void でも構わない」事が公式に認められているだけで。
void でも構わないとベンダが言明している UNIX のコンパイラは寡聞にして聞いたことがありません (探せば見つかるのかも知れませんが)。
# ちなみに C# では main の戻り値は int でも void でも
# 構わないことになっていたと思います。
# この辺は Java の void な main の向うを張ったのか
# Microsoft の C 方言の名残なのかは意図不明。
まさにこのコード（Re:そんなこと聞いてないんだけど (スコア:2)
...というだけではナンなので。 :-)
今回のトピックは試験問題が遡上にあがっています。 試験というからには前提となる「ルール」があるはずで 日本国の教員資格の試験であれば、それは JIS 規格であるべきでしょう。 gcc とか (以下略) の個別の実装の話を出すのは (カルマを減らす or ちゃちゃいれ or 他人をおちょくる or so on が目的でなければ) そろそろ潮時かな～と愚考する次第です。
# もっともこの話題の発端は Oliver 氏の伝えるところの
# 教授氏のmath-out [tuxedo.org]な話から始まっているので
# 結局はこの教授氏を説き伏せるのにどちら (規格 or 実装) が
# 有効かという話に帰結したりするのかも。
Re:みんなで void main (スコア:1)
仮にこの定義を受け入れたとすると、現在のコンピュータでは、関数を表現することは不可能だと思います。
単に引数から戻り値を得るだけの用途でも、時間と空間(記憶域)を消費するという副作用をもちますから。
なので数学的な意味での関数と、コンピュータ用語の関数では、名前が似てるだけで異なるものであるとして扱ったほうがいいように思います。
Re:みんなで void main (スコア:1)
排他的事象なのでしょうか?
どっちにせよ、Cの関数の返し値が、数学でいう関数の返し値と
同じものかどうか怪しいっすね。
たんに、数学のほうの返し値の猿真似(???)な書式をCは使える、意味が同じかどうかはさておき、というだけじゃないかと。
Re:みんなで void main (スコア:1)
理想は理想ですが、
数学的(なのですね?)な主張に対して「自分の」主張だと言えるのかどうかは、
また別の問題かと。
#ただ、名前の定義を間違っているような気がするんで、
#数学的に正しい主張かどうか?がまず心配ですが。
Re:えっ？ (スコア:1)
今はint main(void)と書いたりしてますけど。
MS-DOSとかWindowsのDOSプロンプトだったらmainをvoid型に
しても別にいいかもとか思ったりします。
Re:えっ？ (スコア:2)
GUI アプリケーションなら戻り値を使ったりする局面が多いとも思えないので「まあ void でもいいか」と思うのですが、Windows GUI の main (にあたるもの) は WinMain() ですからね...。
# VC++ とかで make すると
# ・main は MZ
# ・WinMain は PE
# のスタートアップにリンクされるんですかね？
# > Windows SDK 識者な方
Re:えっ？ (スコア:2)
# Cygwin の bash で書ければいいんだが
# 日本語のファイル名が平然とだなぁ...
Re:えっ？ (スコア:1)
しても別にいいかもとか思ったりします。
確かに MSDN library に「main および wmain 関数が void 型を返すように宣言することができます」と書かれていますね。exit で終了コードを返すかどうかも任意のようです。
(個人的好みとして)終了コードを返さないで終わられると makefile に書きづらくなるので避けたいところですが。
いろいろ使えます (スコア:1)
参考に・・・
終了ステータスについて [wakayama-u.ac.jp]
man system [linux.or.jp]
man bash [linux.or.jp]
Re:正しい main (スコア:3, 参考になる)
ということで、main関数のもっとも短い形は、
int main();
になりました。
#C99は、指定初期化子なんてのもあって、かなり使いたくなります。
#gccでは、ラベルのような構文で同じ事が出来ていたようですが。
Re:えっ？ (スコア:2)
私の学校の環境だけ?
#ちなみに当方、main()派。最初にそう習ったので…#1年後期以降の課題のサンプルとして配られるコードではint main(...)も多いです。
#が、自分で一から書く時には大抵main()にしてしまうです。
#まあ、プログラマーを育てる為の授業でなく、あくまで実験の道具としてのCらしいですから。
#void mainも「こういう書き方をする人もいる」と習いましたが、実際書いたことはないです。
Re:えっ？ (スコア:1)
これって「模範回答」なのでしょうか？ ま，突っ込んでみましょう :-)
入力される数値の数が 3 個よりも少ない場合もあり得ます．
判別式自体は正の値なので，解の公式を計算しようとしますが，分母が 0 になるので，「0 で割り算できないぞ」例外で異常終了してしまいます．
同じ内容が繰り返し何度も出てくるのは，「駄目なプログラム」の典型的な特徴です． 修正する時のことを考えると，修正箇所が１箇所だけの方が保守は簡単ですね．
浮動小数点型の数値は変換・演算で誤差が出るので，== による比較は思ったように動かないことがあります（というか，動かない，と思った方が良いでしょう）． ある程度の不正確さを容認して d*d<ε のように近似的に判定した方がいい場合が多いです． この問題の場合は微妙なところですが．
pow() 自体は，pow(2.5, 3.5) のような場合にも対応しているので，内部では exp(log(a)*b) のような計算をしてると思います． FPU によっては built-in かもしれませんが．． あと，サブルーチンコールのオーバヘッドもあります．２乗であれば，a*a のように書いた方が計算量も少なく，サブルーチンコールも生じる可能性は少ないでしょう．
これらの修正を全部行うと，「説明用」のプログラムとしてはちょっと見通しが悪くなるかもしれませんが．
まぁ，プログラム自体の評価としては，大学だと，教養部での「パソコンでプログラム書いてみましょうね」レベルの講義だったら，ま，こんなものなのかもしれません． 学部の「数値計算」の講義だとしたら…「単位をとるための講義」と割り切った方が良いでしょう．
「数値計算」の議論・技術は言語・CPU・OS を越えて（おそらく）一生ものの技能になると思います． というわけで，授業とは別に，気合いを入れて自習して身に付ける価値はあると思います．
Re:えっ？ (スコア:1)
b と sqrt(D) の絶対値が近い場合の桁落ちを防ぐ工夫ですね． 参考になります．
もう片方の解は c/(x1*a) で求まるので，この場合，生じるのは丸め誤差だけかな．
ええと，一応説明しておくと，桁落ち，というのは，たとえばこんな感じ．
この例では，有効数字 8 桁の 2 つの数の引き算を行った結果得られる数値の有効数字が 2 桁になってしまってますね． このように絶対値が近い数で引き算を行うと，有効数字の桁数が減ってしまう現象が起きます． これが桁落ち．今の２次方程式の解の公式の例では，±√ の２つの解の片方は異符号の演算なので桁落ちの条件に引っかかりますが，もう片方は同符号の演算なので，桁落ちは発生しません． まず，この桁落ちしない方の解を採用し，もう片方の解は上記の式で導きます． この場合は乗除算だけで，丸め誤差の発生がありますが，どのみち丸めが発生するのは有効桁より下なので，有効桁数の現象は生じない，ということになります．
というところでよろしいでしょうか，先生．
Re:えっ？ (スコア:2)
叩いて下さい > 識者
Re:これで、*str != NULL (スコア:2)
Re:これで、*str != NULL (スコア:2)
Re:これで、*str != NULL (スコア:2)
# だって Makefile の中で sed 使ってるんだもん。
Re:これで、*str != NULL (スコア:2)
# そろそろ見てる人も減ってきたか...
え～と、そういう観点でなくて、単に cc (せいぜい cpp まで) 以外を 「醜い『C』コンテスト」のエントリー作品の Makefile で使うというのは、真の漢 :-) の道具立てとしてはちょっといかがなものかな～、という程度の意図です。 (やっぱり『C』のコンテストなんですから、道具は『C』コンパイラ周りに絞って戴くのが漢の美学というものかと)
オフトピック（Re:main()） (スコア:2)
私的には「御意」なのですが、どこかの海外な方が「ソースもプロポーショナルフォントの方が読みやすい」という論陣を張られていたのを記憶しています。
ちょっと思い出せないのですが、どなたかリソースへのポインタをご存知ありませんか？ (何かのフリーソフトの作者だったかな？)Re:オフトピック（Re:main()） (スコア:2)
# しまったな～。正月休みに読む本が... (-_-;
Re:BASIC風 (スコア:2)
ん～、昔 Turbo-C とか LSI C-86 で作ったのを X に移植するために、そういう奴を自分でも作った記憶がありますね。 そういう人は結構いるんじゃないでしょうか？
結局、私は PUT とか GET の実装が面倒だったので途中で放り投げましたけど。Re:こっちのほうが、マシでしょう。 (スコア:2)
新出先生の UNIX like tools みたいに確たる理由がある (身辺に non-ANSI な処理系が残っている、とか) のであれば別に構わないでしょうし 学生さんに教えていない (自分用使い捨て only) であれば全然構わないと思いますが。
K&R の文法を使っても書き方がきちんとしていれば (signed/unsigned の非互換性の問題は置いといて) C89 でも C99 でもコンパイルできるはずです。 問題は、K&R の文法で「きちんと」書くのは lint でもないとやってらんない、(と私は思う) 事ですが。