C言語なら俺に聞け 144
■ このスレッドは過去ログ倉庫に格納されています
>>97
んなこたあない
>>94の書いてるコードと同義で、cの先頭アドレスからint分の領域に代入するだけで、cを拡張したり戻したりしてるわけではない
gcc 3.xやVC++2008では通ったが今のgccではコンパイルエラーになる記法 思いっきりメモリーリークして実行時に大暴走する悪寒しかしない。 >>101
そうだよ
だけど一部の（まずいことに大手の）コンパイラが
左辺値としての用法を古くから許していた >>98
俺は初見ではcはcharのまま代入されて代入後の値がintとして評価されると見たんだが >>102
Cは95のコードを書く池沼は死んでよし、って言語なんだよ。
だからそんなのは問題にもならない。
94はよく見るが、95は見たこと無いぞ。 若造が見たことないのは仕方ないよ
活発に議論されていたのがC89制定を目指していた頃のことだから >>84,87,91,95 の流れがよくわからん
const <type> *p = ... が <type> const *p = ... と等価となる理由が例外ではなく
p を左辺値と解釈する隙間があるから ってこと？ >>107
例外じゃないって立場は俺しか居ないのか？
その場合、お前らはこれを整合性よく説明できない馬鹿共だということになるが、それで良いか？
逆に考えてみろ。
君がそれを「例外」だとしているのなら、つまり「例外」でなければ君は
const <type> *p = ... // (A)
<type> const *p = ... // (B)
で意味が違うべきだというわけだ。
その場合、それぞれどういう意味と捉えるべきだと考えるのか、言えるか？ 少なくとも俺は そういうもんだと覚えてるだけで説明はできない こんなの決め事なんだからもしそう言うのがあったとしても
> その場合、それぞれどういう意味と捉えるべきだと考えるのか、言えるか？
は、作った奴に聞くしかないだろ 例外でもなんでもなく、単にC言語の標準規格がそうなっているからとしか言いようがないけどな。
宣言指定子 (declaration specifier) は以下の3要素から構成されている (順不同)。
・記憶クラス指定子 (storage class specifier) : auto, register, static, extern, typedef
・型指定子 (type specifier) : void, char, short, int, long, float, double, signed, unsigned, struct/union指定子, enum指定子、typedef名
・型修飾子 (type qualifier) : const, volatile
ポインタ宣言子 (pointer) は以下の2要素から構成されている。
・*
・型修飾子 (type qualifier) リスト
いろいろ省略してるので細部は不正確かもしれないがC89ではだいたいこんな感じ。
参考: C11のYacc文法 http://www.quut.com/c/ANSI-C-grammar-y.html
で、なぜそうなっているかを自分流に解釈して自分の中で整合性を取るのはいいけど、それを他人に押しつけるなってことだね。 ちゃんと理詰めで理解できるやつもいれば
暗記するしかないやつもいる
世の中、人それぞれだな >>113
別に太陽が地球の周りを公転していると解釈してもいいんですよ？
結果さえ合っていればね。
ただその自分流の解釈を他人に講釈したら恥をかきますよって話。 >>113
> ちゃんと理詰めで理解できるやつもいれば
アホなの？
理詰めで説明できると言うならして見せろよ ｢￣ ｀ヽ､ ＿_＿_＿_
Ｌ -‐ '´ ￣ ｀ヽ- ､ 〉
／ ヽ＼ /
／/ / / ヽヽ ヽ〈
ヽ､レ! { ﾑ-t ﾊ li ､ i i }ﾄ､
ﾊＮ | lヽ八l ヽｊﾊVヽ､ｉ j/ l !
/ﾊ. ｌ ヽｋ=＝ , r= ､ﾉﾙｌ lＬ」
ヽN､ﾊ ｌ ┌‐┐ ﾞl ﾉl l
ヽﾄjヽ､ ヽ_ノ ノ//ﾚ′
r７７７７７７７７７tﾉ｀ ｰ r ´ﾌ/′
ｊ´ﾆゝ ｌ|ヽ _/｀＼
〈 ‐ 知ってるが ｌﾄ、 / 〃ゝ、
〈､ﾈ.. .ｌＦ Ｖ=＝"／ ｲl.
ト |お前の態度が とニヽ二／ ｌ
ヽ.|l 〈ｰ- ! ｀ヽ. ｌ
|l気に入らない ｌﾄﾆ､_ﾉ ヾ、!
|l_＿_＿_＿_＿__ｌ| ＼ ソ 無知なやつには
恥をかかせるよりも
教えないことが最も堪えるからな 何を教えるつもりなんだろう...
俺が思う正解は>>111に書いてあるんだが w 悪党の泣き声は言い響きだ
何を教えるつもりなのか聞き出したいんだなあｗｗｗ どうせなにも出てこないのは既にわかってる
って>>115みりゃわかると思うんだが w 正直なところ
const int x
と
int const x
は同等、
というのは、決め事でいいと思うよ、何もかも原理原則で理解できる（までに細かくパースできる）人にはどうでもいいのかもしれないが。
‥えっと、細かい人にとって、この場合どうでもいいのか、どうでもよくないのか、どっちだったっけ？？ 同等も何も、修飾する主体が変数だけなんだから、何をどう変えろと？
対象がポインタなのかポインタの内容なのかって話に意味の無い例を挙げてどうしたいんだ？ >>116
>>125
禿同
というかいい加減、知らない奴が煽るとか止めろよドアホ共。それは長期的にスレを毀損する。
なお、俺は知っている奴が馬鹿を糞味噌に貶すのを止めはしない。
馬鹿なこと言わなきゃいいだけだし、
逆に、これが出来ないのがID制フォーラムが腐る原因だと思っているから。
ヒントは既に書いたし、それ以前にC流の文法解釈をすれば特段不自然でもないし。
「例外」だと言いつつ(A)≠(B)を妥当とする根拠もないのはただの自己矛盾だと気付け。
そしてK&RはCの作者によって書かれているんだが、それも知らないのか？
Cしかなかった昔ならともかく、今お前らみたいな馬鹿がCやる理由は無いと思うんだがなぁ。 >>126
で、K&Rのどの記述からconstに関する解釈（constの右側の固まり全体が定数と見なされる）を読み取ったの？ K&Rにconstはねえな
constの設計は髭と禿の合作だが >>128
ここに来て堂々と嘘をつくとか、お前も死んだ方がいいな。
K&Rが手元にあるのなら、目次見てみろよ。 煽ることしかできないアホ ⇒ ID:u4QX+fVn0, ID:8LuLzpAV0 constがないK&Rが本のことだと思ったアフォはもう死んじまったのか？ 家のは、4-320-02145-2だけど、constは無いな プログラミング言語Cの第2版(白本)は初版(緑本)と違ってANSI規格準拠
型修飾子や型指定子の項目にconstは存在する
というかconstとvolatileはANSI標準で新設されたものと明言されてる
一般には同一著者なので第2版まで含めてK&R本と呼ばれているから紛らわしい 緑は初版じゃ無いよ。
初版は白。だから紛らわしいの。 あ、そうか
第2版の翻訳訂正前の表紙が緑だったっけ？
現在発売中のものの表紙は白だよ
https://www.amazon.co.jp/dp/4320026926 プレンティスホール版で言う所の「ANSI DRAFT」の斜線入り
に相当する版が緑色だったかと。
4.xBSDやOS-9がこの前の版のCなので、未だに残っているんでしょうね >>141
そう言えば最後にK&Rスタイルで書いたのはOS/9-68Kだったな
もう25年ぐらい前の話だが ゴガギーン
ドッカン
ｍ ドッカン
＝＝＝＝＝） ）) ☆
∧_∧ | | ／ ／￣￣￣￣￣￣￣￣￣￣￣
（ ）| |＿＿＿＿＿ ∧＿∧ ＜ おらっ！出てこいOgju
「 ⌒￣ | | || （´Д｀ ） ＼＿＿＿＿＿＿＿＿＿＿＿
| / ￣ | |/ 「 ＼
| | | | || || /＼＼
| | | | | へ//| | | |
| | | ﾛ|ﾛ |／,へ ＼| | | |
| ∧ | | | |／ ＼ / （ ）
| | | |〈 | | | |
/ / / / | / | 〈| | |
/ / / / | | || | |
/ / / / =-----=-------- | | openじゃなくてfopenみたいに、ファイルの存在確認のaccess関数に
対応するちょっと上位の標準関数ってある？ >>147
stat()とfstat()なんかどうだ？
まあでもopen(), fopen()の関係とは違うけどな。
open()はシステムコールだがfopen()はライブラリ関数だ。
(UNIX系OSの話ではあるが)。 俺の希望は、たいしたやりたくもないけど、
ちょっとやってみたら？とか丁寧に教えるからやってみなよ！
とかさ、そういう感じで優しく接してもらってだな、で、出来も悪いからなかなか覚えないけどそれでも教える側が知恵を絞ってどうにかうまく理解させる方法はないだろうかと創意工夫して育てる環境というのかな。とにかく頼むよまじ >>148
stdio.hにaccess()の偉いやつあるのかなー と思ったのだよ
無いならまあいいけど >>149
授業料ももらってないのに優しく教える理由なんかないわな
5chなんて煽り合いと罵り合いの場だよ >>149
日本語でおｋ
そして死ね
> 出来も悪いからなかなか覚えないけど
なら覚えるまで何度でも読み返せ
> 教える側が知恵を絞ってどうにかうまく理解させる方法はないだろうかと創意工夫して
教わる側が1mmも努力せず、教える側に全責任をなすりつけるのは典型的ゆとり。死ね。
というかな、はっきり言えば昔より格段に環境は良くなっている。
当然教える側のノウハウも蓄積されてるし、
本も大量に出版され、良書以外は淘汰されてるし、
Webにも情報があふれ、ここみたいな掲示板やフォーラムもあるし、
無料でIDEも使えるし。
だから昔の環境で手こずった奴も、今なら楽勝で学んでいける。
問題は、昔だったら(=IDE無しでは）お話にならない馬鹿にもプログラミングさせようとしていることであって、
俺はこれに関してはもう諦めた方がいい＝手取り足取り教えないと出来ない奴は死ねでいい、と思っている。
自分の為に他人に無償の努力を強いるその姿勢が根本的に間違っている。
つかマジで、ゆとりのノリでやりたいなら、C以外のゆとり用言語を使え。Javaとか。新しいのならGoとか。
そしてこれとは別に、俺は2chとは別の掲示板を立ち上げようとしているのだが、
君はこれについて興味あるか？
追える限りでの発言を確認したが、君は煽るだけの無能ではないらしい。
俺は今の2chのシステムでは行けるところまで行っている（既に飽和している）と見ているから、
これ以上の物を求めるのなら何かしら新しい機能が必要だと考えている。
今はそれのアイデア出し中だ。何かあれば是非。 漠然とした質問で失礼します。
私は最近ｃ言語の勉強を始めたところでギリギリポインタ等も理解できたところです。
そこで、アルゴリズムとデータ構造の勉強をしようと思い本を何冊か買ってきたのですが、
スタックなどのデータ構造の仕組みがよくわかりません。。
どの参考書でも、「スタックとは後入れ先出しで…」という説明の後、「それではc言語でスタックを
実装してみましょう」といって意味不明なコード（長い）が書かれているパターンが王道のようです。
このパターンは線形リストとかでも同じです（諸兄にはいうまでもないでしょうが…）。
どのような実益があってこのようなデータ構造を生成する必要があるのでしょうか。
python等でいうところのリストに相当するデータ構造をc言語で作成するためということ?
また、実際のプログラムにおいては、データ構造の定義だけでかなりコード長くなると思われるのですが、
よく利用される手法なのでしょうか。 >>153
std::stack相当の話？
なら大して使わないから、とりあえず読み飛ばしていい。
つか、最初から全部キッチリ理解しようとせず、
まずは分かる範囲で組み、その後、自分の出来る範囲を広げていくようにした方がいい。
(1度読んで全部理解して捨てる、ではなく、最初から5回読む前提で分かるところから読み進める）
そのうち、stackを使うべき用途に遭遇したら、なるほどと理解できるようになる。 >>153
直近のご要望としては、スタックの使い所を知りたいって事かな？
ほとんどの実行環境において、C言語の関数呼び出しなんかの実現に使われてるよ。
呼び出した側の状態を保存する場合にpush、呼び出され側から戻るときにpop的な。 >>153
どのような実益？そうだなあ。スタックといえば以前PerlでXMLの階層構造を
SAX使ってRDBに全て入れる時に使ったなあ。まあ、それだけでなく先入先出に
するとやりやすくなる処理はあるよ。再起処理でも使われるし(スタックに積まれて
いるとあまり意識する必要ないかもしれないが)。
リストは例えば長さが可変長のファイルからデータ取得してメモリ上に置いておく
時に使えるかな。
まあしかしライブラリにあるならそれ使った方が楽だよ。毎回書くのは阿保らしい。 >>156
とりあえずソートアルゴリズムのが理解したいと思い勉強をしていたのですが、複雑なものになってくると
各種データ構造の理解が必須！みたいになってきまして、データ構造の方にも手を出したみたわけです。
ヒープとかの方が簡単そうな気がしますし、とりあえずスタック関連は後回しにします。
>>157
はい、なんかそのようなことも本に書いてあったのです。
しかしこれが、「スタックとはプログラミング言語内においても既に設計されている基本構造なのだ。以上終わり。」
であれば、スッキリするのですが、
「それでは、これをc言語で実装してみましょう」といって、スタックをc言語のプログラムで作り出すことの意義
が今一つわからないというか。 >>150
filenoとfdopen覚えた方が楽だけどね >>159
難しすぎます！
おそらく当分使えるようにはならなさそうです！ >>160
> とりあえずソートアルゴリズムのが理解したいと思い勉強をしていたのですが
アルゴリズムとデータ構造をソートで学ぶのは昔流で、今はそれをこの段階でやる必要はない。
今はとりあえず次の章に行ってしまって、for/while/if等を使いこなせるようになった方がいい。
> 「それでは、これをc言語で実装してみましょう」といって、スタックをc言語のプログラムで作り出すことの意義
仕様を説明する必要がないからだよ。
「じゃんけんゲームを作ってみましょう」なら仕様は大体分かり、説明が省ける。
「オレオレゲームを作ってみましょう」なら、「オレオレゲームとか何か」から詳しく正確に説明しないといけない。
その本は「スタックとは何か」を当然知っているという前提で書かれているんだよ。
Cプログラマがスタック構造を知らないというのもあり得ないからね。
ただ、スタック知らなくてもプログラムなんて組めるし、実際Web系の連中は知らんと思う。
とはいえこれが一方的に悪い訳でもなくて、逆に言えば、
スタック構造を知っていることがプログラミングの本質ではない、ということなんだよ。
だから君みたいな初心者は、分からないところは飛ばして分かるところから読み進めればいいんだよ。
というか、今、君のレベルの初心者がCから始める意味は無いし、
無駄に遠回りになるだけだが、それ分かってやってるか？ >>160
ハノイの塔のパズルを解くプログラムを書いてみて。
スタックを使う場合と使わない場合の2パターン描いてみて。
で、どちらが少ない行数で書けるか、どちらが実行速度が速いか、
どちらが理解しやすい美しいコードか、さまざまな観点で比較してみて。 >>153
と思ったが、Pythonに言及しているところからすると、既にPythonを使いこなせるのか？
だとすると、「アルゴリズムとデータ構造」をガッツリやる意味はある。
スタックが何故使われるかと言えば、スタックで対応できる場合に最速だからだよ。
だからCは実行方式からしてスタックべったりだ。
逆に言えば、それくらいしかメリットないし、
通常の配列にメソッド生やしてスタックにするのも簡単だから、他言語では大体そうしてるでしょ。
以下見れば分かるが、
https://cpprefjp.github.io/reference.html
Pythonのリストに当たる物は
array, deque, forward_list, list, queue, stack, vector の７種類あり、
Cはこれらを使い分けて最速コードを得る為の言語なんだよ。
勿論それ以外の物が良ければ自作しろ、という文化だし。
逆に、Python等は、グダグダ考えずに全部リストでやれ、それの方が分かりやすいし、という文化だろ。 >>165
ほうほう。ありがとうございます。
かなり難しそうですがやってみます。
>>166
スプリクト言語の方が簡単、pythonやrubyでプログラミングというものをはじめましたが、そもそも詳しい人だけが
簡単に思えるだけで、基礎的知識なしでは相当にきついんでないの？と感じてcを始めました。
というわけでpythonが使いこなせるということはありません。
cに関しては教科書一通り一周して、とにかく制御をマスターしたかったので制御文を使いまくるであろうソートアルゴリズムに手を付けたんです。
制御文もアルゴリズムも理解できたら一石二鳥かなと思って。
「定本ｃプログラマのためのアルゴリズム〜」に「リスト」の説明があり、
・要素の挿入 ・要素の削除 ・要素の読み書き ・探索
・複数のリストをまとめる ・リストの分割 ・リストの複製 ・要素の数を求める
とあり、「あら、pythonのリストと全く同じ構造だ」とおどろいたわけです。
ｃはとりあえずarray, deque, forward_list, list, queue, stack, vectorといったものを「なんとかして」pythonのリストやまた
それ以外のデータ構造を自分で作成するということですか。 どうでもいいけどプログラミングなんて10年後オワコンじゃない？
コード共有サイト行けば書きたかったコード見つかるしコピペすればおk
世界で既に誰かが書いてるもの二回三回書く必要性はない
この流れが自動化されれば終わるだろうな >>168
1から1000 までを全部掛けた答えを出す共有サイトのコードを見せてください >>169
なに言ってんだこいつ
調べれば1000000億%出るから自分で調べろよ
まさかgithubも使ったことないのかい？ >>167
> ｃはとりあえずarray, deque, forward_list, list, queue, stack, vectorといったものを「なんとかして」pythonのリストやまた
> それ以外のデータ構造を自分で作成するということですか。
違う。
Pythonのリストというのは抽象データ型で、要するに「万能」に作ってある。
この方がソースコードは分かりやすいから。（知識が少なくても読める）
逆に、「万能」なら限界ぎりぎりの速度を追求できないから、
Cでは別々にして使い分けろ、必要なら自作しろ、ということ。
> スプリクト言語の方が簡単、
これは実際にそう。
pythonやrubyでプログラミングというものをはじめましたが、
これも正しい。
> そもそも詳しい人だけが簡単に思えるだけで、
> 基礎的知識なしでは相当にきついんでないの？と感じてcを始めました。
ここはちょっと違う。
要するに、「動けばいい」プログラムでCを使う意味なんて無いんだよ。
逆に、最速のコードが欲しいときにはC/C++以外に現実的な選択肢はない。
だからほとんどのOS/ブラウザ/処理系(PythonやRubyも）はCで出来ているし、
Cが基礎だっていうのも間違いではないんだが、
プログラミングにCの知識が必要かというと、そうでもないんだよ。
Python/Rubyで済むのなら、Python/Rubyで済ませるべきであってね。
そして初心者はまず、「動けばいい」からスタートすべきであって、
それ以外に色々知識が必要なCはズブの初心者向きではないんだよ。
ただまあ、話を聞く限り、君が「アルゴリズムとデータ構造」をやるのは悪くはない。
とはいえ、現実的にソートのアルゴリズム知ってても大して意味はないし、
直接目標に向かった方がいいと思うが。
例えば、ゲームを作りたいのなら、何でもいいからとりあえず動くゲームを作ってみろ、ということ。
どうせこの最中にいろいろな問題にぶち当たることになるから。 一応付け加えておくと、
Pythonのリストは、C++で言う array, deque, forward_list, list, queue, stack, vector のどの用途にも使える。
でもその分遅いし、メモリも食う。
Pythonを使うというのは、これを認めて、楽さを取る、ということ。
逆に、最高速度で動かしたい、メモリを無駄に食うのは嫌だ、となると、
リストの実際の使われ方を確認して、最も適切なものを選べ、
或いはさらにチューニングできるのなら自作しろ、となるのがC。
だから、組み合わせて作るのではなく、使い分ける。 例えて言った方がいいかな？
Pythonのリストは「車」という解像度しかないのに対し、
Cでは、「軽、軽トラ、普通車、バス、トラック」が指定できるようなもの。
「車」で済むのならPython使っとけ、だし、初心者はこれで問題ない。
細かくチューニングしたいからそれ以上の解像度が必要だ、というときにだけCが必要で、
逆に言えば、その気がないのならPython/Rubyで十分だと思うし、そうするべきだとも思う。
Cは実行速度は最速だが、開発速度は最速ではないので。 なお、人工知能にはPython使う模様
cさん...w Pythonでも速度求めるんならスタック・キューはlistじゃなくてcollections.deque使うやろ >>174
py なのはインタフェースだけでしょ。 >>160
えっ？
データ構造を学んでるんでしょ？
その実装例がでてきたことに対して、実装する意義がわからないっておかしくない？
学習するためじゃないんかい…
車輪の再発明は無駄だけど、学習として車輪の作り方をトレースするのは有益。
とちょっと斜め上の視点をとってみた。 今からお前らが書いてるコードが全て車輪だってことなんだよなぁ... 2chにいる時点で端くれプログラマーなんだし世界で既に書かれたコードしか書いてないでしょ...() >>179
おまえさんは何かコードを書く前に
それを誰が書いたのか調べてクレクレしに行くのか？
すげー嫌われ者だろうな >>180
これは無能確定
何回も同じコードを書くのかい？ 同じ仕様を満たすコードを何人もが独自に書くプロジェクトなんて、沢山あるだろw
誤ったオブジェクト指向の解釈が蔓延した弊害でなw 自分でコード書かないと npm left-pad みたいな問題が起きる
ブラックボックス的に使う部分と内製化する部分はきっちり区別して
内製部分はすべてのコードを完璧に把握しておくべきだ >>185
そりゃコードは把握すべきだよ
けど基本全部他かりゃ引っ張ってくりゃ解決するんだよなプログラムなんざ
プログラマーを神格化する風潮やめようぜ 知恵遅れでポインタすらも分からずギャーギャーわめいてるアホがコイツなんじゃねえの
ttps://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10184535725 >>189
確認したが、同意する。
質問/回答一覧できるのに、酷いな。 いやしかし、ひどい質問だなw
プログラムどころかアルゴリズムの時点で特許がどうの騒ぐ時代なのに、プログラムを全世界で共有とか頭悪すぎる。 部分的にはライブラリの配布みたいな感じで出来てはいるけどな。 正直車輪の再開発なんていってたら商売成り立たないよな
ほかの人に見せて第三者がそのコード使ったら普通に嫌だと思うんだけどコードの共有化とか利益と競争を考えてない綺麗事じゃないか？
コード使い回しなんて実際問題、会社内ぐらいでしかやらんだろ むしろ乖離問題で使わせてない。つか使わせたくないってのが本音。
資産だけど公開した途端にむしろ負の資産になる。 GNU汚染問題もあるし出所の怪しいコードをやたらとホイホイ取り込めないよな ライセンス絡みは面倒だから出来るだけ自分で書くのが一番いい ■ このスレッドは過去ログ倉庫に格納されています
