C言語なら俺に聞け 149
■ このスレッドは過去ログ倉庫に格納されています
>>253
＞スッキリJava は、250ページにも及ぶ、猿向けにオブジェクト指向を解説した、伝説の書。
私が知りたいのはスッキリC++（そんなものが存在するのですか？限りなく胡散臭いですね）の話です >>258
おっしゃることがよくわからないので、ちょっと書いていただけますか？http://ideone.com >>263
下準備にはPEEK/POKEも重要
私は CALL で呼んでいた記憶がありますが、もしかするとNとN88とN88(86)とでは違っていたかもしれません… PC6001でBASICを覚えてPLAY,SOUNDで音楽作ってたな
PSGの音を聞くだけで懐かしい気分になる
そしてMSXでMSX-Cを覚えた
cursesがあったからローグもどきのゲーム作って遊んでたよ C言語以降関数と手続きを区別しない言語が増えたこととOOPでは一部がメソッドと呼ばれるようになったので使用頻度は下がったな
なくなってはいないけど 関数と手続きを総称して、「メインルーチン」に対して「サブルーチン」って
言い方なら今でも使うんじゃないかな。
プログラミング教育の初期の段階での説明。
BASICでの「サブルーチン」は言語仕様での用語だっけ? >>277
処理をまとめたのがサブルーチンで
値を返すのが関数…とかなんかあった気がする >>280
その定義だとvoid func(void)
はサブルーチンになるな
ちょっと難癖っぽいけどw アセンブラだと値返していようがいまいがサブルーチンっていうよね
今曖昧だってことは元々曖昧だったのかな もともとは呼び出しがステートメントであって返値というものが存在しないサブルーチンと、
値を返して式の一部となる関数という区別だね。
式+;が文になるという単純化を行ったCではその区別もなくなってそれが主流になった。
副作用のないものが関数、ありえるのがサブルーチン、と定義を変えて復活はあるかも。 言語(VBとか)によっては明確な違いがあったりするけど、概念的にはサブルーチン⊃関数というイメージあるわ。 副作用のある手続きをほんとは関数とは呼ばないのだろうけど
Cではそんなことに頓着せず全て関数に単純化したからね
ただ本来サブルーチンとはメインルーチンと対立する文脈で語られていたものかと
これは単なる呼び出し関係だけでなく、古い言語では変数のスコープなども異なる
Cではこれも単純化してしまった
main は単にスタートアップルーチンから最初に呼び出されるという以外は
特別なスコープを持つわけでもなく、他の関数と何ら違いがない
他の関数から main を呼ぶことも、普通やらないだけで問題なく可能だ
Cでサブルーチンという名前がしっくりこないのはこの辺が理由でもあるかと ああ、関数と対比されるのはサブルーチンじゃなくて正しくはプロシージャ(手続き)だね。 >>287
そうだけと、その辺の用語も統一されてるとは言い難いところがあるよ
AdaなどのPascal系の言語ではprocedureとfunctionという区別があるよね
まぁ値を返すかどうかという違いでしかないわけだけど
VBではPascalのprocedureに相当するのはSubであって、SubとFunctionをまとめた
上位概念としてプロシージャと言うからね mainが特別扱いされてると言えばOSが受け取れる返り値は0--255なのにint型を指定するってところとかかな。 Perl ではサブルーチンは sub で始まる。これはCの関数のようにも使える。 >>286
> 副作用のある手続きをほんとは関数とは呼ばないのだろうけど
> Cではそんなことに頓着せず全て関数に単純化したからね
逆だぞ。関数型が馬鹿やったから「副作用」なんて言葉が必要になったのであって。
元々Cの関数は副作用がない。これは単純に、Cの場合は引数で渡すしかないからだ。
（当たり前だがグローバルは使わないとする）
だからC全盛の時代には「副作用」なんて言っている奴すら居なかった。
関数型の連中が副作用(ｷﾘｯとか気にする必要がでてきたのは、クロージャを濫用したからだ。
単純に言えば、関数に対しての値の渡し方は、
・引数
・グローバル
・this(OOPの)(＝インスタンス内グローバル)
・クロージャ(＝レキシカルスコープの場合は階層内グローバル）
とあって、クロージャは使い方を間違えば結合を強めてしまうんだよ。
(thisの場合は最初からクラス界面で切る《=public/privateを意識して設計する》
からそこまで酷くはならない）
Cはそれがないから、便利に書けない反面、無駄に結合するって事もない。
（少なくとも、結合していることは明示的に見える）
伊達に50年近く現役な訳でもないのさ。現役で居続けられた理由がある。
>>288
AdaとかPascalとか、最早死んで誰も使わないし使う価値もない言語を持ち出しても、
何の意味も無いと思うぜ。
それらが死んだのは、それなりの理由があるんだよ。 なんだCの関数には副作用なかったのか。これで安心してprintfできる Cに副作用の概念はないって……それは流石に嘘でしょう。
箇所は失念してしまったがK&Rにも関数を指して「文字列を出力したりする場合もあるので純粋な関数とは呼べない」
みたいな記述あるくらいだし。 >>294
副作用の概念はあるに決まってるだろ。
そもそもプログラミング自体が副作用を伴うものであって、
全てを含んだ「学術的な意味での副作用」を伴わないプログラムなんて、何もやらないプログラムだからだ。
それすら理解出来ない>>293なんてただの馬鹿だ。
そうではなくて、関数型()の連中が言っている意味での「副作用の無い関数」についてなら、
Cは全ての関数が該当する、ということだよ。
だから、「副作用(ｷﾘｯ」する必要すらなかったって事だよ。
試しに関数型()の連中に、「クロージャ禁止、this禁止、グローバル禁止、全て引数で渡せ」と言ってみろよ。
多分、顔が引きつると思うぜ。 >>298
まあそれがゆとりが嫌われる理由なんだけどな。
お前も含めて自覚がないのが救いようがない。
お前ら、もう既に老害になってると思うぜ。 https://ja.wikipedia.org/wiki/%E3%82%86%E3%81%A8%E3%82%8A%E4%B8%96%E4%BB%A3#%E5%AE%9A%E7%BE%A9%E3%83%BB%E7%AF%84%E5%9B%B2
ゆとり世代については明確な定義、範囲はなく諸説ある。
小中学校において2002年度施行（高等学校は2003年度）の学習指導要領による教育を受けた世代（1987年4月2日 - 2004年4月1日生まれ）。
小中学校において1980年度以降（高等学校は1982年度以降）の学習指導要領による教育を受けた世代。1966年度生まれ以降。
1966年度生まれ以降。
1966年度生まれ以降。
1966年度生まれ以降。
1966年度生まれ以降。
1966年度生まれ以降。 >>301
俺に言ってるのなら説明しても良いが、タダではやらん。
お前が説明に値するだけの頭があることを先に示せ。
具体的には、現状の議論について、何らかの進展があるレスをまずしろ。 >>291
まず、副作用という言葉は C が生まれる前から使われていたし意識されていたことですよ
Lisp をやってれば分かることだけど
C 全盛時にCプログラマが副作用という言葉を使わなかったのは当然でしょうね
C は副作用そのものであるノイマンアーキテクチャを素直に表現できる言語と
目されていたわけで (i++ とか)、それこそ最初はグローバル変数も使いまくりだったのでは
また、引数で文字列を渡すにもポインタを使わざるを得ないので、それが破壊されることを
防ぐ手立てがなかった (今でもないか)
引数経由でなくても、ポインタが使えるということは、そこに任意のアドレスを設定でき、
任意の場所に書き込めるということなので、C の関数で副作用を防ぐ手立てはないわけですよ
C 界隈で副作用うんぬんが取り沙汰されるようになったのは const 引数の導入や、
グローバル変数の弊害が意識されるようになって、むしろ民度が上がってきたと見るべきかと
あと、Oracle のストアドプロシジャ PL/SQL をやったことはないですか
あの文法は Ada そのものなんだけど >>302
1966以前と1966以後では教育内容で変化があったのですか？数学に関する限り一時期は線形代数も微積分もやる、という過剰な状況だったと思っています >>291
オラクル社の第一言語は、Ada言語を借用したPL/SQLだぞ。
C言語が例外処理機能を受け入れなかったのは完全な失敗。 >>305
そうですよね。いま働いている日本人のほとんどはゆとり教育です。
ただ昔は教科書に載っているだけでまともに教えていないと思います。
学年トップレベルだったという年配の多くが義務教育の範囲さえ、完全に忘れているか、知らなかったりします。 >>304
> 引数経由でなくても、ポインタが使えるということは、そこに任意のアドレスを設定でき、
> 任意の場所に書き込めるということなので、C の関数で副作用を防ぐ手立てはないわけですよ
それは「副作用」ではなく「バグ」と言うんだよJava以外では。
その他諸々色々勘違いするのは自由だが、
さすがにそれだと話が通じなさすぎて煙たがられてるだろ。
> あと、Oracle のストアドプロシジャ PL/SQL をやったことはないですか
> あの文法は Ada そのものなんだけど
無いね。
ただ、Oracleがそうなら、Ada文法がまだ生き続けていることにはなる。この点は訂正しよう。
とはいえ、それが「参考にする意味があるか」とは別だよ。
本当に意味がある物は、「オブジェクト指向」や「クロージャ」のように、
ほぼ全ての言語でサポートされる事になる。
現状、procedure/function/Subを区別してない言語がメジャーで、
区別した言語(Ada/Pascal/VB)はことごとくマイナーだし、
最近のクロージャのようにC#/C++/Java等のメジャー言語が
相次いで方針を変更してサポートした、ということもない。
それは不要だった、ということで結論は出てる。
それを反例と持ち出してきても意味がないだろ。 老害がブチ切れてて草
変ったのは世の中じゃなくてお前の脳味噌やぞ老いぼれ >>302
> 小中学校において1980年度以降（高等学校は1982年度以降）の学習指導要領による教育を受けた世代。1966年度生まれ以降。
そういうことをするからゆとりは駄目なんだよ。 >>306
Oracleについては308の通り。
例外についてはCで採用しなかったのはとりあえずは正解だろ。
未だに各言語で例外方式が安定しないのは、未だにいい解を見つけられてない、ってことだよ。 自分がゆとりであることに気付かずにだからゆとりはと言い出すやつばかり。
それが今の時代。 >（当たり前だがグローバルは使わないとする）
副作用について議論するうえでこんな変な条件付ける人はいない。
あと当然だが、引数によって参照される関数スコープ外の値を変化させるのも副作用だ。 >>313
> こんな変な条件付ける人はいない
君がグローバルを普段から濫用している人だとは理解した。
> あと当然だが、引数によって参照される関数スコープ外の値を変化させるのも副作用だ。
勿論。
というか、まともに議論する気があるのなら、明確に条件を確定させなければならない。
何も言わないのなら、C言語での『標準的な』コーディングを各自が想定することになる。
君が普段からグローバルを濫用しているのは理解したが、それは俺の『標準』ではないし、
君みたいな馬鹿が出てきて無駄に議論が空回りするのが嫌だから、俺は明示的にそれを除外した。
そしてこの条件付けは『標準的』であり、問題ないと俺は考えている。
君がグローバルを含めて副作用を議論したいのならそうすればいい。
俺はその議論には意味が無いと思うから参加はしない。
君の言うように、俺は「参照透過」は以下の2種類に分けて考えるべきだと思っている。
・狭義の参照透過…sin()等
・広義の参照透過…qsort()等やthis
・参照透過でない…その他全部、つまりクロージャやbindやグローバルを用いるもの
通常の文脈で言われる『副作用』はおそらく関数型（）言語から来ている。
それは上記「参照透過でない」物を濫用した結果だ。
Cの場合は最初からそれが出来ないから、その議論が発生することはなかっただけ。
それとは別に、意識高い系関数型（）の「『狭義の参照透過』だけでプログラミングすべき」、
というのは当たってはいるが、実際の所それは多値を返せないと厳しい。
そして多値返しよりも参照を返してそこからアクセスしろ、というのがメインストリームの言語だろ。
それの方が楽だから。 少なくともCにおける「副作用」はずっと昔からの規格で定義されている用語だから、
独自定義で話されるのは困る。
http://kikakurui.com/x3/X3010-2003-01.html#13
> ボラタイルオブジェクトへのアクセス，オブジェクトの変更，ファイルの変更，
> 又はこれらのいずれかの操作を行う関数の呼出しは，すべて副作用（side effect）と呼び，
> 実行環境の状態に変化を生じる。... >>315
FPUのフラグか。なるほどそれは正しい『副』作用だ。
というか、『副』作用というからには当然「作用」（『主』作用)と対比されるべきで、
「printfが副作用」(>>293)というのはHaskellの定義だからな。
スレチというのはごもっとも。 C言語使う人ってアドレスって言ったほうがわかりやすい場合でもポインタっていうよね
ポインタの意味が多くて混乱する 副作用は、volatile とか、何かの状態を変えること
関数型のmonad とか、
Vuex, Nuxt.js みたいに、1方向のライフサイクルを作って、
状態は、Mutation からしか変えられないとか
どこかのタイミングに、絶対に変化していない、ポイントを作る
WEB+DB 106号に載っている、Flux。
状態管理のデザインパターン、単一方向のデータフロー C言語はファイルポインターを配列を指すようにして同じように扱うことはできませんよね。
それなので同じように扱うにはファイルポインターと配列のラッパーを自分で作らなければいけませんよね。 >>321
調べたらわかりました
ありがとうございます なんだこれ？引数 void って初めて見たぞ。文法的にありなのかこれ？ >>323
FILE * 経由の入力や出力をするように書かれているプログラムで使うと便利な場合があると思う。 >>326
それはC言語を知らない初心者が前スレだったかで残した名言 プロセスメモリエディタも初めて見たり副作用を知らなかったりする彼ね Ruby には、StringIO と言う、メモリ上だけに存在する仮想ファイルがある。
これは、IO クラスの派生クラスではなく、
文字列クラスに、IO にある関数をDuck Typing したもの(インターフェース)
StringIOインスタンス.read, puts など、ファイル操作と同名の関数を使える
テストの際に、本当のファイルを作らなくても、
メモリ上だけでファイルの振りができるので、楽 へぇーっ！メモリ上だけに存在する仮想ファイル？Rubyすごぉ〜い！
特許取った方がいいんじゃない？
ノーベル賞狙えるかもー！？ 単体テストで使った様な気もしてきた
でもまあストリームは難しいわ。fopenよりopenが好きだよ C++にもstringstreamがあって
メモリ内でファイルイメージが作れる
しかもcin, cout, ifstream, ofstreamの
メンバ関数・フレンドが全て使える なぁんだRubyパクリだったのか。ダッサ。
パクリRuby！ >>329
プロセスメモリエディタを知ってる＝Cを知ってる、になるのか。
さすがゆとり、だな。
お前らはそんなことばかりするから、お前らの居場所を無くして行ってるんだぜ。
自覚出来てないんだろうけど。
まあ、ゆとりに付ける薬はないって事だな。
三つ子の魂百まで、と同様、ゆとりの魂百まで、なのだろう。 彼は自分がゆとりであることに気付かない。超ゆとりである。 勉強始めて半年くらいの初学者だけどenumの便利さに今日気が付いて震えてる
case文がシェルスクリプトとかのと比べてあんなに使いにくいものになってるのはそういうことだったのね……。 なんにせよまあswitch/caseはあんまり使わない方がいいですよ。 クソコードに発展しやすいんです。
if文の方がちゃんとしてる。 switchは単一の変数(大抵は状態)を比較してることが一目瞭然。
case内が長くなって醜いのは全く別の問題。 まあ今となってはコンパイラが軽く最適化してくれれば全く同じコードになってしまうかも知れず、どちらで書くかは見易さの問題だけかも知れない。
ま、switchはbreakなしで下に抜けるっていうifとの違いがあるからそれ利用してたら別だけどな。 switch〜caseで、char 値の比較の場合、昔のコンパイラでも最適化した時、
条件分岐じゃなくて、テーブルジャンプにしてくれるものがあったなあ。
最近のコンパイラが if〜else if〜 で記述した時、どう最適化してくれるのかは知らない。 文法に罪はない人が悪いと言って終わるならば、もうなんでもありで良いんです。
C++の方が選択肢が多い分圧倒的に優れてるとも言える。 自分的にアホだと思う書き方はcaseの中身を{}でくくっちゃうやつです。
そんなことするなら関数呼べや。 case文内に関数にするほどでもない、ちょっとした処理を書きたいとき、その処理内だけで使う変数宣言は{}使ってその中に書いちゃうわ。 そういやswitchのブロックの先頭でも変数宣言できるんだよな。
今はどこでもできるから関係ないとは思うが昔は驚いた。 地味に都合の良いスコープ範囲だから便利っちゃ便利だよね。 たとえば、caseではクロージャ的なもんが使えて、関数ポインタに代入。
抜けた後でそれを実行、とかできるのなら許容するかも。 初期化されないのかよ。
最初から禁止にしといてくれや… >>354
いや、クロージャ無いじゃん。
あってもいいと思うけど。 構文やや変数キャプチャの問題はさておき、関数ポインタは原始的なクロージャっぽく使えるよね。
こんなん書いたらクロージャ原理主義者が反論しそうだけど。 C言語勉強してます。
エラーにOBJが開けませんってでるんだけど、どうしたらいいか教えてください。
コンパイラーはbcpadです bcpadって、懐かしい響きだな。
古すぎてなにか特別な理由がない限り使われなくなってるようなものだと思うんだが、なんでそれ使って勉強しようと思った？ 授業で使ったからこれでいいかなーって感じ、これといった理由ないです笑
最近はどんなコンパイラーが主流なんです？ MSのVisual Stdioに入ってるVC++か、gcc か、clangだね。
bcpad使った事ないけど、それで使えるbccも地味に生き残ってて進化してた。
(久しぶりに見に行ったらフリーのは最新じゃないけど、地味に進化してた)
エンバカデロがまだインプレス(買収される前)だったり、ボーランド(社名変更前)だったりしてた時代のbccコンパイラ環境設定記事がまんま使えるはず。 LinuxまたはWindowsのWSLのUbuntu等やCygwinの中でもgccが動く。Macでも中はUNIXなので動く。 ■ このスレッドは過去ログ倉庫に格納されています
