仕様書 http://www.open-std.org/jtc1/sc22/wg14/www/standards [open-std.org] ここの WG14 N1570 を読んでみました。確かに >5.1.2.2.1 Program startup >It shall be defined with a return type of int とも書いてあるんですが、最後に >or in some other implementation-defined manner. と書いてひっくり返してあります。そんなわけで言語仕様上は、 #2638323 に tenokida さんが書かれているように、 実装依存という
The rationale for the C99 standard [open-std.org]の5.1.2.2.1を見ると、 そのsome other implementation-defined mannerってのは、おそらく引数の事で、戻り値の型では無いと思う。
While many implementations support more than two arguments to main, such practice is neither blessed nor forbidden by the Standard; a program that defines main with three arguments is not strictly conforming.
アルゴリズムのお勉強 (スコア:0)
コンピュータサイエンスの初級コースってのが
どんな教育をする場かは知りませんが、
アルゴリズムのお勉強とかは、C/C++ がベストと思うんですよね。
使える機能がもっとも原始的という意味で。
ま、最低、Java でもいいとは思うけど。
Re:アルゴリズムのお勉強 (スコア:1)
ちなみにKnuth先生の本では, 仮想機械の機械語を使って記述されてますね.
高級言語では, アルゴリズムを評価する基準の一つである計算量について評価が出来ないので, 機械語を使うべきなのだとか.
Re: (スコア:0)
そこはPascalだろ。
コンパイラがやってはいけないことをやってはいけないと言ってくれない言語を初心者に書かせるのはちょっと。
Re: (スコア:0)
同意。アルゴリズム+データ構造=プログラムを体得するのに,
Pascalは良い選択の一つだと思ふ。Cを学ぶのは,それからでも
遅くないです。
Re: (スコア:0)
わたしは独学でBASICで,大学に入ったらPascalでした.
私が卒業後,すぐC派閥に押されてCに変わり私の教授は嘆いてましたが.
Re: (スコア:0)
いいかも。オブジェクト指向周りの機能は、最初は不要だから、最近の言語はどれも機能が多すぎるし。
Re: (スコア:0)
言語に依存しない「アルゴリズム+データ構造」を学ぶには、やはりSICPでSchemeだと思ってたのに
今はもう違うのね。本家もPythonを使ってるみたいだし。
オブジェクト指向も3章読んで理解したのだが。
Re: (スコア:0)
Pascalいいよね教育向き
最近さっぱりらしいけど、あとで実用性がないとか言われるからかなぁ
Re: (スコア:0)
数あるプログラミング言語でも飛び抜けて多機能なC++を、「使える機能がもっとも原始的」とは恐れいった
Re: (スコア:0)
そうかもしれない。私がイメージしたのはGCとかに邪魔されず。
基本的なデータ構造を自作しても効率が悪くないくらいに原始的という感じ。
確かにSTLとか使っちゃったらアルゴリズムのお勉強にならないね(^^;
Re: (スコア:0)
STLの存在がデータ構造のアルゴリズムの学習を妨げるとしたら、qsortがあるCだってソートの学習に向いていないことになってしまう
ある機能が学習の妨げになるというのなら、それを使わないようにすればいいだけ
それに、より原始的なほうが適しているというのなら、マシン語やアセンブリ言語から学ぶべきだし、
GCがアルゴリズムの学習を阻害するというのも意味がわからないな
Re:アルゴリズムのお勉強 (スコア:1)
> GCがアルゴリズムの学習を阻害するというのも意味がわからないな
ここだけ説明、GC のある言語でマージソートのようなメモリを
確保するアルゴリズムを実装すると、実装に仕方にもよるけど、
正体不明の速度低下を引き起こすことがあったりするんですよ。
私自身の体験ですけどね。
で、アルゴリズムの素の性能を見極めるときの邪魔にならないかなぁと思ったと。
Re: (スコア:0)
教科書通りに再帰的なコードを書かなければ問題はないかと。
現場では絶対に再帰的なソートなんて書きませんし。
スタックオーバーフローを避けるために通常ループに展開します。
演算子とループ構文とIf構文と配列だけで出来ますから。
なんで再帰的なソートを初めに教えるのか理解に苦しみます。
更に、マージソートは改善策が沢山在って(以下うんちく
Re: (スコア:0)
わかりにくい皮肉だな
Re: (スコア:0)
> スタックオーバーフローを避けるために通常ループに展開します。
で結局、配列側でオーバーフローするんでしょ?(以下うんちく
Re: (スコア:0)
なんで再帰的なソートを初めに教えるのか理解に苦しみます。
教育の初歩の段階だからこそ数学的な定義に基づいてやってるんじゃないんですかね。
Re: (スコア:0)
> 現場では絶対に再帰的なソートなんて書きませんし。
まあ結果的にはそのとおりだけど。
> スタックオーバーフローを避けるために通常ループに展開します。
通常C言語ですらライブラリがあるのに自分で劣化コピーの再発明なんかしねーよ。逆にアルゴリズムの教育用ならコンパイラが末尾呼び出しの最適化すらできない「現場」とやらの都合を持ち込むほうがおかしい。
Re: (スコア:0)
コードがループで書かれても、このアルゴリズムは再帰的なんだから、再帰的なソートを教えるのは当たり前じゃないかな。
Re: (スコア:0)
最近の gcc とか再帰をループに展開してくれますよね。
Re:アルゴリズムのお勉強 (スコア:1)
どうして無限に深いスタックのあるプッシュダウンオートマトンや無限に長いテープのあるチューリング機械が計算機のモデルになるのかいつも不思議で仕方ない。それこそ無限のほうが何かと楽になるという数学屋の都合にすぎないと思うんだが。
Re: (スコア:0)
2000年という有限ですら目を背けてたのがコンピュータサイエンスの世界ですから。
Re: (スコア:0)
数学屋の都合というのはその通りと思いますよ。
もともと現実のコンピュータの能力をモデル化するためじゃなく、
数学の限界、すなわち人間の思考の限界をモデル化するためのものですよね。
だから、考えられる限り最高の計算能力を持ったコンピュータである必要があった。
Re: (スコア:0)
C++がとんでもなく多機能なのは誰が見ても明らかで、「使える機能が原始的」という根拠はまったく説得力を持たない。
そして「アルゴリズムの素の性能を見極めるときの邪魔にならないかなぁと思った」とのことだが、
もちろん現実にはデータの個数やデータの並びの乱雑さ、比較関数の複雑さなどによって結果は異なるため、
実際のコードを走らせても「素の性能」を測ることはできない。
「アルゴリズムの素の性能」を測るときに用いるのは数学的な計算量だ。
「基本的なデータ構造を自作しても効率が悪くない」と、C++が効率に優れることも根拠としているようだが、
Javaは通常の用途ではC++と遜色ないレベルまで効率的になっており、
情報科学
Re:アルゴリズムのお勉強 (スコア:1)
>C++がとんでもなく多機能なのは誰が見ても明らかで、「使える機能が原始的」という根拠はまったく説得力を持たない。
私は「原始的なほど多機能」だという感覚があるから、
全然違和感ありませんが。
(私にとって)超高級言語の LOGO とか、他の言語に比べて機能が少ないどころの話じゃないですし。
Re: (スコア:0)
Graphic Context がどう邪魔するんだろう?
と、しばらくわからなかった。
Re: (スコア:0)
pythonなどではCやpascalなどに比べて考えなしにコードを書き始めても何とかなることが多いですが
教育の場においては良かれ悪しかれですね
ま、入門コースならpythonでいいんじゃないですか
素振りだけやって終わる野球入門なんてイヤでしょう
Re: (スコア:0)
入門は弱い型付けな言語の方がいい。
int x;
x = 0.5;
が、エラーになるのは、スクリプト言語という選択肢がある昨今では、プログラムを学ぶ上では本質的ではない。
コンパイラの都合、最適化、高速化の都合、書き間違いの検出、などなどの意味はあるけど、
最初期にそこで引っかかって時間を無駄にする理由は特にない。
int a[10];
float x;
x = 0.5;
a[x] = 0;
一方、これがエラーになるのは、「配列の性質」だから、理解する必要がある。
と言うように、弱い型付けの方が理に叶っている面が大きい。
あまり本質的ではないことには時間をかけずに、そこそこのものが作れるようになってから
Re:アルゴリズムのお勉強 (スコア:4, 参考になる)
勘違いしている人が多いですが、C言語では
int x;
x = 0.5;
は、エラーになりません。Cの規格上、これは"合法"です
正しい記述なので、処理系は警告を出す必要がありません。例えば、最近のGCCではエラーも警告も出ません。
しかし処理系によっては未だに警告を出す場合があります。その余計な警告が勘違いを引き起こしている様です。
Re: (スコア:0)
C言語の厄介なところは処理系がエラーを出さないからといって合法である保証はまったくないことで(このケースは合法だけど)、やはりどう考えても初級者向きじゃない。
Re: (スコア:0)
> int x;
> x = 0.5;
> が、エラーになるのは、スクリプト言語という選択肢がある昨今では、プログラムを学ぶ上では本質的ではない。
うーん、整数を宣言する意図があるのに、その直後浮動小数点数を代入というのは
思考が整理されていない証拠のように思うのです。
数学でも、まずは自然数、次に整数、次に有理数、でもって実数と段階を踏みますよね。
整数と浮動小数点数が区別できることは重要ではないかと。
まあ、これ以上は、動的型の言語か静的型の言語かの果てしない論争になるんでしょうけど。
Re: (スコア:0)
>動的型の言語か静的型の言語かの果てしない論争
俺の中では、「型推論ありの静的型付け言語が最良」ととっくに結論が出てるな
C++/Java/C#だって型推論を取り入れ始めたし、
動的型付けの言語だって、実は最適化のために内部で型推論してる処理系は多い
型推論ありの静的型付け言語を否定する意見があったら聞いてみたい
Re: (スコア:0)
型付き論理は一般的ではないので論理型言語では動的型のほうがよい
Re: (スコア:0)
C#はどっちかっつうと型推論普及の先駆者って感じ。
で、後からdynaic型なんてのを導入してる。これは型推論とは逆方向のシンタックスシュガーと言えると思います。
静的評価の否定ではないですが、動的評価の有用性も同様に肯定する姿勢ですね。
Re: (スコア:0)
で、結局型を意識しないと実行時エラーになるのが弱い型付け言語ですよね。
Re: (スコア:0)
Pascal系というかWirth系というか、静的な型チェックの厳しい言語のご利益は使ってみないと分からない
弱い型付け言語でランタイムエラーになってデバッグに苦労するバグ/ミスをコンパイラが弾いてくれるのだから、ありがたいことこの上ない
逆にそういう型の制約を無くして実行時のハンドリングに任せるという方向もあるが、少なくとも基本的なアルゴリズムなどを教えるアカデミックな教育の初期段階では型チェックの厳しい言語の方が良いだろう
Re: (スコア:0)
初級ならお約束は少ない方がいいんじゃないでしょうか
Cだといきなり
#include <stdio.h>
とか(当初は)意味不明なお約束が出てきて
「へ~、スタジオをインクルードっと。あれ、エラー? stANDARd iNPUT/oUTPUT? 騙された!」
となるわけでそれだけで嫌いになる要素充分ですわ
Re: (スコア:0)
どうせ意味不明なお約束はどの言語でもあるし、
プログラムをしていれば何度でも出くわすんだから、
そういうもんだと認識させるのは非常に重要ですよ。
全部分かってからじゃないと書けない、なんて言ってる人は
新しい物事なんか永遠に始められません。
Re: (スコア:0)
ですよね。どれだけ噛み砕いたってどこかで「io?イオって?」となるわけで。
Re: (スコア:0)
人によって学習順序は違うし、深さ優先探索あるいはボトムアップ的な覚え方ではなく幅優先探索的な覚え方が性に合っている人もいるので、ただ一つの一般論を定めてそれが誰にとっても最善かというとそうとも言えないと思いますね。
Re: (スコア:0)
あとvoid main~も。
Re: (スコア:0)
あとvoid main~も。
とまあ、かように間違える人が引きも切らないわけで
#誤:void main 正:int main
##理由:言語仕様で決まっているから
Re:アルゴリズムのお勉強 (スコア:2)
hosted environmentだっけか、ランタイムに対する仕様
ランタイムまで自作するときにゃvoid main(void)でもかまわん、
つまり言語そのものの仕様とはしないってのがCの特徴では?
Re: (スコア:0)
言語オタクや老害になるとこのように初級者にいきなりそういうことを体験させるのが適切かという観点がすっぽりと抜け落ちます。
Re: (スコア:0)
仕様書
http://www.open-std.org/jtc1/sc22/wg14/www/standards [open-std.org]
ここの WG14 N1570 を読んでみました。確かに
>5.1.2.2.1 Program startup
>It shall be defined with a return type of int
とも書いてあるんですが、最後に
>or in some other implementation-defined manner.
と書いてひっくり返してあります。そんなわけで言語仕様上は、
#2638323 に tenokida さんが書かれているように、
実装依存という
Re: (スコア:0)
The rationale for the C99 standard [open-std.org]の5.1.2.2.1を見ると、
そのsome other implementation-defined mannerってのは、おそらく引数の事で、戻り値の型では無いと思う。
While many implementations support more than two arguments to main, such practice is neither blessed nor forbidden by the Standard; a program that defines main with three arguments is not strictly conforming.
Re: (スコア:0)
補足すると、Freestandingに関しては5.1.2.1に述べてあるように全く自由で、関数名も何も決められてない。
だからmainを関数名として使っても良いけど、それはHostedのmainとは無関係。
5.1.2.2(と5.1.2.2.1)はHostedの話で、この場合戻り値の型はintと決まっている。
Re: (スコア:0)
http://c-faq.com/ansi/voidmain.html [c-faq.com]
Re: (スコア:0)
何を教えたいかにもよると思います。
C(素朴なC++も含む)で学ぶということは、言語やアルゴリズム自体を学ぶことに加えて、コンピュータの動作原理も学ぶことになります。
これは良し悪しです。講義の目的がコンピュータに慣れることだったらCでも構わないと思いますが、
アルゴリズムメインで教えたい場合、Cだと講義の目的外のところで脱落する人が出てきてしまうおそれがあります。
# Cで書く場合、他で書くよりも遥かに「集中して」やる必要があるなあと感じている。
# 代数的データ型が無いと、自分の頭の中にintの意味だとか配列の意味だとかを保持する必要があるんじゃないか。
Re: (スコア:0)
Cだと、配列をはみ出して他の変数を書き換えちゃったり。
そういうバグって初心者にありがちで、しかも見つけにくい。
Re: (スコア:0)
あー、いたいた、stdio をスタジオって言うやつw
でもそういうやつは Python のコードを Web からコピペして、
インデントをめちゃくちゃにして動かねーでやっぱり嫌いに(^^;